Using a Recovery Server in an Exchange 5.5 Environment

One of the most challenging areas of an Exchange Server administrator's job is disaster recovery. You must consider every scenario, including mailbox and message recovery, Information Store (IS) recovery, and complete Exchange Server recovery. Individual mailbox and message recovery (sometimes called brick-level recovery) can be the most daunting of these scenarios. Microsoft doesn't provide a definitive solution but rather leaves the field open to third-party developers. Many third-party solutions for mailbox- or message-level recovery exist, but most are far from perfect. However, one approach to brick-level recovery should become your best practice, regardless of which version of Exchange you run. This solution—an Exchange recovery server—can be a useful tool for every Exchange administrator. Of course, Exchange Server 5.5 provides recovery retention for deleted items and Exchange 2000 Server adds mailbox retention to that capability, but these two mechanisms might not meet all your disaster-recovery requirements, so the recovery-server option is nice to have available.

The idea behind an Exchange recovery server is to maintain a spare server that you can use as a target location for recovery operations. No matter which version of Exchange you run, you can recover an IS to the recovery server, then restore complete mailboxes or individual messages by using Outlook or a program such as Exmerge to extract the items from the recovered IS. This week, I begin a two-part commentary about the practice of using a recovery server. Recovery-server capability is available for any version of Exchange, but configuration varies depending on whether you use Exchange 5.5 (or earlier) or Exchange 2000. Because most of you use Exchange 5.5, I'll start with the strategy for that environment. Next week, I'll finish up with the recovery-server scenario for Exchange 2000 environments.

With Exchange 5.5 and earlier versions, your recovery server can be any member server or domain controller (DC) in the same domain as your original Exchange server. When you install and configure the recovery server, use the same organization- and site-naming conventions and hierarchy as you used with the original server, but use a different server name and don't join the recovery server to the production organization. You can even use the same Exchange Service account, but the recovery server must have a different name than the original server—you don't want the recovery server to start participating in the Exchange organization and performing directory replication. The result will be a server with a different name but with the same organization and site names as the original server. Because you don't join the recovery server to the organization during installation, this configuration lets the server function in the environment without causing problems for the production Exchange 5.5 deployment.

After you install and configure the recovery server, you can restore an IS to the server. However, because you didn't join the recovery server to the existing organization, the directory database on the recovery server won't contain any objects. You can manually create mailbox objects in the directory to match the objects you want to recover, or you can run the Directory Service (DS)/IS consistency adjuster (which you can access from the Microsoft Exchange Administrator menu) to automatically generate directory mailbox objects for each mailbox in the IS. Either action links IS mailboxes to directory objects on the recovery server. Then, you can simply install the Outlook client on the recovery server, or you can use a tool such as Exmerge to extract mailbox data to personal store (.pst) files, then import the data back to the appropriate mailboxes on the production server.

Setting up a recovery server might seem like too much bother. However, if you want to provide brick-level disaster recovery for your Exchange users, this system can be a lifesaver. Next week, I'll discuss the deployment of recovery servers in an Exchange 2000 environment—a process that's quite different from the Exchange 5.5 process because of Exchange 2000's dependence on Active Directory (AD).