Reputation: 105
Have CRM 2011. Moving to another server with the end goal of upgrading to CRM 2016.
Installed CRM 2011 on new server. Backed up existing dbs and restored on new server. Changed server names in config table Servers. Recreated the PrivReportingGroup, SQLAccessGroup, ReportingGroup and PrivUserGroup. It appears that the groups names are in the format name, with the organization ID is squiggly brackets after the name.
I get the message:
"No Microsoft Dynamics CRM user exists with the specified domain name and user ID:", "A Microsoft Dynamics CRM user record does not exist with the specified domain name and user ID."
What really else should I do or what is the proper method for this type of migration?
The old server and the new are in different domain and different networks. The original server was Win 2008 and SQL 2008. The new is Win 2016 and SQL 2016.
I manually created the admin user in the SystemUser table and Administrator for for user in SystemUserRoles table.
Upvotes: 1
Views: 915
Reputation: 3586
Firstly - your configuration is unsupported, CRM 2011 cannot be installed on WS2016 and SQL 2016 (read). Although it might work (I think I did such test a while ago, but I cannot check it now, as I no longer have access to this environment) you should only do such things for DEV environments. For PRD environments, having in mind that you are a partner, so your client expects you to do the recommended approach not to loose Microsoft support for his system, you should install always software on the environment that is supported. The proper way of upgrading CRM 2011 to CRM 2016 would be to:
Of course on every stage of the system (CRM2013/CRM2015) you can add/change some customizations using things that were introduced in new system (or simply add them all in CRM 2016).
Now about moving the organization - you are clearly doing some magic that you should not do. Moving between domains is the simplest scenario and I did it hundred of times
Nothing more, nothing less. If you are creating manually some groups in AD or manually creating SystemUser by inserting value in SQL table (!!!!! OMG !!!!!) - you are doing something wrong and you should stops and start everything from scratch. And I mean that - from scratch, as you currently broke everything in your environment that could possibly be broken, even if the system works at some point, you can get some errors at the later stage or maybe after another upgrade that you will never be able to fix.
Make sure that you did not restore MSCRM_CONFIG on your target environment (and I'm afraid that you did that, because you wrote, that you restored databaseS) - you should only restore organization database not CONFIG database. If it's still not working then I'm 99% sure that the reason is your unsupported environment, so you will have to take the longer path which I described at the beginning.
Upvotes: 2