Where does Navision or Business Central store the user settings?
Before the RTC, this was quite simple: In fin.zup in the %AppData% folder. The native Navision (fin.exe or finsql.exe) also liked to discard the settings at every opportunity. And a panacea for stuck Navision was to simply delete this zup (pronounced: Z-UP, ZETT-Up = setup).
Under Navision and Business Central RTC, the user settings are distributed across these three storage locations:
* Table entries in the table 2000000075 User Metadata
* Binary content in the file %AppData%\Microsoft\Microsoft Dynamics NAV\PersonalizationStore.xml
* Client settings in the file %AppData%\Microsoft\Microsoft Dynamics NAV\Version\ClientUserSettings.config
The client settings (third point) cannot be meaningfully copied using Navision's on-board tools. For a very simple reason: For Navision & Business Central to run at all, a functioning ClientUserSettings.config must already exist! A copy function built into Navision or Business Central for this user - or rather client - setup is therefore not particularly helpful.
In Business Central from version 15 (2019 Fall Release), the local settings file PersonalizationStore is completely removed. Here we are talking about design changes that are stored in the metadata.
So it is only really difficult with Navision / Business Central RTC from version 2009R2/2013 to version 2019 Spring Release, because here the PersonalizationStore.xml is added to the 2000000075 User Metadata table.
This article deals precisely with these Business Central & Navision versions.
Why copy the settings?
That is indeed a very important question! And unfortunately the answer is: because you didn't work properly beforehand.
The result of the copy-worthy settings is a clean Navision setting in which many columns are sensibly displayed or hidden and arranged in a good order. Fast-entry, skipping unneeded fields with the Enter or Tab key, menus, column widths... All this is already well set up and should therefore be transferred to a new or different employee.
But the mistake was made here much earlier!
Actually, such generally valid settings should be made across the board for all users. What was done in the native Navision up to version 2009R2: Simply open the screen masks directly with CTRL+F2 in the Designer, quickly set the "Next Control" & Visible properties, save, done.
The native Navision liked to discard the settings per form (the predecessor of the page) anyway, as in this case. And bang, all users had the same column order, widths and visibility.
I can do this again in Business Central. Here it's called InPlace Designer. And RTC Business Central and Navision? Also has such a cool function!
Simply call up Business Central or Navision, e.g. via a Lnk file with
Microsoft.Dynamics.Nav.Client.exe -configure -profile:”Accounting“
In this special config mode, all settings that are made (column sequence, visibility, fast entry, menus...) are not saved in the 2000000075 User Metadata table, but in the 2000000074 Profile Metadata table.
And surprise: All users who subsequently log in with this profile receive the same settings, which they can then refine according to their own wishes.
The actual copy
...is not easy because of the division into the config file and the data in the 2000000075 user metadata.
In the %AppData%\Microsoft\Microsoft Dynamics NAV\PersonalizationStore.xml, small details such as column widths are stored, while in the table 2000000075 User Metadata things such as visible columns, sequences etc. are stored. However, this changes in the different RTC versions of Business Central & Navision.
Rule of thumb: The newer the Navision / Business Central version, the more there is in the metadata table. The ever-improving technology behind this is also the basis for today's page extensions. An additional problem is that this PersonalizationStore.xml is located on the client and is therefore not visible or accessible to the executing Tier 2 layer.
The table 2000000075 User Metadata is a pure-bred Navision table, which as such can also be copied quite easily. The PersonalizationStore.xml, on the other hand, is really annoying to copy! Especially as Navision and Business Central always rewrite this file when exiting, from the settings that Navision or Business Central has stored in memory during runtime.
So we can't access this file with on-board tools! We could overwrite it. But even then, Navision or Business Central will overwrite it again with the unwanted values when it is closed.
My solution is therefore a little more complicated:
When a client is terminated, a trigger function checks whether the current user is allowed to write to the user setup table, at least indirectly.
If this is the case, the current %AppData%\Microsoft\Microsoft Dynamics NAV\PersonalizationStore.xml file at the start of the session(!) is written to a blob field in the user setup.
In this way, Navision gradually "knows" all PersonalizationStores of all users for whom there is also a user setup. Attention! This is always from the previous(!) session, as the settings that may have been changed are only written when the Microsoft.Dynamics.Nav.Client.exe is completely closed.
But: Better than nothing!
The rest is purely routine work:
In the user setup, please go to the user setup from which the settings are to be copied to the currently logged in user.
Use the "Copy setup" action command to start the copy.
Navision then asks again whether the direction is correct:
If you select Yes, Navision & Business Central first checks whether the necessary rights are sufficient and whether a PersonalizationStore has already been written in both the source and the target. This is important as there is currently no "clean" way to read the %Appdata% path. When the PersonalizationStore.xml was saved as described above, this was done at the same time.
Business Central & Navision then copies the last valid settings file and the currently valid entries from the 2000000075 User Metadata table of the source to the same table of the logged-in user.
Accordingly, the new user to be set up must also have the rights described below, at least for this process.
The previously saved PersonalizationStore from the source is then also copied to the current %appdata% path. But with the file identifier ".new", e.g. PersonalizationStore.xml.new. Business Central and Navision then open an explorer to this directory.
Now the running Business Central or Navision of this target user must be terminated. Reminder: Only now does Business Central or Navision (re)write the old PersonalizationStore.xml!
After exiting, the PersonalizationStore.xml can now simply be deleted in the browser that is already open, and the PersonalizationStore.xml.new that is already available can simply be renamed to PersonalizationStore.xml.
To do this, the folder option "Hide settings for known file types" should be deactivated (as I generally recommend).
Necessary user rights
Table 2000000120 User read permission
Table 91 User setup (Indirect) change rights & read rights
Table 2000000075 User Metadata (Indirect) write permissions, (Indirect) delete permissions, (Indirect) change permissions
English 
Deutsch 
Español