Moving back on-premise (for now)

One of my clients is experiencing a very poor performance on CRM online. The client is about to go live with the new system, but this week during an internal demo (for the key users) the key users complained about the performance. According to the management it was unacceptable.  *ouch*

Redlight

In the weeks prior we already had set up an on-premise CRM environment that was intended to be used as a fall back environment (in case of an internet outage). Whatever happens, the business must go on!
Now,  I can hear many of you think, the crappy performance is caused by the implemented solution!
On the on-premise environment the performance is actually very snappy. Screens crammed with information load between two and three seconds.

A performance that you would expect…

Did we use extreme hardware?

Nope, we have a single Dynamics CRM 2016 update 1 server (doing all the work) configured for Internet Faced Deployment and ADFS running on an ESX server, and a separate SQL Server instance running on the same ESX server. For both servers we configured a quad core 64bit CPU with 8GB (for the CRM server) and 16GB for SQL Server 2014. The storage used is shared SAN storage.

With this performant on-premise environment, the head of IT requested us to prepare the on-premise environment to be ready to be used as the main production environment just in case the management decides to use the on-premise environment.
In the meanwhile we have to investigate why the online version is performing so bad.

We already did setup some replication (one directional) from the online environment to the on-premise environment using SQL Server Integration Services combined with the KingswaySoft connector.
Getting a 100% replica of the online environment is not possible using replication, therefor we decided to request a backup of the CRM online database. The advantage of using a database backup is that you get all settings, solutions, security roles, users etc.

A Breeze!

I didn’t expect that requesting a backup was so simple! A collegue submitted the request at Microsoft on Wednessday afternoon (around 4pm / 16.00), Thursday morning (around 10am / 10.00) a support engineer called me , requesting some specific details about the backup.
The same afternoon (around by 2pm / 14.00) I received two email messages containing the FTP instructions to download the database backup. I downloaded the backup and uploaded it to the on-premise server, waiting for the evening to fall.

I have to admit, I’m impressed with the level of professionalism and the quick response from Microsoft (kudos to support engineer Sohail).

Getting things back to work again

In the evening I started to restore the online database on the on-premise SQL Server. On Technet you can find a good article on the steps you should follow, including getting the encryption key that you should apply on the on-premise environment after it has been imported.

Once the database was restored, I had to switch over to the CRM server on which I had to start the CRM Deployment Manager. The deployment manager is used to import the organization into your local CRM environment. Technically importing an organization is nothing more than registering a SQL Server database for use within CRM. Importing an organization doesn’t take long. During the import we had to do some minor corrections to the user accounts that were in the import as well.

After the import I was confronted with a CRM server running two organizations, the original on-prem one and the newly imported online one. Hmmz…. not exactly the situation I envisioned. I decided to disable the original organization. Bummer I was stuck with an a new organization using a different name and a different URL.

Getting the original URL to work again

As always the internet is your best friend. I found a blog post on Dynamics CRM Tip of the Day (tip #388) describing how to rename an organization.

  • Disable both organizations
  • Edit? No!
    Editing will only allow you to change the display name of the origanization.
  • Delete organizations (Yes, delete them!)
    This part sounds scary, but deleting is nothing more than deregistering the organization in CRM. The databases will remain untouched, the only database that is being altered is the CRM configuration database. IFD and ADFS settings remain intact!!!!
  • Import organization back
    Choose the correct database.
  • At that point you’ll be given an opportunity to change the name
    At this point I gave the organization the name of the on-premise environment. This resulted in the original URL being active again.
  • Inhale/exhale – that’s how long it usually takes

From this point on I was able to use the CRM online database (complete with all customizations) on the on-premise server. This mechanism works perfectly, definitely a workaround to remember!

2 thoughts on “Moving back on-premise (for now)

  1. Oliver says:

    Hi,

    nice tips & tricks – thanks!

    After you switched to on-premises: Have you / the users been fine with the performance? Do you have some basic numbers for me (amount of users/concurrent users in average, size of database, …)

    • The users are fine with the performance.

      In our case we had 2 servers, 1 CRM server (VM, 8GB, 2 cores), 1 SQL Server instance (vm, 16GB, 4cores). In a moderate customized environment you can expect pages to load between 2 and 3 seconds. The size of the database doesn’t matter that much. THe number of users is around 100.

Leave a Reply

Your email address will not be published. Required fields are marked *