Upgrade Paths for Microsoft Dynamics CRM 2011

You may have heard that Dynamics CRM 2011 requires 64-bit architecture. This is true and is giving some folks some heartburn when they start to think about upgrading their CRM 4.0 deployments, many of which are still living in a 32-bit world.
There are three potential upgrade paths, as well as another alternative that I would urge you to consider. Let’s take a look.

In-Place Upgrade

An in-place upgrade is pretty straightforward: You’ve got an existing CRM 4.0 system that is running on hardware and software that is supported for CRM 2011. You fire up the setup.exe for CRM 2011 and it detects that CRM 4.0 is in place and asks if you want to proceed with an upgrade.
PROS: Straightforward, no need to lay out money for new hardware.
CONS: Risky – if the upgrade fails, you need to know how to roll back to your backups; Disruptive – while you’re upgrading, your users won’t be able to access CRM.

Upgrade Database During Install

In this scenario, you install CRM 2011 to a new 64-bit application server, and connect to a SQL server with an existing CRM 4.0 database. The 4.0 database will be upgraded during the install. This is a decent option if you’ve already got your SQL database on support hardware and SQL versions. It’s a little easier to recover from in case of failure than an in-place upgrade, since all you need to do is restore your databases.
PROS: Leverages your investment in 64-bit SQL hardware/software; once-and-done installation if you succeed.
CONS: Similar risks to the in-place upgrade though perhaps slightly less disruptive to end users.

Upgrade via Import

This is my preferred manner for upgrade. Essentially you build a new 64-bit environment for a clean install of CRM 2011 – the application servers and database servers are brand new and without remnants of CRM 4.0. After you’re satisfied with your new CRM 2011 environment, you simply restore a backup of your 4.0 database to the 2011 SQL Server, and then, using the CRM 2011 Deployment Manager, import the 4.0 org database into your new deployment. I’ve done this several times now, and it works like a charm, upgrading the org during the import process.
PROS: Nice, new, bug-free 2011 environment; opportunity to perform upgrade tests multiple times before your “go-live” upgrade; no disruption to users.
CONS: This is the most expensive scenario, requiring new hardware (or at least separate hardware) for the 2011 deployment. Also, you need to manually copy over things like supporting ISV files and applications that you may have had in place in your 4.0 environment.

Consider This

Lastly, I’d recommend that you evaluate CRM Online while considering your upgrade options. Now is a great time to take advantage of the improved functionality, affordability, and ease-of-maintenance that CRM Online provides.  If you have been managing a CRM 4.0 on-premises deployment, and want to move to the latest version of CRM, there are many good reasons to consider the cloud. C5 Insight can upgrade your database for you and then migrate your customizations and data to Microsoft’s data centers, allowing you to go back to running your business instead of running servers. Think about it!

Originally posted at my C5 Insight blog.

CRM 2011 Released for On-Premise and Partner-Hosted Installation

Microsoft is moving quickly on the heels of the January release of CRM 2011 Online, and this week's release of the 2011 Implementation Guide and SDK, they have now released the RTM version of Dynamics CRM 2011 for on-premise and partner-hosted installation. Available from the Microsoft download site.

A Complex Upgrade

I had the opportunity this past weekend to do an upgrade that challenged just about every skillset that can possibly be required during a CRM implementation. It took 14 hours, and involved changes, installation or configuration of: Small Business Server, DNS, Active Directory, SQL Server, Windows Server components, database restores, IIS, Reporting Services, registry hacks, virtual servers, Office service packs, and possible several other things I'm not recalling right now. For those of you who are masochists, here's a lengthy narrative to describe the process:

CRM 3.0 SBE was on a virtual server running Small Business Server 2003 – R1, not R2, so it was using SQL 2000. CRM 4.0 requires SQL 2005 SP2, so we could not do a straight upgrade in place on the SBS box. Rather than upgrade Small Business Server to SBS 2003 R2, since they had already installed a new SQL 2005 server, we backed up the CRM databases and restored them to the new SQL 2005 box – which, by the way, was also a new virtual machine.

We then re-configured the existing CRM 3.0 installation to use the new SQL 2005 databases, and tested that everything was working. One thing I did not do – though I thought about it at the time, and ruled it out for the sake of time – was to move the SQL Reporting Services databases to the new SQL 2005 server and upgrade SQL Reporting Services for the existing CRM 3.0 installation. In the end, I might have saved more time by having the SSRS reporting function pre-migrated to SQL 2005.

So we restored the CRM databases to SQL 2005, and then we were ready to start an in-place upgrade to CRM 4.0 right on the SBS box. We had to add SP2 to SQL 2005 before upgrading, and we found out that the IT partner had pretty much given us a raw server for CRM, so we had to install IIS and ASP.NET support, as well as indexing and message queuing, and full-text indexing for SQL. While we were at it, we went ahead and installed SQL Reporting Services on the SQL 2005 server to get it ready for our final step, which was to install CRM 4.0 a second time on the new CRM server and import the organization that had just been upgraded on the SBS box.

We had to add a registry entry to disable loopback checking to get the Reporting Services website to work, and of course run the configuration wizard for Reporting Services. Additionally, there are a couple of custom add-ins that I had developed for 3.0 which required some tweaking and migration of their own in order to make them available to the new 4.0 installation.

At this point, everything seemed to be functioning correctly, but as soon as we powered down the SBS virtual server, reports stopped functioning from the new CRM 4/SQL 2005 environment. My suspicion was that some of the Active Directory security roles that had been controlled by the SBS box had not replicated to the new Primary Domain Controller that was replacing the SBS box. So after trying to manually configure these unsuccessfully, we brought the SBS box back online to see if our suspicions were correct. We also installed the SQL Reporting Services Connector for CRM, but unfortunately, we couldn’t get reports working again, and we’re going to have to wait until the SBS box is completely decommissioned, with the FSMO roles, DNS and Active Directory fully migrated to the new Primary Domain Controller.

We installed the Email Router for CRM and configured the Incoming and Outgoing rules. This is still a highly un-intuitive process, and after a few minutes of trial and error, the tests of the Email Router configuration returned successful results.

Another glitch we ran into was when we were trying to install the Outlook client the first time. Actually, the installation of the Outlook client went fine, but when running the configuration wizard, after entering the new address of CRM, we kept getting errors that the Outlook add-in couldn’t resolve the CRM address (the error message suggested that maybe the CRM server was shut down). Turns out these error messages were misleading. I initially thought there was some confusion due to using the same port number for the new CRM website as for the original one, so I changed the port numbers IIS was using, and still had no luck. After some digging, we found that the configuration wizard was in fact resolving correctly to the new CRM server, it just wasn’t getting the right message back from the database because there were still some lingering entries in the DeploymentProperties table that had the SBS server name in them. Here’s the SQL script (thanks to the CRM newsgroups) to update the database to make sure it contains the right server:port entries if you have remnants from a previous install:

UPDATE dbo.DeploymentProperties SET NVarCharColumn = 'newcrm:5555' WHERE
ColumnName IN ('ADWebApplicationRootDomain', 'AsyncSdkRootDomain',
'ADSdkRootDomain');
UPDATE dbo.DeploymentProperties SET NVarCharColumn =
'HTTP' WHERE
ColumnName IN ('ADRootDomainScheme');

After manually updating the database to get rid of these remnants of the old SBS installation, we were able to successfully configure the Outlook add-in.

So, between virtual machines, an upgrade, a re-deployment (or, more precisely, a reinstallation of CRM that pointed to existing databases that had been upgraded both to SQL 2005 and CRM 4.0, and an import of the CRM Organization), and various and sundry updates, patches, hotfixes and setting configurations, CRM 4.0 is up and running. Performance is great, with sub-second response times and form loads, and I’m confident we’ll get the reports working once the SBS box is totally out of the mix.

UPDATE: I got the SQL Reporting Services website working. Once the SBS box was removed from the network and all the FSMO roles and DNS had been migrated to the new domain controller, I was able to add the correct security permissions to the SQL Reporting Services website.

What was strange was that the installation/upgrade added the folder to the SSRS website for CRM 4.0. (In CRM 3.0, there was a flat hierarchy in the SSRS website - you had a folder called MyOrganization_MSCRM, and inside were all the RDL files and data source settings for the CRM reports. In 4.0, when you upgrade from 3.0, you get a new folder under this called simply "4.0" and all the new reports are under this folder.) I couldn't see the 4.0 folder at first when I browsed to http://sqlreports/reports, so I tried adding it. That's when I got an error message saying this folder already existed. Even though I had domain admin permissions. If you click the "Show Details" button you should see the 4.0 folder, but I didn't.

I checked another CRM installation's SSRS website, and copied the URL that takes you directly to the 4.0 reports folder: http://sqlreports/Reports/Pages/Folder.aspx?ItemPath=%2fMyOrganization_MSCRM%2f4.0&ViewMode=Detail and it took me to the folder, where, oddly, the folder had been checked to remain hidden in the folder view. I removed this checkmark, and then went to the security settings for the folder and added the Active Directory groups for CRM report users, as well as the NT Authority\NETWORK SERVICE account, and voila - CRM could now see the SQL Reports for 4.0.

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.