Move Dynamics CRM 2011

1
votes

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.

1
sql-servermigrationdynamics-crm
Thanks for the comment. I am the partner and I dont think this should be rocket science. MSDN states, Backup, Restore & you're done. Obviously it cant be that easy. - Ricardo
I don't know what to say here. You want it to be easy but there are many pitfalls. It's not as simple as backup and restore--definitely not across domains. I have no idea where you got that idea/article. Because these instructions definitely don't imply that. - Jacob H
Thanks for the link. Dont want to upgrade immideiately. Just get it working first and the link is [](msdn.microsoft.com/en-us/library/hh699772.aspx) - Ricardo

1 Answers

2
votes

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:

  • Install supported environment for CRM 2011 (WS2008/SQL2008)
  • Import organization to that server
  • Fix things that are not supported in CRM 2013 anymore
  • Install supported environment for CRM 2013 (WS2012/SQL2012)
  • Import organization to that server
  • Upgrade (in-place) to CRM 2015 (works on WS2012/SQL2012, so no need for another environment)
  • Upgrade (in-place) to CRM 2016 (also works on WS2012/SQL2012)
  • Install environment WS2016/SQL2016
  • Import organization to that environment
  • Get rid of the unnecessary environments
  • Drink beer and celebrate

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

  • take backup from one environment (ONLY organization_MSCRM database)
  • restore this database on second environment
  • run Deployment Manager on second environment and Import Organization
  • map users (if they have the same domain names, you can go for automatic mapping, otherwise do it manually or using mapping file) - you must map System Admin at least
  • done

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.