Restoring Microsoft CRM to a baseline state

Restoring to Baseline

Restoring the Microsoft CRM environment to a baseline state for development purposes requires several steps. These steps are simple but important.

The first step is to turn off any access to the database from the application. Please note that while this document includes all of the CRM components involved you will need to make sure that there are not any other applications or services such as SSRS or SSIS that may be trying to connect to the database.

Many of these actions may be scripted to assist with this process. It is common in a development environment to have one script to handle all of these actions in order to facilitate automated developer builds form a source control system. This only works in the case where all components reside on the same server (usually a virtual server).

STEPS TO RESTORING THE ENVIRONMENT TO A BASELINE STATE

On the CRM web front end and platform servers
* Stop the CRM Async Service [MSCRMAsyncService]
* Stop IIS

On the database server
* Restore the configuration database [MSCRM_CONFIG]
* Restore the working database. The name will depend on what you called it at installation time. Example [My_CRM]

On the CRM web front end and platform servers
* Start the CRM Async Service [MSCRMAsyncService]
* Start IIS

SAMPLE

Here is a sample script that can be used to restore a single server development environment to a baseline state.

WARNING: running this script will overwrite your current CRM database! While this sample doesn’t contain any way for the user to verify that they want to continue or give them a chance to cancel out of the script before running, you should 100% include such code in your process. I’ve provided the basics, it is up to you to enhance and embellish.

WARNING: running this script will overwrite your current CRM database! While this sample doesn’t contain any way for the user to verify that they want to continue or give them a chance to cancel out of the script before running, you should 100% include such code in your process. I’ve provided the basics, it is up to you to enhance and embellish.

REM Stopping services…
net stop MSCRMAsyncService
iisreset /stop

REM Restoring configuration database…
OSQL -E -Q “RESTORE DATABASE [MSCRM_CONFIG] FROM DISK = N’C:\Backups\MSCRM_CONFIG-Baseline.bak’ WITH FILE = 1, NOUNLOAD, REPLACE, STATS = 10”

REM Restoring working daatbase…
OSQL -E -Q “RESTORE DATABASE [My_MSCRM] FROM DISK = N’C:\Backups\My_MSCRM-Baseline.bak’ WITH FILE = 1, NOUNLOAD, REPLACE, STATS = 10”

REM Restarting services…
net start MSCRMAsyncService
iisreset /start

Baseline Data

While the cleanest and by far simplest way to restore your CRM system is to make a backup before you have added any data or made modification there a re a few points to consider that may aid in the process.

USERS

If you have a set number of users in the environment, it can be helpful to add and setup these users and include them in the backup. This way you don’t need to set them up each time. If you will be using a different set of user each time (For example in a training environment) it may be best to setup just the users that will always need to be included such as administrator.

DOMAIN ENTITIES

Domain entities such as listings of states or countries that do not change over time are good candidates for including in your baseline. Even though these may be custom entities, if they are static and will not change due to design updates they can be considered for inclusion.

As an example if you have a state entity that contains the state name, the two-letter code, and a time zone, this information will most likely not change over time. On the other hand if you are adding several custom fields to the state entity for use in calculations you may want to leave it out of your baseline as it may be subject to updates down the road. (Though honestly if you need to perform calculation based on state you may be better off having a simple static state table, and creating a second custom entity for your calculation fields.)

OOB ENTITIES

There are several out of the box entities that come with a basic CRM installation such as the account entity. You may decide that you would like to setup a simple shell for several accounts using the basic OOB fields to save time as you begin your customizations, or after you load a customized xml file. This is one that needs to be carefully considered and is highly dependent on the situation. You need to have a good understanding of how you are planning to use accounts so that you don’t fill in information that would be subject to change later, but if you fill out too little information it may not be useful.