Disaster Recovery Preparation
If you are still running Exchange 2000, you probably know that disaster recovery preparation has changed quite a bit in Exchange 2003. For instance, the introduction of the Recovery Storage Group now makes it much easier to recover mailbox data for individual users, and no longer requires you to build a recovery Exchange server (in a separate forest, or segmented network).

Let's go back and take a look at building a recovery server for Exchange 2000, though. There are really two choices when you implement a recovery server. First, you can take an existing GC offline and move it to a segmented network that has no access to your production server. Once you have done this, you will need to seize all the FSMO roles. Then you can install Exchange on another server (using the /disasterrecovery switch if you want) that has the same name as the original Exchange server. If you choose this method, you won't have to worry about legacyExchangeDN issues, as the /disasterrecovery switch simply pulls all the Exchange info out of Active Directory and doesn't prompt you for any information. HOWEVER, one key warning here. If you have deployed an empty forest root domain, and all your accounts are set up in a child domain (as well as Exchange), you also have to put a forest root GC in your recovery network. See, one of the FSMO roles is the Schema Master. That specific role can only be assigned to one server in the entire forest. In order to seize the Schema Master role, you have to be logged on with an account that is a member of the Schema Admins and/or Enterprise Admins Groups. Guess what? Those groups do not exist in a child domain :-) If you forget to put a forest root GC into your recovery network, you will not be able to reinstall Exchange because you will not be able to seize the Schema Master role. Which brings you to the second choice (and the one actually outlined in Microsoft's Mailbox Recovery white paper - found here).

The second method is to build a completely new forest (the AD domain name simply doesn't matter here as it relates to Exchange). For this, you can even use a single server to do everything. This also gives you the added benefit that you can leave it attached to your production network if you choose (certainly makes restoring from tape easier) Build your forest (new forest, new tree, new domain), then install Exchange using the same Organization name as your production org (and SP's to same level as production server). Once you have done that, you'll need to make sure that the legacyExchangeDN's match those of production (this information is detailed in the white paper) and then create the Admin groups and Mailbox stores so that they match production as well. Now you are ready to restore. You can either restore using your backup software (if this is a possibility), or you can also simply restore the flat files (.edb and .stm files). Either way works fine. Now you are ready to mount the store. If everything was done correctly, the store will mount without any problems. IF there are any errors, consult event viewer (Application log) for more details. The most common reasons that the store wouldn't mount would be if a legacyExchangeDN value does not match somewhere. There is a great tool on the Sp3 CD to help with this - it is called LegacyDN.exe. It basically allows you to change the LegacyExchangeDN value for your Administrative Group (and all objects underneath it if I understand the tool correctly). It can come in quite handy if your production environment had been migrated from Exchange 5.5.

With either the first or second method, once the mailbox store is mounted, you are ready to use Exmerge. A couple of notes on using Exmerge.

1. There is some conflicting information out there regarding whether or not Outlook is required. I do not recall ever needing Outlook on a recovery Exchange server, but there are other KB articles that mention Outlook should be installed. I'll leave it up to you.
2. If you run Exmerge, remember that it requires RECEIVE AS permissions on the mailbox store object in order to be able to extract.
3. The user account you are logged in with MUST have a mailbox on a store that is mounted. If the user account has a mailbox, but that mailbox store is not mounted, Exmerge will be unable to log in and see the other mailboxes on other stores.

As you can see, recovery prospects for a single mailbox for Exchange 2000 can be quite difficult. If you are looking to recover a single mailbox and don't do mailbox-level backups (which I don't recommend anyways), you might consider deploying an Exchange 2003 server and working with the Recovery Storage Group. Remember that as long as your Exchange 2000 database is SP3 or greater, you can still mount that database to the Recovery Storage Group in Exchange 2003.
- posted by Ben Winzenz @ 8:15 AM