Three ways to migrate Exchange 5.5 mailboxes to Exchange 2000
One of the more challenging tasks involved in migrating from Exchange 5.5 to Exchange 2000 is moving users' mailboxes. If you don’t want to spend hours explaining to users where their e-mail disappeared to, you must take care to correctly complete the process.
Three migration methods
There are three common techniques for moving mailboxes from Exchange 5.5 to Exchange 2000. These are:
- The Move Mailbox Method
- The Swing Upgrade Method
- The In Place Upgrade Method
The Move Mailbox Method
The first method is the Move Mailbox Method. This technique involves actually moving existing mailboxes to a new Exchange 2000 Server. Although this particular technique tends to be the least troublesome, it has one major disadvantage — the price. The Move Mailbox Method requires you to shell out money for new hardware and won't allow you to reuse your existing Exchange Server. However, there are workarounds.
For example, suppose that you have five Exchange 5.5 Servers that you want to migrate to Exchange 2000 and that each server has adequate hardware to run Exchange 2000. If you like the Move Mailbox Method, but you don’t like the idea of having to buy five new servers to replace your perfectly good existing servers, you can get away with just buying a single server. You could then migrate the first Exchange Server to the new server.
When you are convinced that the migration has gone according to plan, and that everything is working properly, you can format the hard drives on the server that you’ve just replaced and load a clean installation of Windows and Exchange 2000 onto it. After doing so, you can migrate the second server onto the server that you have just reloaded. In the end, you would end up with only one server that you can’t reuse.
I've seen organizations set the unused server aside and use it as a spare in case one of the production servers had a catastrophic failure. I've also seen organizations go ahead and load Windows and Exchange 2000 onto the leftover server, and then migrate all of the organization’s public folders to the leftover server, thus using it as a dedicated public folder server. The advantage to this strategy is that you relieve all of the mailbox servers from the burden of having to host public folders.
One last disadvantage to the Move Mailbox Method is that, while it’s possible to simply move mailboxes and public folders to the new server, there is no built-in method for moving connectors or key management services. You’ll have to manually reconfigure such items on the new server once the migration is complete.
Advantages to the Move Mailbox Method
Now that I have talked about the Move Mailbox Method's disadvantages, I’ll talk about the method’s advantages. For starters, this method is the easiest migration method. It also has the least user downtime. After all, a user’s mailbox is only inaccessible during the time it takes to move it from one server to another.
Typically, it's necessary to update the user’s profile in order to point Outlook to the mailbox’s new location. One of the things that I really like about this method is that it works well for organizations with small or inexperienced IT departments. For example, suppose that you needed to migrate 1,000 users, but your entire IT staff consisted of only four people. Odds are that four people wouldn’t be able to reset 1,000 users' Outlook profiles in a single night.
There’s also the issue of unforeseen problems. I've been in situations where I've migrated a server and everything appeared to work perfectly. However, when users started logging on the following day, some unforeseen problem manifested itself, and the phone started ringing off the hook. This meant scrambling to fix problems for everyone using that server.
One advantage to using the Move Mailbox Method is that you don’t have to migrate all of the mailboxes at the same time. Instead, you can migrate as many mailboxes as you feel comfortable with. For example, you might migrate 20 or 30 mailboxes and make sure everything is working fine for those users. Once you are satisfied that there are no kinks in the migration, you can migrate the other users.
Another advantage to using the Move Mailbox Method is that it eliminates most of the need to worry about Exchange Server versions. This is important because you can’t upgrade a server to Exchange 2000 unless it is running Exchange 5.5 with Service Pack 2 or higher. Therefore, if you have an Exchange Server that is Exchange 4.0 or 5.0, you won't be able to upgrade to Exchange 2000 without first upgrading to Exchange 5.5. Using the Move Mailbox Method keeps you from having to deal with the headaches of multiple version upgrades. Furthermore, since you are moving the mailboxes to a freshly installed Exchange 2000 Server that hasn’t been upgraded from a previous version, your server will likely be more stable and perform better than a server that has been upgraded several times.
Unfortunately, the Move Mailbox Method isn’t completely version-independent. There is one version-related requirement that you must adhere to when using this technique. Before you can install an Exchange 2000 Server into an existing Exchange organization, you must have at least one server in the organization that’s running Exchange 5.5 with Service Pack 2 or higher. This means that if your entire organization is running older versions of Exchange, you will have to upgrade at least one server before you are able to bring the new Exchange 2000 Server into the organization.
This is easier than it sounds. The upgrade version of Exchange 2000 comes with a copy of Exchange 5.5. In addition, Exchange 5.5 is so similar to Exchange 5.0, that you shouldn’t have any issues learning the differences between the two versions, especially if you're only upgrading for the purpose of moving the mailboxes onto a different server.
The Swing Method
The Swing Method is a variation of the Move Mailbox Method. There are dozens of variations of the Swing Method, so I will try to illustrate the most common. Like the Move Mailbox Method, the Swing Method also requires you to purchase additional hardware. The biggest hardware requirement difference is that, for the Swing Method, you can get away with buying low-end hardware. In fact, you could even use a regular PC instead of having to shell out big bucks for a server.
The basic idea behind the Swing Method is that you install Exchange 2000 onto your swing server and make the swing server a part of your Exchange organization. Once the swing server is up and running, you use the Move Mailbox Method to move all of the mailboxes and public folders from the production server to the swing server. After doing so, you upgrade the production server to Exchange 2000, and then use the Move Mailbox Method to move the users and public folders back to the production server.
Although this technique is a variation of the Move Mailbox Method, it tends to be more complex than the Move Mailbox Method because there are more issues that you must consider. The first of these issues is bringing the swing server onto the network as an Exchange 2000 Server. If you don’t presently have an Exchange 2000 Server on your network, there is still the requirement that at least one server on your network must be running Exchange 5.5 Service Pack 2 before you can bring an Exchange 2000 Server into an existing Exchange Network.
However, there isn’t any reason that you can’t simply install Exchange 5.5 Service Pack 2 onto the Exchange Server and then upgrade it to Exchange 2000. In fact, if you buy the upgrade version of Exchange 2000 Server, it actually comes with a copy of Exchange 5.5 and with a CD containing Service Pack 2.
Once the swing server is up and running, there’s the issue of moving the mailboxes from the production server to the swing server. When you were using the Move Mailbox Method, you had the luxury of moving a few mailboxes at a time. However, the Swing Method requires you to move all of the mailboxes at once.
Once all of the mailboxes have been moved off of the production server, it’s time to upgrade the production server to Exchange 2000. While you can technically perform an In Place Upgrade, I recommend formatting the server and loading Windows and Exchange from scratch. Doing so will give you the best performance and reliability, because there won’t be any leftover components from previous versions of Windows or Exchange.
Furthermore, you won’t have any of those mystery glitches caused by components that didn’t quite upgrade the way you expected. After the production server is running Exchange 2000, you must use the Move Mailbox Method to move the mailboxes and public folders from the swing server back to the production server.
The biggest advantages to using the Swing Method are costs and accessibility. The cost of using this method is lower than that of the Move Mailbox Method because you can use a PC as the swing server rather than having to buy a full-blown server. The accessibility part comes into play because you don’t have to reconfigure anyone’s Outlook profile to point to a new location. This is a really nice advantage if you have several users or if you have remote users.
Disadvantages to the Swing Method
The disadvantages of this method are the administrative burden and the time involved in performing the upgrades. Think about it. If you have a 10-GB private information store, then you will have to wait for all 10 GB to be transferred to the swing server. You will also have to wait while all 10 GB are copied back to the production server. Believe me, there’s nothing worse than sitting around at 3:00 A.M. waiting for large chunks of data to copy so that you can finish the job and go home.
You also have the wait time involved in reformatting your production server, reloading Windows, and installing Exchange 2000 and the necessary service packs. Just to give you an idea, the last time I had to set up a brand new server, I formatted the hard disk and then loaded Windows, the Windows Service Pack, Exchange Server, and the Exchange Service Pack. All in all, it took about three hours. This was a 2.55-GHz server.
As you can see, there are several tasks that you’ll have to complete before anyone affected by the upgrade will be able to use Exchange again. Fortunately, the swing server can be set up at any time prior to the upgrade since setting up the swing server doesn't affect users. Therefore, you could set up the swing server a day or two before performing the upgrade, so that you have one less task to complete on the night or weekend of the upgrade.
A final disadvantage of the Swing Method is similar to one of the Move Mailbox Method's disadvantages: There is no mechanism for moving connectors or key management services. This isn’t really a big deal, but it does mean that you will have to manually reestablish the various connectors and other mechanisms prior to allowing users to access the new server.
The In Place Upgrade
If you've been reading this article wondering why you can’t just upgrade your existing Exchange Server to Exchange 2000, the answer is that you can. This technique is known as an In Place Upgrade. As you have probably already figured out, an In Place Upgrade uses your existing hardware rather than requiring you to go out and buy a new server. But there are some issues to consider when adopting an In Place Upgrade.
For starters, your server usually won’t perform quite as well after an In Place Upgrade as it would after a Move Mailbox or a Swing Upgrade because you are upgrading software rather than getting the benefit of a clean installation. Furthermore, an In Place Upgrade puts some limitations on you. You aren’t allowed to install any Exchange components that weren’t already installed in the prior version. This means that you won’t be able to take advantage of things such as instant messaging or chat services unless you were somehow using them with Exchange 5.5.
There’s also the requirement that your server be running Exchange 5.5 Service Pack 2 or higher prior to the upgrade. If your server is presently running Exchange 5.0 or earlier, you’ll have to upgrade to Exchange 5.5, install Service Pack 2, and then install Exchange 2000. This could mean a lot of downtime for your users. Remember that the server is inaccessible during the upgrade.
Another thing to consider is that if your Exchange Server is using any connectors that aren’t supported by Exchange 2000, the upgrade process will remove the connectors, and you may not be able to get them back.
An additional issue is that of Outlook Web Access (OWA). OWA was completely redesigned for Exchange 2000. This means that it performs much better than previous versions of OWA, but it also means that older versions of OWA are overwritten rather than upgraded. Therefore, if you have made any modifications to OWA, those modifications will be lost.
TechRepublic originally published this article on 21 July 2003.