Subscribe to our newsletter

sales.email@dmcinfo.com

(888) DMC-4400

DMC, Inc.
Contact Us
dynamics-crm

How to Upgrade On-premises Microsoft Dynamics CRM 2015 to 2016

DMC

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:

  1. 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.
  2. Install CRM 2016 on the new servers and test performance
  3. Migrate (backup and restore) the organization’s database to the new SQL server
  4. Upgrade the organization database using the CRM Upgrade Wizard
  5. 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.”

The account specified to run the Microsoft Dynamics CRM...

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 for yourself at this TechNet article), so I made the table below to help determine what kind of authorization each account needed for 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”:
 
Microsoft.Crm.Setup.Server.GrantConfigDBDatabaseAccessAction failed.
 
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. An exception was thrown by the target of an invocation. Cannot create a file when that file already exists. (Exception from HRESULT: 0x800700B7)”
 
Microsoft.Crm.Setup.Server.StartWebsiteAction failed.
 
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 within SQL Server Management Studio. We only had to back up 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 organization 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:
 
CRM 2016 Import Organization
 
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!