Update NAV - NAV 2017 CU9 --> CU10

Blackdiamond

Hello,

I need to understand how to update to the newest CU10 NAV 2017.
I have already tried once and failed. Therefore I need some professionnels to assist me.

I am currently working on 10.0.17972.0 (CU9), which is a demo company (Cronus) without any modifications.

Now I want to update to the latest CU10.

I have already read: https://support.microsoft.com/en-us/help/3204818.

1. Application:
To install the application files, follow these steps:
Unmodified databases:
Import the CUObjects.<Locale>.<Build No.>.fob file into an unmodified Microsoft Dynamics NAV 2017 database.
Replace the existing objects in the database with the cumulative update objects. After this it ask me to Sync. Schema for all tables.
Should I say yes to Synch here?

If I only import *.fob files during step 1, can I still run Dynamics NAV client or I am missing something here?
Purpose of only do step 1?

2. Platform:
What it is main purpose of updating platform. Are you not able to run Dynamics NAV Client without updating platform.

Thanks
Blackstone

Slawek_Guzek

Usually you would want to preserve ClientUserSettings.config file.

Apart from that one you need to overwrite all the files in RoleTailored Client and in Service folders. Also pay attention to NavSip.dll file which is supposed to go to %systemroot%system32\ folder.

Slawek_Guzek

Hi,

Yes, sorry, I meant CustomSettings.config under folder "Service". This keeps your default NST configuration, you'd rather want to keep it rather than reconfiguring the NST each time.

Unfortunately I don't know what exactly NAVSip.dll do. It is installed by NAV installer, and with some CUs there are coming new versions of it. If you'd uninstall NAV and re-install it back using the installer a new version of NAVSip.dll would be copied over to System32 folder. I don't know why MS documentation does not mention it.

How would you realize that a patch requires database upgrade? 1. It is written in the release notes, 2. if you open the database with a newer version of DEV Env it will ask for conversion 3. If you update NST server binaries it won't start but will leave an error in the Event Log.

You don't have to import the fob twice. At the point of fob import, when the NST is stopped, you can select "Later" when Dev Env is asking for table synchronization. Layer on after the NST is up and running you can open the database in DEV Env and select Tools -> Sync. Schema For All Tables -> Force

If you already imported the fob re-importing it is not necessary - unless you have skipped some objects from it.

In any case table synchronization is necessary.

Slawek

Slawek_Guzek

Hi.

1.
You need to synchronize your tables. If you only import the fob the table structure on the server will not change, and the system will not fully work. Each time you try to access any object which touches unsynchronised tables you will get an error.

2. Platform updates fix various errors. With each release you have release notes telling you what platform errors have been fixed. Your database still may work on older client without those fixes, but it is genrerally a good idea to have the platform errors sorted out as much as possible

EDIT:

The purpose of loading new fob is to get all new functionality (if any has been included) and to have application errors fixed. The release notes mentioned earlier include both application fixes (fixes in NAV object code) and platform fixes (fixes in Client and/or NST server binaries)

/EDIT


Slawek

Blackdiamond

Hello,

Thanks for answering me very quick.

1a. Do I need to stop my Dynamics NAV Server, before importing the *.fob file.
1b. Can I still run Dynamics NAV Client after importing *.fob file without updating platform hotfixes.

Slawek_Guzek

Hi,

1a. You cannot stop the NST, if you do you will not be able to synchronise your tables.

1b. It depends.

There are system tables which are closely linked to specific Client version, or few versions. One of those is Active Sessions table. If your fob includes the Active Sessions table, and you import it the NAV will no longer work, until you stop the NST server and upgrade its binaries, convert the database in newer DEV Env delivered with that patch.

If you skip the system tables (ie import only objects with ID below 20 000 000) the new fob may work witth older client

The patch may or may not requiring you to upgrade the database (I am not sure if upgrade CU9 -> CU10 actually requires this). If not then applying the patch is simple - load the fob, sync the tables. Job done.

If however the patch requires updating the database the correct process of applying it looks as follows:

1. Stop the NST
2. Update the NST and Client binaries (possibly web client too if you use or plan to use it)
3. Open the database in new DEV Env, convert the database, load the new fob
4. start the NST
5. synchronise the tables (either by opening the database in DEV Env again and synchronising it from there, or by using PowerShell

Slawek

Blackdiamond

Hello,

1a. Thanks for answering.
1b. You are right.

I did try with your description just import the new *.fob file from CU10 and open Dynamics NAV Client. It was successful, no errors :-)

Now I want to go to extreme and also update NST and Client binaries.
During updating (I will use manual patching process, since i am not a developer) is there anything i need to avoid or do not overwrite a file in either "Service" or "RoleTailored Client" folder.

Slawek_Guzek

Usually you would want to preserve ClientUserSettings.config file.

Apart from that one you need to overwrite all the files in RoleTailored Client and in Service folders. Also pay attention to NavSip.dll file which is supposed to go to %systemroot%system32\ folder.

Blackdiamond

Thanks for all your tips. It is helping me a lot. I am much further in my progress toward updating then last time.

I cannot find any ClientUserSetting.config file under folder Service or RoleTailored Client. On the other hand i am able to fine CustomSettings.config under folder "Service". Is that what you meant?

What does NAVSip.dll do?
In the guideline from Microsoft this file is not mentioned at all.

A question out of curiosity: In earlier post you mentioned "The patch may or may not requiring you to upgrade the database, how would you realized that.

If however the patch requires updating the database the correct process of applying it looks as follows:

1. Stop the NST
2. Update the NST and Client binaries (possibly web client too if you use or plan to use it)
3. Open the database in new DEV Env, convert the database, load the new fob
4. start the NST
5. synchronise the tables (either by opening the database in DEV Env again and synchronising it from there, or by using PowerShell

Which means that I am importing *.fob file twice? Is it necessary, when I already importing *.fob before updating step 2.

Sorry if I ask to much.

Slawek_Guzek

Hi,

Yes, sorry, I meant CustomSettings.config under folder "Service". This keeps your default NST configuration, you'd rather want to keep it rather than reconfiguring the NST each time.

Unfortunately I don't know what exactly NAVSip.dll do. It is installed by NAV installer, and with some CUs there are coming new versions of it. If you'd uninstall NAV and re-install it back using the installer a new version of NAVSip.dll would be copied over to System32 folder. I don't know why MS documentation does not mention it.

How would you realize that a patch requires database upgrade? 1. It is written in the release notes, 2. if you open the database with a newer version of DEV Env it will ask for conversion 3. If you update NST server binaries it won't start but will leave an error in the Event Log.

You don't have to import the fob twice. At the point of fob import, when the NST is stopped, you can select "Later" when Dev Env is asking for table synchronization. Layer on after the NST is up and running you can open the database in DEV Env and select Tools -> Sync. Schema For All Tables -> Force

If you already imported the fob re-importing it is not necessary - unless you have skipped some objects from it.

In any case table synchronization is necessary.

Slawek

Blackdiamond

Hi,

That explain much better. I succeed with implementation after all.

I did a mistake by self in the beginning, because I forgot to check as you described :
if you open the database with a newer version of DEV Env it will ask for conversion 3

It is working now and thanks a lot for your help and knowledge.

Slawek_Guzek

You are welcome