So this week was very interesting. We had a client who wanted to go from the hosted Dynamics CRM 3.0 to an on-premise Dynamics CRM 4.0 Professional edition.
Since they wanted to keep their hosted 3.0 system functional, I built out a new server with:
- Windows Server 2003, w/ SP2
- SQL Server 2000, w/ SP4
- All windows updates, including .NET FMWK 3.0
We redeployed CRM 3.0 to the new server, then upgraded the SQL installation from 2000, SP4 to 2005, SP2. We ran the SQL update script to change the buildversion of the CRM database to comply with CRM 3.0 On-Premise. The SQL script is listed below:
select *from buildversion
update buildversion set buildnumber = 5300
update buildversion set revision = 0
update buildversion set minsupportedclient = '3.0.5300.0'
After you run the SQL script to upgrade the database, it will be able to appear in the CRM 3.0 On-Premise installation (when you connect to an existing installation).
After installing CRM 3.0, we upgraded to CRM 4.0 and backed up the database to transfer to the client's new CRM 4.0 environment.
Redeployment for CRM 4.0 has been designed to be system admin friendly.
- You install CRM 4.0 on the new server
- Rrestore the existing CRM 4.0 Org_MSCRM database to SQL 2005
- Access the MMC snap-in Deployment Manager
- Import Organization (and you are done.)
I walked through all of the steps on my own test server before attempting it on the client's environment. My test worked perfectly smooth.
The actual execution wasn't quite so picture-perfect. Yeah...we ran into different issues while trying to restore the database to the new SQL Server.
One of the errors we received was: Error 3154: The backup set holds a backup of a database other than the existing database.
After doing some research, I found that it was a semi-common problem in SQL and that you had to use a REPLACE clause when executing this statement. Since I couldn't execute the restore through the GUID, I decided to try to execute the restore manually through a SQL script. This is the script that I ended up writing. (oh the client wanted the sql database files to exist on a different harddrive, hence the MOVE clause):
Query:
RESTORE DATABASE CRMName_MSCRM
FROM DISK = 'E:\InstallDBs\CRMName_MSCRM-Full Database Backup.bak'
WITH REPLACE,
MOVE CRMName_MSCRM' TO 'E:\sqldata\CRMName_MSCRM.mdf',
MOVE CRMName_MSCRM_log' TO 'E:\sqldata\CRMName_MSCRM_log.ldf'
Results:
Processed 59816 pages for database CRMName_MSCRM', file CRMName_MSCRM' on file 1.
Processed 4 pages for database CRMName_MSCRM', file CRMName_MSCRM_log' on file 1.
Processed 17 pages for database CRMName_MSCRM', file 'sysft_ftcat_documentindex_eacc0dc2b9b94e2c98d072e33598dfe6' on file 1.
RESTORE DATABASE successfully processed 59837 pages in 32.453 seconds (15.104 MB/sec).
Using the above script, it appeared to Restore correctly. The importing of the organization failed in a later step. Since that didn't work, we had to figure something else out.
The solution:
I mentioned that I had restored this database to my own test server. I stopped all of the SQL Services that were running, physically copied the mdf and ldf (SQL database and log) from my test server to the client server. The mdf and ldf files were ATTACHED to the client's SQL Server and then we executed the Import Organization against that attached database. The import took about 10 minutes, and WORKED! (That was the most nerve-wracking progress bar I have ever watched.) I think we could have also used a copy of the mdf and ldf from the upgraded database (from 2000 to 2005). So if you can't restore your database into the target SQL Server, you may want to try our workaround:
- Install CRM 4.0 on target CRM Server
- Stop all SQL services on upgraded CRM/SQL Server (source)
- Copy MDF and LDF files from source to target server
- Attach MDF and LDF files to target SQL Server
- Use Deployment Manager to Import Organization
Good luck in your upgrades! We worked until almost 3AM in order to land upon this solution ...hopefully your chances are improved by this post!
Labels: 4.0, Deploy, MSCRM, SQL