Hardware vendors are constantly pushing new hardware technology, a push that's often backed by application requirements and customer demand. In light of these continuous hardware advances, you might find yourself facing a particularly challenging problem: retrofitting your Exchange Server 5.5 systems. Last week, I went on site with a customer to replace Exchange 5.5 hardware, and in this case, we needed to accomplish the task with minimal downtime. We didn't have the luxury of simply backing up the Exchange 5.5 servers, then recovering the Information Store (IS) to the new servers. How we handled this challenge is the subject of this week's UPDATE. (Next week, I'll discuss the same topic for Exchange 2000 Server.)
The two basic approaches to upgrading hardware for Exchange 5.5 are the Forklift approach and the Move Mailbox approach. The Forklift approach is more work and requires a greater amount of downtime. The Microsoft article "XADM: How to Move Exchange Server to a New Computer with the Same Name" (see the first URL at the end of the Commentary) documents this approach. In a nutshell, the procedure involves backing up the Exchange data directories (e.g., IS, Directory Service—DS, Message Transfer Agent—MTA) on one existing Exchange computer, then transferring the directories to the new computer. You then bring up the new installation with the same name, organization, and site as the old Exchange server. The new installation will accept the data from the old Exchange server relatively easily (through the use of tools such as the DS/IS Consistency Checker and the Isinteg utility). Depending on how quickly you can accomplish the tasks outlined in Microsoft's procedure, the server can be operational in a reasonable amount of time. The disk subsystem that you use with an Exchange server has a huge effect on this procedure. For example, if your Exchange server attaches to a Storage Area Network (SAN), you can simply move the SAN LUNs from the old server to the new server. If your Exchange server boots from the SAN, your prospects are even brighter because you might be able simply to swap servers and reboot (depending on the server hardware configuration, of course). However, the Forklift approach isn't my favorite method because of potential downtime and a complex backout procedure.
The Move Mailbox approach is less risky than the Forklift approach and is by far my favorite way to solve the hardware-retrofit challenge. The Microsoft article "XADM: Differences Between Move Mailbox Methods" (see the second URL at the end of the Commentary) documents the procedure, which involves little downtime and is easy to back out from if you encounter problems. Using this procedure, you bring new hardware into the environment as an additional Exchange 5.5 server in the same site as the existing Exchange server. After you add the new Exchange server to the site, you simply move user mailboxes from the old server to the new system. The only downtime a user experiences is during the time you move his or her mailbox. In addition, even though users are on a new server, their Messaging API (MAPI) profiles are automatically updated as long as the old Exchange server is still available. After you successfully make the transition for all users and data, you can safely decommission or redeploy the old server.
Regardless of the approach you choose, you need to carefully plan and test your retrofit procedure. For example, when you plan to use the Forklift approach, you need to understand how long it will take to perform the retrofit operations, all of which will constitute downtime. When you use the Move Mailbox approach, you need to know how long it takes to move a mailbox and plan the moves accordingly to minimize user downtime. Weigh your options, plan carefully, and test thoroughly to make this task a success.
"XADM: How to Move Exchange Server to a New Computer with the Same Name"
"XADM: Differences Between Move Mailbox Methods"
