For the last several weeks I’ve been pretty much heads down migrating my Small Business Server 2003 to SBS 2008. One of the last tasks was to move my MS CRM 4.0 over. The plan was to install SQL 2008 on the new SBS 2008 server, install a TEMP CRM organization and then import CRM data from the original server. in the end it did work, but there were a few bumps on the way.
The first bump was trying to install SQL 2008 on the SBS 2008 server. Naturally I wanted to install it ALL. Well, it wouldn’t let me. It kept complaining about a conflict with SQL 2005 Express. I thought I’d just uninstall the parts it was complaining about but quickly figured that that would also uninstall my Companyweb and my Monitoring. Can’t do that. i eventually figured out that what it was complaining about was the management tools. Leaving those off I was able to install SQL 2008 fine.
Next step was to install my TEMP organization. Seemed to go well until I hit the SQL Reporting Services part. This has always been a stumbling block, especially with SBS installations. It seems that CRM in this case requires using SSL to connect to the SRS, even on the same box. In the past there used to be a check box. I don’t recall ever seeing an SSL check box on this migration. I have a commercial certificate for https://remote.company.net but this didn’t seem to work for my SRS. i eventually resolved the issue by using a self-signed certificate from SBS.
My last step was to import the old CRM organization into the new CRM deployment. To do this I used the SQL Management Studio in my SBS 2003 to backup the MyOrganization_MSCRM database which contains all the pertinent data. The original MSCRM_CONFIG isn’t needed as it is already created in the new deployment. I then transferred the backup to my new server and then would have restored it into my new SQL 2008 server. Would have except for one itty bitty little problem. Remember those pesky SQL management tools I couldn’t install? Guess what I need in order to do the restore of the migrated data into SQL 2008? Yup, those management tools which include SQL 2008 Management Studio. What I had to do was install those on a workstation. I’ll spare you the bumps I encountered doing so as it is not really related to this discussion. Suffice it to say that once I installed them on a workstation, I was able to access the SQL 2008 on the new server and do the restore. Now I had a MyOrganization_MSCRM database on the new server.
The last step was to do the actual import. This is done on the server itself using the Deployment Manager from the Start –> All Programs –> Microsoft Dynamics CRM. You must be a Deployment Administrator to do this. By default, the account you use to install CRM is a Deployment Administrator. You may add others if you like. Importing an organization is basically pretty straight forward. From the Deployment Manager, select Organizations from the Navigation (left) pane then Import Organization from the Action (right) pane. Unless you are running the Enterprise Edition which allows multiple organizations, you will receive a warning stating that the current organization will be disabled if you import a new one. Since we only have a TEMP organization, that’s cool. Next you select the SQL server (in my case the SBS 2008 server) and the database which you just restored into SQL. Next you provide the Organization display name (My Organization) and it will fill in the name for you without spaces (MyOrganization). Next enter the SQL Report Server URL. Again, I had to use the SSL URL, https://server.company.local/ReportServer. The last step is to map the users from the old database to the new one. If you have migrated your Active Directory users over to the new server, this should be fairly straight forward. Except… another bump in my bumpy road. Seems that the account used to install CRM and to be the Deployment Administrator for our migration needs to have a CRM user account. SBS 2008 makes you create a new Active Directory account to use as the system administrator instead of using the Built-in Administrator account. So I had to configure a user account for this new Administrator. I also had had a couple of odd accounts I had used in the past that were no longer being used. They had been disabled in CRM and when I migrated I removed the Active Directory user accounts as well. CRM didn’t like this very much at all. Once a user account has been created in CRM, you cannot delete it. You can only disable it. This is by design and appropriate. But put a few more bumps in the road. Eventually I got those user issues ironed out and was able to import my old organization into my new SBS 2008 server.
Be sure to read the CRM 4.0 Implementation Guide before you do the migration. There are a couple of other steps and checks in the IG that I haven’t covered that you’ll need to attend to as well. All in all, my new deployment seems to be doing well. Be sure to reconfigure your CRM Outlook clients to point to the new server.