Last week, I opened up the concept of using a recovery server—a vital tool for all Exchange Server administrators—and discussed deployment of Exchange Server 5.5 recovery servers. (You can access last week's commentary, "Using a Recovery Server in an Exchange 5.5 Environment," at http://www.exchangeadmin.com , InstantDoc ID 24995.) This week, I focus on Exchange 2000 recovery servers.
Deploying an Exchange 2000 recovery server is more complex than deploying an Exchange 5.5 recovery server. The first difference involves Exchange 2000's dependency on Active Directory (AD), which affects your ability to deploy recovery servers. Because you currently can have only one Exchange organization per AD forest (I hope this limitation changes someday), you must deploy a separate AD forest for your Exchange recovery server or servers. Otherwise, you'll be forced to join the recovery server or servers to your production Exchange organization. Although this requirement shouldn't be that big of a deal—the recovery forest can exist alongside your production forest and can provide a test environment—you need to determine the administrative impact that this new forest will have on your organization. The other key differences involve the change from sites (in Exchange 5.5 and earlier) to administrative groups (in Exchange 2000) and Exchange 2000's ability to have more than one Information Store (IS) per server. These differences add steps to the configuration of an Exchange 2000 recovery server.
The first step is to deploy your recovery forest. You can use any naming convention, but I recommend that you use the same conventions (i.e., organization naming convention and administrative-group hierarchy) you use for your production forest. The recovery forest can even exist on the same network as the production forest. After you deploy your Exchange 2000 recovery forest, install your Exchange 2000 recovery server into the forest. Use the same Exchange organization name (not AD organization name) for the recovery server as you use for the production server. The server name also can be the same as the production server name; because the servers are in different forests, no conflicts will exist (other than potential DNS conflicts if you place both forests on the same network). If you're going to run the recovery forest permanently, I recommend that you install a permanent recovery server that maintains a permanent name and is the first server in the Exchange recovery organization. When you've installed a permanent server in this manner, you can then install a second recovery server each time you want to perform a recovery; simply name that second server to match the server you're recovering. Or you can install a recovery forest and server each time you want to perform a recovery and modify the necessary values according to the recovery requirements.
After you configure the recovery forest and recovery server or servers, you can restore the IS database into a recovery administrative group with the same name as the administrative group from which you took the original database. From a database and AD point of view, the LegacyExchangeDN values for the recovery administrative group and the recovered database must match. In addition, the recovery storage group (SG) and recovered database names must also match those on the original server. If you've configured a permanent recovery server and installed a second recovery server to the same administrative group, SG, and database as the production server, these values will match. If you don't want to maintain a permanent recovery configuration, you can use a Lightweight Directory Access Protocol (LDAP) editing utility (e.g., Ldp, ADSI Edit—from the Windows 2000 Support Tools, or Ldifde—which Win2K installs by default) to view and manually update the LegacyExchangeDN values for the database and administrative group. Regardless of which tool you choose, the Exchange 2000 organization name, administrative group name, SG name, database name, and LegacyExchangeDN values for the production environment and the recovery server must all match. (For more information about the procedure to modify LegacyExchangeDN values, see "Exchange 2000 Server Database Recovery—Appendix A: Changing legacyExchangeDN Attribute Values" at http://www.microsoft.com/technet/prodtechnol/exchange/support/dbrecovr.asp .)
After you've restored the IS database to the recovery server, you can proceed to link mailbox objects to mailboxes. In Exchange 2000, you must explicitly connect a mailbox in the database to a directory object. If you're recovering only a few mailboxes, you can perform this step manually by using the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in to create user objects that aren't mailbox-enabled. Then, run the Exchange System Manager's (ESM's) Mailbox Cleanup Agent. Afterward, you should see mailboxes with a red X (which indicates that the mailboxes are orphaned—i.e., not connected to any user object) in the restored database. Right-click a mailbox object, choose Reconnect from the context menu, then select the user object that you want to connect to the mailbox. If you're recovering many mailboxes, you might want to use something such as the Mailbox Reconnect tool (MBConn), which is available on the Exchange 2000 CD-ROM, to save some keystrokes and mouse clicks. After the mailboxes are connected to user objects, you can use Outlook or Exmerge to extract data from them in the same manner that I discussed last week.
Every Exchange administrator should take the recovery-server concept to heart. I suggest that you implement Exchange recovery servers in your environment regardless of which Exchange version you have. Be aware that Microsoft does require you to purchase an additional Exchange license for each Exchange recovery server you install in your environment. Still, in addition to providing important Exchange recovery facilities, recovery servers provide a great nonproduction testbed. If you aren’t already using Exchange recovery servers, consider the benefits this practice can bring to you and your users.
