Recently, one of my clients reached a point in its business evolution where it began to outgrow the confines of Microsoft Small Business Server 4.5. As a quick refresher, the software has a limit of 50 client connections (50 users), among other restrictions. The client was still well below that number of total users, but its concurrent connections to the Exchange 5.5 system (part of the SBS server platform) were beginning to exceed that number due to Outlook Web Access connections. After consultation, the client decided to upgrade its messaging system from SBS Exchange to a standard Windows NT 4.0 Server running the full version of Exchange 5.5.
This migration involved overcoming several hurdles and providing for a careful backup plan. In this article, I will walk you through the process we used to accomplish this upgrade.
Mapping out a solution
According to Microsoft, there are no “official” methods to migrate from SBS, with the possible exception of upgrading directly to the full version of BackOffice Server—but even that method is rife with problems and is the subject of dozens of Microsoft Knowledge Base articles. What I was attempting to do was neither recommended nor supported by Microsoft, which meant that I needed to find new and innovative ways to move the Exchange system without destroying client data.
First things first. I ascertained that the client had a properly working full information store and a brick-level backup of the Exchange data. I verified that the system was working and that the tapes were restorable. This would allow the team to work and try new solutions while ensuring that nearly all client data was preserved. As we wanted to make sure that all the data was left unchanged, the next step was to plan exactly how to perform the migration itself.
My team realized that it was impossible to perform this migration on one server and that a forklift upgrade of some sort between servers was mandatory. One possible course of action was to create a new server in a new domain, with an Exchange server using the same organization, site, and server names. We could then take the PRI and PUB EDB files (from the SBS version of Exchange) and move them to the new box via some form of backup/restore system or direct move. After an offline restore and a directory services patch-up, all would be well, but in a brand-new domain.
However, since the client had other software running that relied on domain names, we had to find another method to get the system onto the new server. What finally evolved was a combination of PST files, directory copies, and DNS changes that effectively moved the data over with the minimum of downtime and no data loss.
Performing the migration
Our first step was to go to each Outlook client and create a local PST file specifying that all incoming mail should be directed to the new “inbox” created as part of the PST. This ensured that any incoming mail—no matter which server it came in on—would go to the client and stay there until we were finished. This also ensured that all client data was safely stored off of the servers in case the worst should happen.
Next, we built the second server with Windows NT 4.0 Server and Exchange Server 5.5. The Windows server was set up as a BDC to the SBS system, thereby re-creating all of the user accounts on the new box. The Exchange system was created in a new site with a new server name. Once all of the service packs and patches were put into place, we went to the original box and did a directory export to a CSV text file, then imported that into the new Exchange box to get all the recipient accounts replicated, although none of the data was there yet.
At this point, we worked with the ISP controlling the DNS information for the client and redirected all of the MX traffic to the new server. The clients could not yet receive their mail, as they were still connected to the old Exchange box, but all new mail was safely being stored on the new box until they could be moved over.
A return trip to each client machine completed the process. We changed the settings in Outlook to point the clients to the new server, allowing them to send and receive mail again. Total downtime was about 30 minutes, since there wasn’t a large amount of clients to be moved and the data stores were small. Reversing the PST process to move the mail back onto the server restored all the former functionality of the Outlook system.
If you ever have to do this type of upgrade, here are a few things to keep in mind. First, all of these upgrades require new licensing from Microsoft. Exchange 5.5 client access licenses needed to be purchased for each client connection (although there is a special price for the upgrade). In addition, it’s important to note that Exchange 5.5 licensing is no longer available. But you can purchase the equivalent Exchange 2000 licensing and use that, as recommended by Microsoft.
In the end, the migration off of SBS onto Exchange 5.5 is absolutely possible. It just takes planning, patience, and thinking on the fly as minor issues arise and need to be resolved. Provided you have the foresight to plan ahead and the patience to follow through, you can be running the full version of Exchange 5.5 Server with a minimum number of problems.
Have you upgraded from SBS to full versions of the components?
We look forward to getting your input and hearing about your experiences regarding this topic. Join the discussion below or send the editor an e-mail.