Upgrading CRM 3.0 SBE to CRM 4.0 Professional

Well, I promised to blog on this, and it's taken me longer than I expected to find the time. I recently performed my first upgrade of CRM 3.0 SBE (on Small Business Server 2003 R2) to CRM 4.0 Professional.

First, a little background on system requirements if you are considering an upgrade to CRM on you Small Business Server. The newest version of CRM, version 4.0, requires SQL Server 2005, which means that if you have not upgraded your SBS 2003 to "R2" then you are probably still running SQL Server 2000. So the first thing you'll need to do is get SBS up to the R2 (that's shorthand for Release Version 2) which upgrades SQL to 2005, installs WSUS and also upgrades a number of other items in Small Business Server Premium.

If you've got R2 in place, you shouldn't have to do anything more than insert the CRM 4.0 disc (or download the installation package from Microsoft.com). Of course, you will want to have good backups of your server, and especially your SQL databases.

When you first begin installing CRM 4.0, the installer goes out to the web to check for updated installation files. So you will need an internet connection. It also installs and initiates the C++ runtime (and it will do this each time you try to run the CRM 4.0 installation, even if you've already downloaded it). So make sure you've got a good internet connection!

When I started this upgrade, I got to the point where the installer checked all the system requirements (more about that below) and when I proceeded to install, it kept failing with a weird error about the MsiInstallerServerAction. It said something like "the patch package could not be opened." I thought this might be related to the Windows MSI installer, so I went on a wild goose chase and ran Windows Update several times to get the server fully patched. It turns out the problem was because the antivirus software on the server was preventing the installer from opening the installation package! I could have kicked myself because I typically disable antivirus software when performing a complex installation like this, but it had slipped my mind this time. So take that as a warning: disable your antivirus solution while running your upgrade.

After working that out, I started running the installation and when I got to the part again where it checks all the system requirements (the part where you want to see a bunch of green checkmarks show up) I got a warning that "setup has detected that there are one or more bulk import jobs pending in the existing Microsoft Dynamics CRM 3.0 system." I searched through CRM and the database and could not locate any pending bulk import jobs. All of them were in a successful completed state, so I still don't know what this warning was about. I then proceeded with the upgrade, and after the installer started running it took about 35 minutes to complete.

After that I started doing my post-upgrade testing. One thing I found was that because CRM 4.0 was designed for multi-tenant, some custom dashboards in this particular installation were not showing images correctly. This is because the relative URLs in the custom .aspx page needed to be re-written to include the organization name. Where they had been pointing to "_custom/_imgs/image.jpg" for example, they needed to be re-written to "orgname/_custom/_imgs/image.jpg" (this particular custom dashboard had it's root folder inside the root folder of the CRM server which, strictly speaking, is unsupported).

Further testing since the upgrade has uncovered a number of minor bugs, mostly related to script errors when viewing or closing windows in the CRM web client. The script errors aren't related to custom scripts, but there appears to be some problems with code inside 4.0 that Internet Explorer 7 doesn't like. I'm still compiling the steps to reproduce these errors and haven't tracked them down. In most cases when a user gets these errors they are saving and closing (or just closing) a form for an activity or a history view on a record, and they get an error window that allows them to send the details to Microsoft. If they click through this the record they were working on is typically saved correctly, so, like I said, it's an annoyance at this point, but doesn't seem to have a critical impact. I'll post again later if/when I track down the source of these errors.