Midsized to large Exchange 2000 Server installations often maintain a dedicated server for recovery operations. You can use a recovery server as replacement hardware to get users back to work quickly after a catastrophic hardware failure, but the most common use of recovery servers is to retrieve specific information deleted from an Exchange 2000 database on another server. To produce mailbox data that your users—or lawyers—might ask for, first configure a server with plenty of disk space and the same software as your Exchange 2000 servers, then follow the steps outlined here.
Uses for a Recovery Server
Some examples of Exchange data that you might be asked to recover are
- a mailbox that someone has mistakenly deleted (after the mailbox's deleted-mailbox-retention period has ended)
- one or more mailboxes or items needed for legal or other reasons (you might need to retrieve all the messages from several mailboxes or messages sent over an extended period; the latter necessitates restoring multiple backups to ensure that you don't omit a specific message)
- a public folder whose only copy has been deleted
- a specific item or items that a user has deleted and can't retrieve by using the deleted-items-recovery option
- mailboxes from a failed server that you want to save to personal file folders (PSTs), then reload on a restored server
You can also use a recovery server to run database-maintenance utilities against a backup copy of a database to check it for any lurking corruption or to test to make sure that you're making reliable backups. For example, let's assume that you've noticed some -1018 (JET_errReadVerifyFailure) errors in the Application log. Typically, these errors indicate that the drive that contains the database has a hardware problem. You can restore a backup of the database to the recovery server and run the Eseutil utility to determine whether the database is healthy. If the database is OK, you can check the hardware to discover the root cause of the -1018 errors. If Eseutil reports that some pages contain problems, such as a failed checksum, you know that the database has a serious problem and that it will soon fail even if you replace the hardware. You can use the Move Mailbox option or the ExMerge utility to transfer mailbox data to another server before the database fails.
A recovery server also lets you determine how long Eseutil will take to rebuild a database (so you'll know how long your production server will be offline) and whether the rebuilt database will save you a significant amount of disk space. In addition, recovery servers are useful if you want to test an add-on product, especially a backup or antivirus utility, against real data. Far too many products work wonderfully in demonstration environments processing limited amounts of data only to encounter problems processing real data in production environments.
Hardware and Software Environments
You must allocate suitable hardware to a recovery server. You don't need a multi-CPU, highly redundant disk subsystem configuration such as what you deploy in production. However, a recovery server has some prerequisites:
- The server must have enough disk space to hold the largest database that you might need to recover. Alternatively, the system should be capable of adding disks quickly should the need arise.
- The server should use the same backup software as used in production and must be able to read tapes created on the production servers.
- The server should be running the same version (including patches) of Windows and Exchange as the production servers.
If you want to be able to recover PSTs from a failed disk, your recovery server will require a surprising amount of disk space. (Exchange 2000 doesn't force users to delete email messages from their PSTs to stay within quotas, so users tend to keep messages.) However, the number of individual files involved makes restoring PSTs a fiddly operation, so you aren't likely to undertake this job unless absolutely required.
Having an available recovery server is only part of the equation. Knowing how to restore data quickly and effectively is the other.
Recovering an Exchange 2000 Mailbox Store
Because Exchange 2000 depends so heavily on Active Directory (AD) for mailbox and configuration data, you must take some specific AD-related steps to ensure that you can access mailboxes after you restore databases onto a recovery server. The basic requirements are as follows: The recovery server must be in a different AD forest from the original server. The forest names can be different, and the two forests can share a network. However, you must install the recovery server into a different Exchange organization with the same name. Remember that a forest can have only one Exchange organization, so by installing the recovery server into a different forest, you prevent the recovery server from interfering with the production servers. You should also stop users from attempting to log on to or otherwise access the recovery server while you're working with it. For a description of how to keep users away, see "Blocking Client Access to Exchange Servers," November 2002, http://www.exchangeadmin.com, InstantDoc ID 26505.
After you install Exchange 2000 on the recovery server, you must perform the following steps before you can use the regular restore procedure to restore the databases. First, use Exchange System Manager (ESM) to change the logical names of the recovery server's storage group and database to match the names of the storage group and database on the original server (either specify the required names when you create the storage group and database or rename them later). The names should match exactly—including the name of the original server if it's specified in the database name—but the underlying filenames (e.g., mailbox.edb) can be different. Use the same storage group names, and follow a convention for database names throughout an organization to lessen the chance of errors during a recovery operation. Figure 1 shows a portion of the ESM interface displaying a store's logical name and the underlying physical filename.
Second, you're going to overwrite the database on the recovery server with the database from the original server, so you must use ESM to amend the target database's properties to allow backups to overwrite the files, as Figure 2 shows. If you use an offline backup for the restore, you're copying data stored at a specific point in time, so the recovery server's Store doesn't need to replay data in transaction logs to apply transactions that occurred after the backup was made. Thus, you can delete the existing database and logs and overwrite them with the data from the backup set. However, you must set the database's properties to let the database be overwritten, even when you use an offline backup.
Third, before you restore any data, make sure that the AD legacyExchangeDN values for the administrative group and organization match on the original and recovery servers. Exchange 2000 uses the legacyExchangeDN attribute extensively to identify objects and ensure backward- compatibility with earlier versions in items such as Messaging API (MAPI) profiles. In the case of recovery servers, a successful restore depends on the Store being able to verify with AD that a database it wants to mount is registered with AD. The simplest way to ensure that the administrative group and organization values are the same on the original and recovery servers is to specify the original server's values when you install Exchange 2000 on the recovery server. However, if you've already installed Exchange 2000 with different legacyExchangeDN values, you can use the LegacyDN utility in the \utils\tools\i386 folder on the Exchange 2000 Service Pack 1 (SP1) and later CD-ROM to adjust the values before you attempt to recover data. Essentially, you create a replica of the original environment. You can make the necessary changes with other Lightweight Directory Access Protocol (LDAP) tools such as ADSI Edit or Ldifde, but using LegacyDN is much easier and quicker.
Don't run LegacyDN in a production environment. If you do so, you could easily make a mistake that would severely affect your Exchange organization and force you to restore AD and all Exchange 2000 servers.
Figure 3 shows the LegacyDN utility in action. In this case, the recovery server is restoreserver in the restoredomain.com domain. When you run LegacyDN on a server, it scans the AD to find all the existing administrative groups. You can then select an administrative group and change its base details or legacyExchangeDN stem to reflect the values in the database that you want to restore. You can restore the database from tape (or other media) without changing these values, but the Store won't be able to mount the restored database because the legacyExchangeDN values won't match.
In the Figure 3 example, I want to restore a database from the NSIS European Messaging Team administrative group in the Compaq organization. To fix the values, I insert the names of the original organization and administrative group and click Change Leg. Then I, stop and restart the Store process to make the change effective. The net effect is to change the existing legacyExchangeDN stem of
/O=Compaq/OU= First Administrative Group
/O=Compaq/OU= NSIS European Messaging Team
If you don't know the value of the legacyExchangeDN attribute for the administrative group on the source server, you can use the ADSI Edit utility to read the value from the Microsoft Exchange configuration container. Figure 4, page 4, shows the result of using ADSI Edit to drill down through the AD configuration naming context to the Services container, then the Microsoft Exchange container, followed by the organization container. Each administrative group is a subcontainer under the organization. Select the administrative group to which the source server belongs, and view the group's properties. Select the legacyExchangeDN attribute from the drop-down list, then note the value reported. In this instance, the value is
/O=Compaq/OU= NSIS European Messaging Team
You can see that the Exchange 2000 attribute preserves the legacy of the Exchange Server 5.5 naming convention, which lists the name of the organization followed by the name of the site.
After adjusting the legacyExchangeDN values, you can proceed with restoring the database. Dismount the database on the recovery server. Restore the backup set from the original server to overwrite the database files on the recovery server's disk.
Check the Application event log to ensure that the backup utility or Extensible Storage Engine (ESE) hasn't reported a problem and that the Store has been able to mount the restored database. The most common reason for a failed restore is that the name of the database in the backup set doesn't match the name of the target database as shown in ESM. The most common reason for the Store failing to mount the database after the restore successfully creates the database is that the legacyExchangeDN values of the restored and target databases don't match.
In either case, the Store signals the errors in the Application event log with event ID 1088: The information store could not be loaded because the distinguished name—DN—of message database /O=old_org_name/OU=old_site_name/CN=RECIPIENTS/CN= does not match the DN of directory /O=new_org_name/OU=new_site_ name/CN=RECIPIENTS/CN=.
Associating Accounts with Mailboxes
I now have a mounted database that contains the mailboxes that I want to access, but I still need to associate them with AD accounts before I can use a client to open a mailbox and retrieve information. Remember that mailboxes are attributes of AD accounts rather than entities in their own right. Without an association with an AD account, a mailbox is a repository that you can see through ESM but can't access with a client or other program.
You must perform two steps to link accounts with mailboxes. First, you must create the AD accounts (the names that you use don't have to match the names of the original accounts).
Second, you link the new accounts to mailboxes in the restored database. The easiest way to associate mailboxes with accounts is to use ESM's Mailbox Cleanup Agent. To invoke the agent, open the mailbox Store, select Mailboxes, right-click to view the context-sensitive menu, and select Run Cleanup Agent. The Mailbox Cleanup Agent scans a mailbox Store to look for mailboxes that don't have a link to an AD account, and the agent marks with an X in a red circle any mailboxes that it can't resolve.
Figure 5 shows what you might see after running the agent—all the mailboxes are visible, but the ones marked as unassociated don't show a valid account in the Last Logged on By column. This result implies that the Mailbox Cleanup Agent was unable to resolve against the AD the SID of the account last used to access the mailbox, which means that no link exists between the mailbox and an AD account.
You can right-click a mailbox and select the Reconnect option to link the mailbox to an AD account. If you need to connect many mailboxes, you can use the Mbconn utility from the \support\utils\i386 folder on the Exchange 2000 CD-ROM. (For more information about Mbconn, see the Microsoft article "XADM: How to Use the Mbconn Utility to Generate Active Directory Accounts for Information Store Mailboxes," http://support.microsoft.com/?kbid=271886.) Mbconn identifies the mailboxes in the Store that don't have an associated AD account and generates an LDAP Data Interchange Format (LDIF) load file with details of the missing accounts. You can then use the Ldifde utility to process the LDIF file to recreate the accounts, then run Mbconn again to reconnect the accounts with the mailboxes.
After you connect accounts to mailboxes, you can use a client to log on to a mailbox and access the content. Default Exchange 2000 permissions block administrator access to mailboxes, so if you want to use your account to access a mailbox, you must first change the permissions on the mailbox to give your account access. If you want to recover information for a user, you can select it from the mailbox and copy it to a PST. You can use the ExMerge utility to recover data for multiple mailboxes at one time.
The Recovery Timeline
The amount of time needed to perform the different steps to restore and access a mailbox Store on a recovery server depends on the size of the database, the backup technology you use, and the amount of data you need to retrieve after the restore is complete. Use the time estimates that Table 1 lists as a guideline, but remember that you should test the estimates in your own environment. For a list of and links to Microsoft articles about Exchange 2000 backup and recovery, see the Web-exclusive sidebar "Related Articles," http://www.exchangeadmin .com, InstantDoc ID 27489.
Recovering a database to another server isn't particularly difficult if you have the right hardware and software environment in place. Remember to clean up the server by deleting all the databases and logs after recovery operations are complete. Keeping confidential mailbox data on a server that other administrators might access isn't a good idea, especially if they can use relatively low levels of privileges to open the mailbox Store with clients.