ArcherPoint Dynamics NAV Developer Digest - vol 53
The ArcherPoint technical staff—made up of developers, project managers, and consultants – is constantly communicating internally, with the goal of sharing helpful information with one another.
As they run into issues and questions, find the answers, and make new discoveries, they post them companywide on Yammer for everyone’s benefit. We in Marketing watch these interactions and never cease to be amazed by the creativity, dedication, and brainpower we’re so fortunate to have in this group—so we thought, wouldn’t it be great to share them with the rest of the Microsoft Dynamics NAV Community? So, the ArcherPoint Microsoft Dynamics NAV Developer Digest was born. Each week, we present a collection of thoughts and findings from the ArcherPoint staff. We hope these insights will benefit you, too.
Jon Long on migrating personalization and profile metadata:
Personalizations and Profiles – The Continuing Saga of migrating Metadata.
You can’t migrate Personalizations from a test db to a db upgraded from pre-NAV2013.
My team and I have developed several clever scripts over the years, as well as DataPorts, XMLPorts, and tricks to move Metadata relating to Personalizations and Profile Configuration Metadata from one db to another. They all work, but, not really. They do move the data from one db to another, but there is a catch: In versions prior to NAV 2013, there was no concept of a SID (Security Identifier). In 2013, there are User SID, Login SID, and SID (Windows Login). They all map to each other in multiple tables.
To get an idea what is in these tables, run these queries in SQL Server Manager:
SELECT * FROM [Windows Access Control]
SELECT * FROM [Windows Login]
SELECT * FROM [User Personalization]
SELECT * FROM [User Metadata]
SELECT * FROM [Page Data Personalization]
There is also the Profile Metadata table. The Profile and User Metadata tables contain a blob field containing personalizations in some type of binary XML format.
The SID mapping is a nightmare since we’re finding that some fields are being re-generated during the conversion in an upgrade, ultimately wiping any mapping away. So we’ve had to write some re-mapping scripts. Once we’ve gotten the mapping correct and all data looks good, the users do not see their personalizations or any of the Profile Configuration Metadata. I’m suspecting it’s because the Metadata itself has hard coded references from the old db.
Here is a transcript from my conversation with Microsoft (edited to save time):
[Jon] The solution will be different when going from Classic to RTC (upgrade) as opposed to RTC to RTC. If a client is already on RTC and they are upgrading, or simply moving Personalizations from one db to another, it may not be an issue. The mapping part of this issue is due to the Upgrade Toolkit creating the User SID field every time an upgrade occurs. The logic is in the conversion code. We typically do 2 or 3 migrations before an actual GoLive. Each conversion requires us to transfer personalizations and other relevant tables from the old TEST to the new TEST and then from the final TEST to PROD at GoLive.
Here’s what we’re doing:
Old Prod (5.0sp1) from server A restored and upgraded to 2015 on Server B and named TEST
Testing is done on TEST with lots of configurations applied to Profiles and Personalizations
6 months later, Old Prod (5.0sp1) from server A restored and upgraded to 2015 on Server B and named PROD. Then we run SQL scripts to move all relevant tables from TEST to PROD. Now, everything looks as if it should work. But, it doesn’t. The personalizations are not active and the Profile Configurations are not active, even though the data looks as if it should be.
I understand the mapping and how to get data from one db to another, including across domains. My problem is that the end result simply does not result in the correct personalizations or configurations. The result is that the system behaves as if no personalizations or configurations exist yet. It’s as if the delta (blob fields in the Metadata tables) has hard coded references to the old User SID.
I’m fairly convinced that the answer to this mystery is in the Metadata (User and Profile). It seems that, currently, we cannot successfully migrate Metadata from one db and apply it to another.
[MS] If you’re now going into a scenario such as upgrading and trying to maintain personalizations, that’s not going to happen. You have to rebuild them, sorry. My assumption was that the upgrade occurred and then you’re at a stable place in NAV 2015 trying to migrate from one 2015 to another 2015 environment. Development has never provided anything that will allow one to maintain all security and personalization when upgrading. Feel free to test deleting user metadata, but I’m not sure that’s going to allow you to do what you’re trying to do. If you’d like to discuss please let me know.
Jon Long on upgrading with Easy Security:
Easy Security – When upgrading from and to any version, it is best to remove the old version and start clean. From Per “You can upgrade the data in NAV Easy Security, but we suggest you install the application clean in the new NAV version. Then can you transfer the data with the tools inside NAV Easy Security. You can find more information on the page below.
Upgrade 2009 to 2013/2013 R2/2015 with NAV Easy Security
“The upgrade process is tricky because you have to deal with the changing data types and clean-up of records. That is the reason we suggest using the fresh install and transfer the data.”
Rajasekhar Yedamakanti shared this blog from Microsoft on upgrading best practices:
Microsoft has published article about best practices and tips and tricks in upgrading process to NAV2013R2 or NAV2015. See the article below:
Best Practices Tips and Tricks for Upgrading to Dynamics NAV 2013 R2 or Dynamics NAV 2015