Looking for help with upgrading your Microsoft Dynamics CRM system? We recently upgraded our Microsoft Dynamics CRM 2015 system to MSCRM 2016. When preparing for the upgrade and during the process we found a lot of disparate information available from Microsoft. I wrote this blog to help others find the most useful information and to share details about the challenges we faced during our upgrade.
Our high-level upgrade plan was as follows:
- Build new servers to house the database and web application
- The initial environment consisted of two servers, both Windows Server 2012, with the database server running SQL Enterprise 2008 R2.
- We kept the two-server model and upgraded both to Windows Server 2012 R2, and the new SQL install was SQL Enterprise 2014.
- Install CRM 2016 on the new servers and test performance
- Migrate (backup and restore) the organization database to the new SQL server
- Upgrade the organization database using the CRM Upgrade Wizard
- Enable Internet Facing Deployment (IFD) and Active Directory Federated Services (ADFS)
Every step except number 5 went extremely well, but we ran into issues when enabling ADFS and the IFD. Originally we wanted to move from ADFS 2.0 to ADFS 3.0, but following a day of troubleshooting and not resolving the problem, we ended up sticking with ADFS 2.0. Additionally, we found that our custom fix for single sign-on with ADFS 2.0 was not possible in 3.0 due to the switch away from using IIS.
Despite the issues that we had with ADFS, the process was fairly simple and we were able to get our new deployment up and running over a weekend. Had we not tried to upgrade to ADFS 3.0 we would have been ready in a matter of hours. There were a few small hiccups here and there along the way, but hopefully the information below will help you sail through your own upgrade.
Setting Up Servers
We followed Microsoft's most recommended path to set up a new application and database server for our 2016 install. The following table shows Microsoft's recommendations for hardware, along with our own setup; we have not seen any performance issues ourselves.
|
Component
(CRM Server)
|
Microsoft Minimum
|
Microsoft Recommended(source)
|
DMC Server |
|
Processor
|
x64 architecture or compatible dual-core 1.5 GHz processor
|
Quad-core x64 architecture 2 GHz CPU or higher such as AMD Opteron or Intel Xeon systems
|
Intel Xeon CPU E5-2660 v3 @ 2.6GHz |
|
Memory
|
4-GB RAM
|
8-GB RAM or more
|
8-GB RAM |
|
Hard disk
|
10 GB of available hard disk space
|
40 GB or more of available hard disk space
|
60 GB of available hard disk space |
|
Component
(SQL Server)
|
Microsoft Minimum
|
Microsoft Recommended(source)
|
DMC Server |
|
Processor
|
x64 architecture or compatible dual-core 1.5 GHz processor
|
Quad-core x64 architecture 2 GHz CPU or higher such as AMD Opteron or Intel Xeon systems
|
Intel Xeon CPU E5-2660 v3 @ 2.6GHz |
|
Memory
|
4-GB RAM
|
16-GB RAM or more
|
32-GB RAM |
|
Hard disk
|
SAS RAID 5 or RAID 10 hard disk array
|
SAS RAID 5 or RAID 10 hard disk array
|
SAS RAID 5 |
Setting up these servers was fairly straightforward, and we followed the Microsoft TechNet article on CRM 2016 Software Requirements to drive our decisions on which additional programs to install. Basically, all we had to do outside of the pure defaults was to turn on IIS on the application server.
Installing CRM 2016
Once the servers were ready to go, we moved the CRM 2016 installation executable to the application server and ran the installer. The first hiccup we ran into was some errors with permissions: "The account specified to run the Microsoft Dynamics CRM application does not have Performance Counter permissions."
This occurred because the CRM setup does not give all of the appropriate permissions to the accounts that you specify during the initial steps. Finding the required levels was a little tedious (as you can see yourself at this TechNet article), so I made the below table to help determine what kind of authorization each account needed to which parts of the system. The yellow columns are permissions that could not be added before setup completed, and were added by the setup itself (despite the fact that Microsoft specified them as required).
|
|
Domain Users membership
|
Logon as service
|
Trace Folder
|
CRMWeb Folder
|
CustomizationImport Folder
|
%AppData% Folder
|
HKEY_LOCAL_MACHINE
\SOFTWARE\Microsoft
\MSCRM
|
HKEY_LOCAL_MACHINE
\SYSTEM\CurrentControlSet
\services\MSCRMSandboxService
|
SETSPN
|
PrivUserGroup
|
SQLAccessGroup
|
Performance
Log User
|
CRM_WPG
|
SQLAccessGroup
|
Sysadmin on SQL Server
|
Local admin on FE
|
Local admin on Deployment Web Service
|
Local admin on SQL
|
|
Microsoft Dynamics CRM Sandbox Processing Service
|
Yes
|
Yes
|
R/W
|
|
|
R/W
|
Read
|
|
Yes
|
|
|
|
|
|
|
|
|
|
|
Microsoft Dynamics CRM Asynchronous Processing Service and Microsoft Dynamics CRM Asynchronous Processing Service (maintenance) services
|
Yes
|
Yes
|
R/W
|
|
R/W
|
R/W
|
All access permissions except Full Control and Write DAC
|
All access permissions except Full Control and Write DAC
|
Yes
|
Yes
|
Yes
|
Yes
|
|
|
|
|
|
|
|
Microsoft Dynamics CRM Monitoring Service
|
Yes
|
Yes
|
|
|
|
|
Read
|
|
Yes
|
|
Added by setup
|
|
|
Yes
|
|
Yes
|
|
|
|
Microsoft Dynamics CRM VSS Writer service
|
Yes
|
Yes
|
|
|
|
|
Read
|
|
|
Yes
|
Yes
|
|
|
|
|
|
|
|
|
Deployment Web Service (CRMDeploymentServiceAppPool Application Pool identity)
|
Yes
|
Yes
|
R/W
|
R/W
|
|
R/W
|
All access permissions except Full Control and Write DAC
|
All access permissions except Full Control and Write DAC
|
Yes
|
Yes
|
Yes
|
|
Yes
|
|
Yes
|
|
Yes
|
Yes
|
|
Application Service (CRMAppPool IIS Application Pool identity)
|
Yes
|
|
R/W
|
R/W
|
|
R/W
|
All access permissions except Full Control and Write DAC
|
All access permissions except Full Control and Write DAC
|
Yes
|
Added by setup
|
Added by setup
|
Yes
|
Yes
|
|
|
|
|
|
Once the appropriate permissions were set and setup was rerun, we ran into this next issue, "Action Microsoft.Crm.Setup.Server.GrantConfigDBDatabaseAccessAction failed. Windows NT user or Group [SQLAccessGroup] not found. Check the name again":
Luckily we found a
blog almost immediately that explained why this error occurred. Essentially, the setup creates groups (like the SQLAccessGroup) but does not wait a sufficient amount of time for them to replicate across the domain controllers. The easy fix is to wait a few minutes and retry, at which point everything should exist in the proper places. All we did to resolve this error was to wait five minutes and hit the retry button.
The last setup error that we ran into was, "Action Microsoft.Crm.Setup.StartWebsiteAction failed. Exception was thrown by target of an invocation. Cannot create a file when that file already exists. (Exception from HRESULT: 0x800700B7)"
This occurred because we set the default IIS website to port 80, and the CRM setup wanted to use that port for the CRM website. The easy solution was to delete the default site from within IIS and hit the retry button.
After that last IIS error, the rest of the setup completed without a problem. The next steps in our upgrade path involved backing up and restoring the organization database to the new server and running an upgrade command to bring it into CRM 2016.
Migrating and Upgrading the Database
Backing up the organization database was as simple as selecting the backup command from the set of tasks withing SQL Server Management Studio. We only had to backup the organization database because a new configuration database (MSCRM_CONFIG) gets installed automatically during the installation of CRM 2016. Our organization database had around 40GB of data in it, and it took about 30 minutes to back it up to a file.
Before restoring the organziation database, we installed the CRM Reporting Extensions on the new SQL server as per this TechNet article's instructions. The restore was very straightforward, and simply involved importing the database backup file into the new SQL server. The restore took even less time than the backup took, and was up and running within 15 minutes.
Once the database was restored to the new SQL server, all we had to do was run the Import Organization wizard from the CRM Deployment Manager:
Since we were going right from CRM 2015 to CRM 2016, we ran into zero errors and the import process took less than 10 minutes to get through. The only warnings that came up were some about mapping users that did not exist on our domain any longer, but the rest of the users mapped to the appropriate places without us having to change anything.
Hopefully, this helps if you are tackling a similar upgrade of your Microsoft CRM. If you would like assistance with any aspect of your CRM implementation (e.g. installation, configuration, workflows, and other customizations) - just
contact us, we would welcome the chance to help!