Chapter 11. Backup, Restore, and Recovery
Introduction
Understanding how to back up and restore the Exchange data on your servers is critically important. If you don’t ensure that your public and private information stores, and Exchange’s configuration data are backed up on a regular basis, you could end up losing business-critical data—which can lead to some very uncomfortable conversations, at best. Unfortunately, too many administrators wait until disaster strikes to hone their backup and recovery skills. The time to understand the mechanics of backing up and restoring your servers is before you have a major failure that necessitates reloading your data from backup.
Often, the most important thing to do when faced with disaster recovery is to relax, and think the situation through clearly before beginning. Ensure that you have all of the media you will need for software installation (including third-party products, like Exchange-aware anti-virus software), and that you understand the task you are undertaking. There is no shame in calling Microsoft Product Support Services (PSS) for help; the cost of the call is easily offset by the confidence you will gain and improved speed with which you’ll be able to get the restore process completed.
The basics of disaster recovery for Exchange really haven’t changed through the various releases of the product; the main difference between Exchange 2000 and 2003 and older versions of the product is that Exchange no longer hosts its own directory—Active Directory (AD) holds almost all Exchange-related configuration data, and being AD savvy and understanding Exchange’s dependency upon AD counts for a lot when you’re faced with restoring an entire Exchange server from scratch.
We described some of the inner workings of Exchange’s Extensible Storage Engine (ESE) database engine in the Introduction in Chapter 6. From a backup and recovery perspective, there are several important consequences of the way ESE works; you have to understand these to make appropriate choices about your backup and recovery procedures. The key items about ESE’s architecture to remember are that:
The EDB and STM files for any mounted database will be held open as long as that database is mounted. That means that copying the open file is not guaranteed to yield a complete and consistent copy. For example, let’s say that someone sends you a 5 MB PowerPoint presentation. The first 4.9 MB of the attachment have been written to the store, and then the file is copied before the last 100 KB is written. Even if the copy appears to be complete, you will be left with missing data. You need to ensure that your backup solution works on open databases and understands the transactional nature of Exchange databases.
A single transaction log file (known as a generation) is open for each storage group at any one time. When a log file reaches its maximum size of 5 MB, it’s closed and a new generation is allocated. Older generations of log files remain present until they’re purged. This is desirable, since the log generations allow older transactions to be played back during a recovery; however, the log files do need to be backed up. During a full, or normal, online backup (as described later in this introduction), Exchange-aware backup software freezes the checkpoint file for the storage group, which enables the information store to note which transactions have been committed to the database at the time the backup began, and leaves the checkpoint in place until the backup completes. Once the backup completes, any new generations are also backed up during the operation. The generations that were committed to the database prior to the start of the full backup, and the generations that were backed up individually, are then purged from the file system. These operations are further discussed in the “Backup Types: Full, Incremental, and Differential” section of this introduction.
Online, Offline, and Point-in-Time Backups
Since the EDB and STM files are kept open by the database engine, it’s reasonable to ask how they can be backed up. One way is to dismount the databases you want to back up, or the storage groups to which they belong, then copy or back up the files. This approach is called an offline backup . You can perform these backups either by stopping the Exchange information store service (which dismounts all databases on the server) or by dismounting individual storage groups. Of course, during the time that these databases are dismounted, users won’t be able to access their mailboxes. Restoring these backups can be tricky (as described in MS KB 296788, Offline Backup and Restoration Procedures for Exchange), so we normally don’t recommend them as a part of your backup/restore processes. The exception is when you’re making a major change to the server, like installing low-level software (say, a virus scanner or a Windows service pack). In that case, you should probably plan on making a complete offline backup right before you make the change, just in case the change breaks something and you need to back out.
As a better alternative to offline backups, Microsoft provides an API for performing Exchange online backups. Backup programs that use this API are said to be Exchange-aware; by using the API they can read pages from the Exchange database files while the files are open. This permits you to back up databases while users continue to send and receive messages; you can restore individual databases without affecting users whose mailboxes are in other storage groups on the same server. The API also permits a compliant backup program to simultaneously back up or restore one database from each active storage group; this allows you to parallelize backups or restores by using one tape drive or disk volume for each storage group and backing up or restoring to all of them at once. The online backup API is mature, thoroughly tested, and able to handle a variety of edge cases properly, such as when new transactions come in while the current generation is being backed up, and when two generations’ worth of transactions occur during backup.
Some vendors (notably EMC, HP, and VERITAS) offer snapshot backups that freeze a point-in-time copy of the data in an Exchange database. Without delving into the differences between specific products, all of these products are supported by Microsoft only as offline backups. That doesn’t mean that you can’t use them, it just means that these solutions aren’t directly supported by Microsoft. MS KB 311898 (XADM: Hot Split Snapshot Backups of Exchange) provides a brief overview of snapshot and hot split backups, and has this to say:
This does not mean that you cannot perform hot split and other snapshot backups safely and successfully. However, the backup solution vendor or Exchange administrator is responsible for making sure that all of the required files are backed up and restored correctly. The backup solution vendor or Exchange administrator is also responsible for making sure that the integrity of all of the files is preserved at each stage of the process.
If you implement a snapshot or hot split backup solution for Exchange, your vendor is your primary support provider for backup and recovery issues. Microsoft Product Support Services (PSS) can help you diagnose or analyze issues with the available database and transaction log file sets. However, Microsoft does not test, certify, or debug scripts and procedures for hot split backups or snapshot backups of Exchange data files. Microsoft PSS assistance is limited to advice about how to best continue to recover the available file set.
For Exchange Server 2003 running on Windows 2003, there’s an alternative method of making point-in-time copies; the Windows Volume Shadow Copy Service, or VSS. VSS is a system service that ties together applications, backup, or utility programs, and hardware to provide a safe method for creating point-in-time copies. With VSS, here’s what happens:
The administrator initiates a backup using a VSS-aware backup program. The “VSS-awareness” of this program comes about when the vendor creates a component known as a requestor ; the requestor’s job is to use the VSS interfaces to tell VSS-aware applications what data is to be backed up.
VSS accepts the request from the requestor and looks through its list of registered applications for one that matches. Each application that wants to be visible to VSS, like Exchange, SQL Server, or Oracle, has to include a VSS writer . The writer’s job is to take whatever application-specific actions are required to prepare the application’s data to be safely copied.
VSS notifies the Exchange writer that it needs to get things ready. The writer responds by calling VSS again, asking it to freeze pending write requests for the volumes “owned” by Exchange. Pending reads can still complete, as can any writes that are already in progress; new writes are held in a queue. The writer can initiate this freeze across multiple volumes—a necessary refinement for Exchange, since logs and databases are usually stored on separate volumes.
Once VSS has frozen I/O for all the target volumes, it notifies the writer, which can then perform any necessary cleanup operations like closing log files, flushing caches, and so on to temporarily quiesce the database so it can be safely copied.
When the writer’s finished its work, the application signals VSS, which gives the go-ahead to the requestor. The requestor can then copy the data itself (using the default copy-on-write provider included with Windows Server 2003), or it can tell VSS to use a specific provider, like those provided by various SAN hardware vendors.
When the provider is finished copying data, it notifies VSS, which then unfreezes I/O to the source volumes and notifies the writer to proceed with normal operations.
As we write this, there are still very few vendors outside of Microsoft that are shipping stable VSS-aware products. However, most major backup vendors (including VERITAS, Computer Associates, and CommVault) support VSS, as do many SAN hardware vendors. At the time of this writing, VSS implementations for Exchange have not been widely produced. Until this technology becomes more mature, and more vendors provide solutions based on VSS, we’re sticking with full, online backups for our Exchange servers.
Backup Types: Full, Incremental, and Differential
Earlier in this section, we mentioned that transaction logs must periodically be purged. Assuming you don’t have circular logging enabled, you shouldn’t do this manually; the supported way of purging the logs is to back up the log files themselves. When you perform an online backup with a program that supports the Exchange backup API, the log files may or may not be purged, depending on the type of backup you’ve specified. Understanding the backup types is thus critical to knowing how to ensure that the log files are backed up. (Before reading the remainder of this section, you may find it useful to revisit the Introduction in Chapter 6 on how incoming transactions are logged.)
Full backups are the easiest type of backup to understand. When you perform a full online backup on an Exchange database, the database is backed up in its entirety, but the logs remain untouched. When you perform a full backup of a storage group, all of the databases are backed up, and the log files are truncated—their transactions are committed, and the transaction log files are removed from the disk. To restore a full backup, all you need is the full backup itself—if you restore your Monday full backup, you only need the Monday tape to roll back to that point in time.
Incremental backups capture only pages within the database that have changed since the most recent full backup; they do this by backing up (and then removing) all log files generated since that backup. This tends to make these backups small and fast, but the consequence is that you can’t do a complete restoration using only incremental backups—you must first restore the full backup, and then restore each incremental backup that you have, in the correct order. Let’s say you adopt the common approach of taking a full backup weekly (say, on Sunday) and incrementals daily. If you want to restore to the system state on Wednesday, you need the Sunday full backup and the Monday, Tuesday, and Wednesday incrementals. If you don’t have the Tuesday tapes, you will only be able to restore the Monday state; you can’t play back transaction logs that were generated after a missing or corrupt earlier generation.
Differential backups are a hybrid of full and incremental backups. They accumulate all transactions since the last full backup, but they don’t purge the log files when the backup is completed. If you combine a weekly full backup with daily differentials, each differential will be larger than the preceding day’s backup, but you only need a particular day’s differential plus the full. In the Sunday scenario described earlier, to restore to Wednesday’s state, you’d need the Sunday full backup and the Wednesday differential.
What backup type should you use? It depends on how much time you can afford to take for backup and restore operations, and the capacity of your storage media and devices. For example, if your backup hardware requires 12 hours to make a full backup of your current databases, but only two hours for an incremental backup (on average, of course), you’d probably find that a weekly full, combined with daily incrementals, would give you adequate protection. However, you must factor in restore times.
Let’s say your goal is to restore a failed database within four hours. That means that, within a four-hour window, you need to locate all the needed backup media, start the backup, wait while the backed-up data are retrieved from tape or disk, and then wait while the logs are played back and the database is mounted. The largest portion of time will be spent reading the data from tape. If you can restore 10 GB per hour, then you can restore a maximum of between 20 and 30 GB during your four-hour window. You might be able to cut that time by splitting larger databases into smaller ones, redistributing mailboxes between servers, or using different backup hardware.
11.1. Backing Up an Individual Mailbox
Problem
You need to back up one or more mailboxes without backing up the databases that contain them.
Solution
Using a graphical user interface
Download the ExMerge utility from the Exchange Server 2003 tools page (http://www.microsoft.com/exchange/downloads/2003.asp). You can use this version of ExMerge with any version of Exchange, but you must run it on an Exchange Server 2003 server or a machine with the Exchange Server 2003 version of ESM installed. Install it according to the directions in the Mailbox Merge Wizard (ExMerge) documentation.
Launch ExMerge. At the welcome screen, click Next.
Select the Extract or Import (Two Step Procedure) radio button on the Procedure Selection page and click Next.
On the Two Step Procedure page, make sure the Step 1: Extract data from an Exchange Server Mailbox radio button is selected and click Next.
On the Source Server page, supply the name of the Exchange server where the mailbox is housed. You can optionally specify a DC and port number to use when looking up the account of the user whose mailbox you’re backing up; doing so speeds up name resolution somewhat.
Click the Options button; this displays the Data Selection Criteria dialog box.
On the Data tab, make sure that all of the checkboxes are marked if you want to back up all contents of the mailbox, including hidden items like rules and items in the “dumpster” (the container used to hold items after they’re removed from Deleted Items until the retention period is reached).
Optionally, on the Folders tab, you can specify folders you want skipped. You might, for example, exclude the Sent Items or Deleted Items folders.
Optionally, use the Dates tab to set a date range for the backup. By default, all messages in the mailbox will be included.
Optionally, use the Message Details tab to tell ExMerge that you only want messages that have specified subjects or attachment names. This option was originally introduced to allow you to mass-remove messages infected with the ILOVEYOU and Melissa viruses, but it can come in handy in other circumstances too.
Once you’ve set up the selection criteria you want, click OK to dismiss the Data Selection Criteria dialog box, and then click Next.
On the Database Selection page, select the databases that contain the mailboxes you’re backing up, and then click Next. Be prepared to wait a minute while ExMerge gathers the list of mailboxes in those databases.
On the Mailbox Selection page, select the mailboxes you want to back up and click Next.
On the Locale Selection page, pick the locale you want ExMerge to use when it connects to the mailbox. If you choose a specific locale when you’re importing mailboxes, the standard folders (Inbox, Tasks, Calendar, Sent Items, Deleted Items, Journal, and Notes) will be created with names in that locale’s language. For mailbox backups, you should check the Use last mailbox login locale checkbox to ensure that a consistent locale is used. Click Next.
On the Target Directory page, select the folder where you want the extracted mailbox data to go. Each mailbox’s data will be placed in a separate Outlook personal folders (PST) file. Click Next.
On the Save Settings page, you may optionally choose to save the current settings, which you can then use in the future.
Click Next to actually start backing up the mailboxes. Click Finish once ExMerge finishes.
Take the PST files generated by ExMerge and back them up using your preferred backup method.
Discussion
Individual mailbox backups (also known as “brick-level” backups) are a hassle for two primary reasons. First, they’re slow. All existing mailbox-level backup tools use MAPI, which means that they’re pokey compared to ordinary backups. Second, they’re bloated. When you do a brick-level backup, the backup utility has to back up every message in the mailbox, and single instance storage can’t be maintained across multiple mailboxes. That means that backing up two mailboxes with many messages in common can require nearly twice as much space as the equivalent amount of data in a database backup.
The bigger issue is that, for most purposes, they’re unnecessary. The three most common cited reasons for doing brick-level backups already have other, easier-to-use alternatives:
If your user accidentally deletes an item they need, they can recover it themselves provided that you’ve turned on deleted item retention (see MS KB 822938).
If you accidentally delete a mailbox, you can recover it from the deleted mailbox retention container, as described in Recipe 5.9. In Exchange Server 2003, you can use the Mailbox Recovery Center (see Recipe Recipe 11.10).
If the mailbox becomes damaged or corrupted, you can restore it from an ordinary backup using the instructions in Recipe 11.8.
Accordingly, Microsoft doesn’t provide direct support for mailbox-level backups in their own backup tool; most third-party backup vendors include it.
See Also
Recipes Recipe 11.2 and Recipe 11.3 for backing up database and storage groups, Recipe 11.8 for recovering one mailbox from a database or storage group, and Recipe 11.10 for using the Mailbox Recovery Center
11.2. Backing Up a Database
Solution
Using a graphical user interface
Start the Windows Backup (Ntbackup.exe) utility. If you see the Backup and Restore wizard start page, click the Advanced Mode link.
Click the Backup tab.
Use the Backup destination and Backup media or file name controls to specify where you want the backup to go.
Tip
The options you see here will vary, depending on whether you have a tape drive with Windows drivers installed or not. For example, one Exchange server in our lab has an ADIC FastStor tape library attached; no tape drives appear in NTBackup, so we have to back up files and then use a separate third-party tool that understands tape libraries to put them to tape.
In the left pane of the Backup window, expand the Microsoft Exchange Server node. Beneath it, you’ll see one entry for each Exchange server:
Mark the Microsoft Information Store checkbox to back up all storage groups on the server, or
Expand Microsoft Information Store and check off the individual storage groups you want to back up. (Note that storage groups with no mounted databases will appear here, but if you try to back them up, the backup process will fail).
From the Microsoft Exchange Server node, select the storage group that contains the database that you want to back up.
In the right pane of the Ntbackup window, select the databases you want to include in this backup job.
Click Start Backup.
In the Backup Job Information dialog box, give the backup job a description. Optionally, use the Schedule button to schedule the backup to occur at a later time.
Click the Advanced button and use the Backup Type drop-down to select the backup type you want. By default, it will be a full backup. Click OK.
Click Start Backup to begin the backup. The Backup Progress dialog will appear to show what’s going on.
When the backup completes, review the backup report (backup*.log, which can be found by using the Tools → Report option within Ntbackup) and the application event logs to look for errors.
Using a command-line interface
Create a text file with the extension .bkf containing the names of the databases you wish to back up:
JET servernameMicrosoft Information StoreFirst Storage GroupMailbox Store1 JET servernameMicrosoft Information StoreFirst Storage GroupMailbox Store2 JET servernameMicrosoft Information StoreFirst Storage GroupPublic Folder Store (servername) JET servernameMicrosoft Information StoreSecond Storage GroupMailbox Store3
Run NTBackup from a command line, specifying the options file and backup target file:
> ntbackup BACKUP "
<@X:pathfilename.bks>" /f "<X:path arget.bkf>"To see the options that the NTBackup command take, run the command:
> ntbackup /?
Discussion
When you use Ntbackup as described earlier, you get an online backup of the selected databases. You’ll usually want to back up entire storage groups (as described in Recipe 11.3) at one time, so that your transaction logs will be flushed, but from time to time you may want to back individual databases up by themselves. See the Introduction for an overview of what an online backup entails.
See Also
Recipe 11.3 on backing up a storage group, and Recipes Recipe 11.4 and Recipe 11.5 on restoring databases and storage groups
11.3. Backing Up a Storage Group
You need to back up all databases in a storage group to backup media or files.
Solution
Using a graphical user interface
Start the Windows Backup (Ntbackup.exe) utility. If you see the Backup and Restore wizard start page, click the Advanced Mode link.
Click the Backup tab.
Use the Backup destination and Backup media or file name controls to specify where you want the backup to go.
Tip
The options you see here will vary. See the note in Recipe 11.2.
In the left pane of the Backup window, expand the Microsoft Exchange Server node. Beneath it, you’ll see one entry for each Exchange server:
Mark the Microsoft Information Store checkbox to back up all storage groups on the server, or
Expand Microsoft Information Store and check off the individual storage groups you want to back up. (Note that storage groups with no mounted databases will appear here, but if you try to back them up, the backup process will fail).
Click Start Backup.
In the Backup Job Information dialog box, give the backup job a description. Optionally, use the Schedule button to schedule the backup to occur at a later time.
Click the Advanced button and use the Backup Type drop-down to select the backup type you want. By default, it will be a full backup. Click OK.
Click Start Backup to begin the backup. The Backup Progress dialog will appear to show what’s going on.
When the backup completes, review the backup log to look for errors.
Using a command-line interface
Create a text file with the extension .bkf containing the names of the storage groups you wish to backup.
JET servernameMicrosoft Information StoreFirst Storage Group JET servernameMicrosoft Information StoreSecond Storage Group
Run NTBackup from a command line, specifying the options file and backup target file:
>ntbackup BACKUP "
<@X:pathfilename.bks>" /f "<X:path arget.bkf>"To see the options that the NTBackup command take, run the command:
>ntbackup /?
Discussion
This procedure is essentially the same as the one described in Recipe Recipe 11.2; the biggest difference is that it is going to take longer, since you are backing up all private message stores as well as any public messages stores in the storage group. This is the preferred method for backing up your Exchange Servers, and should be done on a nightly basis, or in conjunction with differential or incremental backups. If you neglect to back up your storage groups on a regular basis, you may end up running out of disk space, as your transaction log files will not be purged from the file system.
See Also
Recipe 11.2 for backing up a single message store, and Recipes Recipe 11.4 and Recipe 11.5 for restoring message stores and storage groups
11.4. Restoring One or More Databases to the Same Server
Problem
You need to restore one or more databases that were individually backed up from backup media or files.
Solution
Using a graphical user interface
If the database is currently mounted:
Launch Exchange System Manager.
Navigate to the appropriate server and storage group.
Right-click the database to be restored and use the Dismount Store command. Confirm the command when prompted.
Launch the Windows Backup utility (Ntbackup.exe) and ensure that it is in Advanced mode.
Click the Restore tab.
In the left Ntbackup pane, find the backup media or file that contains the database copy you want to restore, then select it.
In the right Ntbackup pane, select the specific database that you want to restore.
Navigate down to the specific storage group that contains the mailbox store that you are going to restore and mark its checkbox, then click Start Restore.
The Restoring Database Store dialog box will appear. Select the name of the server you’re restoring to. In this case, you’re using the local server, which will already be selected by default. Next, enter a path for the location of the log and patch files. Ntbackup will put the files it restores here until it’s ready to remount the restored database. Make sure that the directory you specify is on a volume with enough free space to hold the data you’re restoring.
If the backup you’re restoring is a full backup with no further backups after it, or the last backup in a series of differential or incremental backups, check the Last Restore Set and Mount Database After Restore options. If you still have to restore other backups after this one, leave both of those checkboxes blank.
Click OK.
If the Enter Backup File Name dialog box appears, fill in the name of the backup file you’re restoring from, then click OK.
The Restore Progress dialog box appears. If any errors occur, you’ll see them; when the restore finishes, you can dismiss the dialog with the Close button or view a detailed report of the restore with the Report button.
If you are restoring additional databases or if there are additional backup sets to restore, repeat steps 4 through 11 for each one. When you’re restoring the last database, be sure to select the Last Restore Set and Mount Database After Restore checkboxes in step 8. The information store won’t play back the transaction logs or remount the new database unless you do this.
Launch ESM and verify that the databases have been mounted properly (or mount them yourself if you didn’t check the Mount Database After Restore checkbox).
Use ESM, Outlook Web Access, or Outlook to verify that the mailboxes or public folders are present and that the contents of the mailboxes are correct.
Use Event Viewer to verify that the databases have been cleanly mounted.
Discussion
When you do an online restore of a single database, the Exchange information store doesn’t automatically mount the database unless you tell it to. Unless all transaction logs are present, the mount will fail anyway, so Exchange doesn’t attempt the mount until you specify that all logs have been restored. This is a feature, not a bug. If you have to restore more than one database from the same storage group, or if you’re restoring incremental or differential backups after restoring a full backup, those backups will contain logs that are necessary to restore the databases to their original states.
As a bonus, after restoring a database, you can check its integrity or repair it using the Isinteg and Eseutil tools, as described in Chapter 6. Depending on your backup subsystem, and how often you perform backups, it may actually be faster to restore a backup and play back logs to recover it to the latest possible state than to use Eseutil and/or Isinteg to try to fix the database in situ. Of course, you’ll have to be quite familiar with your recovery procedures and capabilities before you can make this determination.
See Also
Recipe 11.2 on backing up a database, Recipe Recipe 11.5 on recovering a storage group, Recipe Recipe 11.11 on using the Recovery Storage Group (RSG), and MS KB 238063 (How to Do an Online Restore of an Exchange Cluster Server)
11.5. Restoring a Storage Group to the Same Server
Solution
Using a graphical user interface
Using the Exchange System Manager, navigate to the appropriate server and storage group.
Dismount the mailbox stores that you are going to restore by right-clicking each storage group and using the Dismount Store command.
Start the Windows Backup utility and ensure that it is set to Advanced mode.
Select the Restore tab.
Select your backup media or file.
In the left Ntbackup pane, find the backup media or file that contains the database copy you want to restore, then select it.
In the right Ntbackup pane, select the specific database that you want to restore.
Navigate down to the specific storage group that contains the mailbox store that you are going to restore and mark its checkbox, then click Start Restore.
The Restoring Database Store dialog box will appear. Select the name of the server you’re restoring to. In this case, you’re using the local server, which will already be selected by default. Next, enter a path for the location of the log and patch files. Ntbackup will put the files it restores here until it’s ready to remount the restored database. Make sure that the directory you specify is on a volume with enough free space to hold the data you’re restoring.
If the backup you’re restoring is a full backup with no further backups after it, or the last backup in a series of differential or incremental backups, check the Last Restore Set and Mount Database After Restore options. If you still have to restore other backups after this one, leave both of those checkboxes blank.
Click OK.
If the Enter Backup File Name dialog box appears, fill in the name of the backup file you’re restoring from, then click OK.
The Restore Progress dialog box appears. If any errors occur, you’ll see them; when the restore finishes, you can dismiss the dialog with the Close button or view a detailed report of the restore with the Report button.
If you are restoring additional databases or if there are additional backup sets to restore, repeat steps 4 through 11 for each one. When you’re restoring the last database, be sure to select the Last Restore Set and Mount Database After Restore checkboxes in step 8. The information store won’t play back the transaction logs or remount the new database unless you do this.
Launch ESM and verify that the databases have been mounted properly (or mount them yourself if you didn’t check the Mount Database After Restore checkbox).
Use ESM, Outlook Web Access, or Outlook to verify that the mailboxes or public folders are present and that the contents of the mailboxes are correct.
Discussion
This procedure is essentially the same as the one described in Recipe Recipe 11.4. The biggest difference here is that restoring a storage group will, by default, restore the transaction logs for all databases in the group. That’s OK, because each transaction includes a unique identifier that allows the store to tell when a replayed transaction has already been posted. The biggest difference in these procedures is that restoring the entire storage group can take quite a bit longer.
Microsoft says that you should only perform one online recovery at a time. This is somewhat of a semantic issue, though. The actual restriction is that only one set of transaction logs can be replayed at a time. By specifying different temporary paths for different restore jobs, and making sure that the Last Restore Set and Mount Database After Restore checkboxes are off, you can reload multiple storage groups—but then you’ll have to manually replay the logs for those storage groups as described in Recipe 6.12.
See Also
Recipe 11.3 on backing up a storage group, Recipe 11.4 on recovering a database, Recipe Recipe 11.11 on using the RSG, and MS KB 238063 (How to Do an Online Restore of an Exchange Cluster Server)
11.6. Restoring a Database to a Different Machine in Exchange 2000
Problem
The database from your original Exchange 2000 server needs to be restored, but the original Exchange server hardware cannot be used for the restore.
Warning
For best-practices disaster recovery, the original server that hosted the database should be used as the recovery point; this recipe should only be used as a last resort. However, this procedure is very useful to perform test restores to retrieve a point-in-time database state, or recover information without affecting the production server.
Solution
Using a graphical user interface
Reset the machine account for the old server:
Start the Active Directory Users and Computers (ADUC) snap-in.
Find the old Exchange server’s computer account (its location will depend on whether you have your Exchange servers segregated by OU or domain).
Right-click the computer account and use the Reset command.
Build the replacement server. It must have the same version of Windows (with the same service pack) and the same name as the original server.
Log on to the replacement server using an account that has Exchange Full Administrator rights.
If necessary, install any Windows hotfixes that were present on the old server.
If necessary, configure the disks or arrays on the new server so that drive letter and partition assignments match those on the old server.
Ensure that the SMTP and NNTP components of IIS are installed on the new server (see Recipe 2.2).
Reinstall Exchange with the
/disasterrecoveryswitchInstall the same Exchange service pack that was installed on the original server using the
/disasterrecoveryswitch.Install any Exchange hotfixes that were installed on the original server.
Make sure that the legacyExchangeDN attribute matches the value from the original server. You can use the LegacyDN utility from the Exchange 2000 SP1 or later CD.
Using your backup software, restore the storage groups and their associated database files to the same locations used on the original server. Remember to tell the backup software when you’ve loaded the last backup set for each so that it can play back the transaction logs.
If you were using full-text indexing on the original server, recreate the indexes on this server:
Launch Exchange System Manager.
Expand the server object for the server you’re restoring, then find the mailbox databases you just restored.
Right-click each mailbox database and use the Create Full-Text Index command.
Specify the location where you want the index files (ideally, not the volumes you’re using for your databases or transaction logs), then click OK.
Discussion
As long as your AD is intact, you can recover from the loss of
an Exchange server by using the /disasterrecovery switch during the
reinstallation process. Before beginning this process, use Exchange
System Manager to verify that the server object still exists.
The /disasterrecovery switch
tells the setup program to reclaim configuration data such as storage
group names, mailbox store names, and virtual server configuration
settings from AD. Reinstalling in this mode ensures that the databases
will not mount immediately after the installation is complete—this is
important, as you will restore the database files (.edb and .stm) from the original installation’s
backup media in order to recover your data.
See Also
Recipe 2.2 for checking installation prerequisites, MS KB 323016 (Setup with DisasterRecovery Does Not Work on a Clustered Exchange Server), MS KB 296790 (Setup /disasterrecovery Does Not Detect Previously Installed Components), MS KB 297289 (How to Move Exchange 2000 to New Hardware and Keep the Same Server Name)
11.7. Restoring a Database to a Different Machine in Exchange Server 2003
Problem
The database from your original Exchange Server 2003 server needs to be restored, but the original Exchange server hardware cannot be used for the restore.
Solution
Using a graphical user interface
Ensure the old server is no longer present on the network.
Reset the old server’s computer account in Active Directory by going to Start → All Programs → Microsoft Exchange → Active Directory Users and Computers and browsing to the computer object, then right-clicking the computer object and selecting Reset Account from the drop-down list.
If Windows Server is already installed on the new server, rename the new server so it has the same computer name as the old server. If the new server does not yet have Windows 2003 installed, install Windows 2003 and, when prompted, give the new server the old server’s name.
Ensure that all Windows 2003 Service Packs and hotfixes on the new server are identical to the Service Packs and hotfixes installed on the old server.
Log on to the replacement server using an account that has Exchange Full Administrator rights.
Verify that the SMTP, NNTP, ASP.NET, and World Wide Web components of IIS are installed on the new server (see Recipe 2.3).
Launch Exchange Server 2003 setup with the
/disasterrecoveryswitch.Follow the instructions in Recipe 11.6, beginning with step 5.
Discussion
Exchange Server 2003 recovery is very similar to that of Exchange 2000. The primary difference between Recipe 11.6 and this recipe is simply the installation prerequisites.
See Also
MS KB 822945 (How to Move Exchange 2003 to New Hardware and Keep the Same Server Name), and Exchange 2003 Disaster Recovery Operations Guide
11.8. Recovering an Individual Mailbox from a Database Backup
Problem
A single mailbox was deleted from your Exchange server and is not available using deleted mailbox recovery; you have a backup from the time frame before the mailbox was deleted.
Solution
Using a graphical user interface
Prior to beginning the recovery process, check to see if you have set a retention period for deleted mailboxes:
Launch Exchange System Manager.
Browse to the mailbox store where the deleted mailbox used to live.
Right-click the mailbox store and select the Properties command.
Click the Limits tab. If the value in the Keep Deleted Mailboxes for (days) area in the Deletion Settings portion of the tab is greater than zero, and the mailbox was deleted within the number of days shown, you can use the method in Recipe 11.10 to retrieve the mailbox. The default deleted mailbox retention time in Exchange 2000 and 2003 is 30 days.
If the mailbox is not recoverable through deleted mailbox recovery steps, there are a few more hoops to jump through. If you are running Exchange Server 2003, follow the instructions in Recipe 11.11 to restore the backup to the RSG. If you are running Exchange 2000, follow the instructions in Recipe 11.6 within a non-production environment, including a domain controller moved from production into the offline environment. Then you can proceed to actually recover the mailbox.
Create a user account in your nonproduction AD with the Active Directory Users and Computers snap-in; when prompted, assign a username and password that you’ll remember. Leave the Create an Exchange Mailbox checkbox blank; this account should not be mail-enabled.
Launch Exchange System Manager and browse to the mailbox store within the RSG (or the nonproduction store on the recovery server, if you are using Exchange 2000) you created in step 1 of this recipe. If the mailbox that you need to restore does not have a red X on its icon, run the Mailbox Cleanup Agent. Right-click the Mailboxes object and choose Run Cleanup Agent from the list. This will disassociate the mailbox with its original user object in AD.
In the open Exchange System Manager console, right-click the mailbox you need to restore and click Reconnect; select the user account created in step 2 of this recipe as the connection point. Click OK.
Recover the data within the mailbox:
Use an Outlook client to connect to the mailbox and export the data to a PST file using File → Import and Export and choosing the Export to a File option. Click Next. Select Personal Folder File (.pst) from the list of options. Click Next. Select the top-level Mailbox object and check the Include Subfolders box; click Next. Choose where you want the data archived on the recovery server.
Use the Exchange Mailbox Merge (ExMerge) tool to export the contents of the mailbox to a PST file by following the instructions in Recipe 11.1. (You can use ExMerge in two-step mode and immediately import the PST into the live information store.)
If you are using Exchange 2000 and needed to restore the database to an alternate server, you will need to follow these steps; if you are using Exchange Server 2003, proceed to step 8:
Shut down and disable all Exchange-related services on the recovery server by going to Start → Administrative Tools → Services. Right-click each item that begins with Microsoft Exchange in the Services console and select Stop. Then right-click each item that begins with Microsoft Exchange and select Properties from the drop-down list; change the Startup type area to Disabled and click OK.
If you used the same server name that is used on the production server for the recovery server, rename the recovery server with a name that is not in use on the production network.
Connect the recovery server to the production network.
For both:
Import the PST file with the mailbox contents to the appropriate mailbox on the production server by opening the mailbox in Outlook and selecting File → Import from the menu.
Discussion
This recipe addresses how to recover a deleted mailbox in either Exchange 2000 or Exchange Server 2003. The RSG in Exchange Server 2003 makes this process much simpler, as you do not need to pull a domain controller offline, and you also do not need to set up a nonproduction Exchange server to do the recovery.
See Also
MS KB 824126 (How to use Recovery Storage Groups in Exchange Server 2003); MS KB 823176 (Recover or Restore a Single Mailbox in Exchange Server 2003); Exchange 2003 Disaster Recovery Operations Guide (http://www.microsoft.com/technet/prodtechnol/exchange/2003/library/disrecopgde.mspx); the Exchange Mailbox Merge Wizard (ExMerge) tool.
11.9. Performing Disaster Recovery of a Cluster Node to a Nonclustered Server
Problem
Your clustered Exchange server is down. While you restore it, you want to offer service using its databases on a regular, unclustered node.
Solution
Using a graphical user interface
Use ADSI Edit to remove the cluster’s AD object:
Launch ADSIEdit.msc.
Expand the forest configuration container.
Expand the container for the administrative group that contains the clustered server (it’ll be located under
CN=Services, CN=Microsoft Exchange,CN=Administrative Groups).Expand the Servers container in the AG.
Right-click on the target server and use the Delete command. When ADSI Edit prompts you to confirm the deletion, click Yes.
Remove mailbox attributes from the user accounts whose mailboxes were on the former server:
On the Exchange server or on a computer with the Exchange Management tools installed, launch the ADUC snap-in.
Make sure that the advanced features mode is on (use the View→ Advanced Features command to toggle it if necessary).
Select the users whose mailbox attributes you want to remove. You can select them one at a time or by using the standard Windows selection modifier keys.
Right-click the user and use the Exchange Tasks command to start the Exchange Task Wizard.
In the Available Tasks window, select Remove Exchange Attributes and click Next.
In the Remove Exchange Attributes window, click Next to indicate your understanding of the tool’s dire warnings.
Click Finish.
Build the new server, using the same name as the cluster’s virtual server and the same version (and service pack level) of Windows.
Install Exchange on the new server, but don’t use the
/disasterrecoveryswitch.After Exchange is installed, create storage groups and databases whose names and locations match what was on the original server.
Restore your databases from a backup (or copying them from the original server or SAN).
Mount the databases and check the event log to verify that there were no errors.
Reconnect the restored mailboxes to their users using the Mbconn utility (described in Recipe 11.13).
Discussion
While it’s rare that you’ll want to restore a database from a clustered server to a non-clustered server, the need to do so might occur, especially in cases where you simply do not have enough hardware to replace your clustered servers. Whenever possible, it’s best to restore Exchange databases to the original hardware configuration they used.
11.10. Using the Exchange Server 2003 Mailbox Recovery Center to Recover a Mailbox
Problem
You have multiple disconnected or deleted mailboxes on an existing, mounted mailbox store and you need to recover them, or you have multiple mailboxes whose properties you need to export to an AD container or LDIF file.
Solution
Adding mailbox stores to the Mailbox Recovery Center
Launch the Exchange System Manager.
Expand the Tools node to display the Mailbox Recovery Center.
Right-click on Mailbox Recovery Center and select Add Mailbox Store. You can add multiple stores at the same time.
Enter a partial or whole mailbox store name in the selection dialog, then click Check Names. If there are multiple stores that match, you will be prompted to select one or more of them. Click OK when you have selected the desired stores.
Click OK to add the selected stores to the Mailbox Recovery Center.
The Details pane should now display a listing of any deleted or disconnected mailboxes in your selected stores.
Since ESM is an MMC application, you can customize the columns displayed in the details pane to provide specific information. Either right-click on Mailbox Recovery Center and select View, or select the View menu. Choose the Add/Remove Columns option.
Select the various columns that you want displayed. Click OK to apply your choices.
Recovering mailboxes with the Mailbox Recovery Center
Launch the Exchange System Manager.
Expand the Tools node to display the Mailbox Recovery Center.
Ensure that the desired mailbox stores have been added.
Select one or more mailboxes to recover. You can use Shift to select a range or Ctrl to make multiple selections.
Right-click and select Find Match.
The Exchange Mailbox Matching Wizards starts. Click Next to continue and allow Exchange to automatically attempt to find matching accounts for the selected mailboxes.
When the results are displayed, examine the matching operations that were successful and those that raised a conflict.
Click Finish to close the wizard.
Select the mailboxes that were not successfully associated. Right-click and select Resolve Conflicts.
When the Exchange Mailbox Conflict Resolution Wizard starts, click Next.
The wizard will display a list of user accounts that could be matches for the selected mailboxes. If the desired account is not listed, click Browse and choose a user account. You will not be able to choose a user that already has a mailbox associated.
When the account is selected, click Next.
Click Next to complete the process and Finish to close the wizard.
Select the mailboxes that were successfully associated with user accounts.
Right-click and select Reconnect.
When the Exchange Mailbox Reconnect Wizard starts, click Next.
Review the proposed operations to ensure they are correct. If so, click Next to begin the recovery.
Review the report and note any conflicts or errors, then click Finish to close the wizard.
Exporting mailbox properties with the Mailbox Recovery Center
Expand the Tools node to display the Mailbox Recovery Center.
Select one or more mailboxes whose properties you wish to export. You can use Shift to select a range or Ctrl to make multiple selections.
Right-click and select Export.
You will be presented a list of AD properties to choose. These are properties of the user objects related to the selected mailboxes. By selecting these properties, you will be making copies of them in your Active Directory. Unless you want to do this, clear the selected properties.
Click Browse. You will be asked to select a container in AD to hold the exported properties selected in the previous step. Click OK.
Click Next.
You will be asked to provide a filename for the export data, which will be placed in a LDIF file. Click Browse to navigate the filesystem and specify the name and location of the file. The typical extension is .ldf.
You can choose to either append data to an existing file or overwrite it completely via the Append the Next Definitions or Replace Existing Content options respectively. Click Next to begin the export.
Click Finish to end the wizard.
Removing mailbox stores from the Mailbox Recovery Center
Expand the Tools node to display the Mailbox Recovery Center.
Right-click on Mailbox Recovery Center and select Remove Mailbox Store. You can add multiple stores at the same time.
Enter a partial or whole mailbox store name in the selection dialog. If there are multiple stores that match, you will be prompted to select one or more of them. Click OK when you have selected the desired stores.
Click OK to remove the selected stores from the Mailbox Recovery Center.
Discussion
The Mailbox Recovery Center is yet another new feature of Exchange Server 2003, and it gives you the ability to deal with multiple deleted or disconnected mailboxes at one time. In previous versions of Exchange, you had to recover them one by one.
The Recovery Center has some limitations, however, and many people confuse it with RSGs (see Recipe 11.11):
You can’t use it to recover mailboxes from other servers in the administrative group. All message stores must exist on and be mounted by the local server.
You can’t use it to recover mailbox data from backup sets.
You can’t use it to recover items on an individual basis.
What it does allow you to do is reassociate mailboxes with user accounts, so that you can access them with other tools and manipulate their contents. The mailboxes need to be physically present in the store to begin with (Exchange does not physically create a mailbox until the user account has logged in to Exchange for the first time or until mail has been sent to the recipient), and must still be physically present (not cleaned up via the default 30-day retention period).
The export capability is also very useful, as you can either put the information back into AD or into an LDIF file for manual examination and manipulation.
The Mailbox Recovery Center will not, by design, show healthy mailboxes. If you still have an empty Detail pane after adding a mailbox store, then you don’t have any deleted or disconnected mailboxes in that store.
See Also
Recipe 11.11 for using the RSG
11.11. Recovering to a Recovery Storage Group in Exchange Server 2003
Solution
Using a graphical user interface
Launch the Exchange System Manager.
Navigate to the server you will place the RSG on. Right-click, select New, and select RSG.
Set the name for the new RSG. If you are recovering from a storage group not already present on the server, you must set the name of the RSG to be the same as the name of the storage group you are recovering.
Provide the system path, as well as a path for the associated transaction logs. Make sure these locations have sufficient disk space and are not shared by other storage groups or transaction logs.
Right-click on the RSG and select Add a Database to Recover.
Select a database from those presented. If a database is already present in the RSG, you can only select other databases in the same storage group. Click OK.
Set the name for the database.
Provide paths and names for the database and streaming database files. These paths and names only need to match the original names if you are going to manually copy these files on top of the original database files after the recovery is complete.
When you are ready to perform the restore, ensure that the original databases are not mounted (see Recipes Recipe 11.4 and Recipe 11.5).
Ensure that you have set the This database can be overwritten by a restore option on all databases to be restored.
You can now begin the restore process as outlined in Recipes Recipe 11.4 and Recipe 11.5.
Once the online backups have been restored, use ExMerge to merge the restored data into the live databases, as described in the ExMerge documentation, included with the ExMerge download package.
Discussion
RSGs are an impressive new feature in Exchange Server 2003.
Once you install the Exchange Server 2003 System Manager or server components on a machine, the Exchange backup API DLLs are updated to provide support for the RSG. Any backup utility (including Ntbackup) that supports that API can automatically and transparently make use of the RSG capability. This, in turn, allows you to restore from backups without service interruptions, applying any transaction logs generated during the backup. If the database being restored is registered in the RSG, the API silently directs the restoration to the RSG.
One thing to note is that if the RSG is configured on a server, all restores on that server must take place through the RSG or they will abort. Removing the RSG will immediately cause the server to revert to pre-RSG behavior.
In testing situations, it is possible to override the RSG
behavior without having to remove the configured RSG. Create a DWORD
value named Recovery SG Override under this registry key on the
Exchange Server:
HKEY_LOCAL_MACHINESystemCurrentControlSetServicesMSExchangeISParametersSystem
When the value is set to 1,
the Information Store will ignore the presence of the RSG; when set to
0, the RSG will work as normal.
Changes to this value are picked up on the fly. If you use this
feature, be sure to completely remove the Recovery SG Override value from the registry when you
are done testing to avoid unintentional damage to production
databases.
To recover data from a mailbox in the RSG, the mailbox must reside in the original database from which the database backup you are restoring was generated.
RSGs have some key limitations to remember:
AD must contain whole and unchanged configuration information about the storage groups and databases.
The recovered database must be on a server in the same administrative group as the server performing the restore.
Recovering single mailboxes and deleted items from mailboxes is possible as long as the mailboxes are in the same database, and are connected to the same user account (by GUID, not username), as they were when they were backed up.
You may only recover multiple databases simultaneously if they are all members of the same original storage group.
The recovered database must be from at least Exchange 2000 SP3, and cannot be from a version of Exchange Server 2003 (with service packs) newer than the machine performing the recovery. If the database is from an older version of Exchange, it will be converted to the native version of the recovery machine.
RSGs do not support recovery from public folders and cannot be used to restore entire servers.
All protocol access to RSGs is disabled, except for MAPI, and only the Exchange Server 2003 version of ExMerge is equipped to connect to and browse the contents of databases in the RSG. You will need to use ExMerge in order to merge recovered data back into your production mailbox databases; this can be done across machines.
Mailboxes in RSG databases are not connected to user accounts, nor are they subject to any policies, preventing the accidental deletion of restored data.
See Also
Recipe 11.4 on recovering a single database, Recipe 11.5 on recovering a storage group, “Using Exchange Server 2003 Recovery Storage Groups” book in the Exchange 2003 Technical Library, and The Mailbox Merge Wizard (ExMerge) (the latest version is available for download from http://www.microsoft.com/exchange/downloads/2003/default.mspx)
11.12. Performing Dial-Tone Recovery with Exchange Server 2003
Problem
You need to perform a lengthy database restoration or maintenance procedure, but you need your users to be able to use their mailboxes and basic messaging capabilities during the process. Short-term outage of stored data is acceptable; downtime is not.
Solution
This solution is longer than most and encompasses a large number of separate steps. Many of these individual steps are covered by other recipes in this book, while others are going to vary depending on your specific configuration and situation. Rather than attempt to repeat every single step here, we’re going to break it down into separate tasks and point you to other recipes in the book where appropriate.
Remove the failing database
Navigate to the server and storage group that contain the failing mailbox database.
Right-click on the database and select Properties.
Switch to the Database tab and make note of the path and filenames of the database files (c:path<filename.edb> and c:path<filename.stm>).
Right-click on the database and select Dismount Store. This takes the database offline.
Using the command line or Windows Explorer, move (not copy) these database files to a secure location.
Delete the mailbox store (see Recipe 6.6).
Create the dial-tone database
From the Exchange System Manager, navigate to the server and storage group that contained the failing database.
Create a new mailbox store with the same filenames and path as the failed database (see Recipe 6.4).
Using Exchange Tasks in the ADUC snap-in (see Recipe 5.2) and the Mailbox Recovery Center (see Recipe Recipe 11.10), recreate mailboxes for all users whose mailboxes were on the failing database.
Use ESM to find the location of the transaction logs for the storage group (see Recipe 6.3).
Copy all the storage group transaction logs to a secure location.
Recover the failed database
If a RSG already exists on your server, dismount any mounted databases and remove the RSG.
Following steps 2-4 of Recipe 11.11, create the RSG. Take note of the path where its transaction logs are stored.
Following steps 5-8 of Recipe 11.11, add the failed database to the RSG. Be sure to use a separate path, but use the same filenames for the database files, and ensure that they are on the same volume.
Copy the transaction logs from step 5 of the “Create the dial-tone database” task to the folder that the RSG uses.
Restore the backup of the corrupted database to the RSG following the procedure in Recipe 11.4. Since the logs are already in the appropriate folder, the Information Store service will be able to replay the logs. This will restore the database in the RSG up to the point of failure.
If there are any additional maintenance tasks that need to be run against the previously failed database, run them now against the database in the RSG.
Perform the recovery
Dismount the recovered database in the RSG.
Dismount the dial-tone database in the live storage group.
Move the database files (both .edb and .stm) for the recovered database in the RSG to a separate temporary location on the same volume.
Move the database files (both .edb and .stm) for the dial-tone database into the RSG location.
Move the database files (both .edb and .stm) for the recovered dataset in the temporary location to the live storage group.
Your recovered database should now be in the live location and the dial-tone database should now be in the RSG.
Mount both databases and confirm that your users have their original mailboxes back. They will not contain any items created during the dial-tone recovery period.
Move the items from the mailboxes in the dial-tone database back to the live database by running the two-step procedure offered by ExMerge and selecting step 2: Import data into an Exchange Server Mailbox and following the steps presented.
Discussion
This recipe is really a culmination of all of the rest of this book, and relies quite heavily on several new Exchange Server 2003 features (such as the Mailbox Recovery Center, RSGs, and more). There are several tricky points to consider:
You need to use the same disk volume for creating the dial-tone database as the original database was on. By doing so, you drastically reduce the amount of time that it takes to perform the final recovery process, as you don’t have to copy large database files but can simply move them on the same volume. This means that keeping adequate free disk space on your live mailbox volumes is critical. If you don’t have it, you can copy the files from other volumes, but doing so will definitely slow your recovery.
You have to manually control the naming and placement of several critical files. Be very certain that you do not overwrite existing files unless you know they need to be overwritten. This is why the recipe calls for moving the files being manipulated (with the exception of the transaction logs for the storage group) instead of just deleting them.
By moving the failed database files, you are temporarily disconnecting users from their mailboxes. This is why you need to use the Mailbox Recovery Center, to ensure that their mailbox properties in AD are resynchronized with the proper GUIDs to the correct database and storage group. If you don’t do this, users won’t be able to reach their old or new mailboxes.
See Also
Recipe 11.10 on using the Mailbox Recovery Center, Recipe 11.11 on using RSGs, Recipe 6.6 on deleting mailbox stores, MS KB 174197 (Microsoft Exchange Mailbox Merge Program (Exmerge.exe) information.
11.13. Using the Mailbox Reconnect Utility
Problem
You have orphaned mailboxes in your Exchange 2000 organization and wish to connect them with their users.
Solution
Using a graphical user interface
Launch the Exchange Mailbox Reconnect tool (mbconn.exe) from the Exchange Server 2000 media.
Click Next at the welcome screen.
Enter the name of the Exchange server and domain controller, and click Next.
Select the name of the Exchange database to use (or click Select All) and click Finish.
Select Actions→ Export Users.
Browse for the container you wish your user accounts to be created in, and select a filename for your LDF file.
Click Generate. The Mailbox Reconnect tool will create the filename you specified in step 6.
Go to a command prompt and enter the command
>ldifde -i -f c:
<filename.ldf>
Once all of the orphaned mailboxes have corresponding accounts, you can run the Mailbox Reconnect tool to connect mailboxes to their accounts.
Launch the Exchange Mailbox Reconnect tool (mbconn.exe) from the Exchange Server 2000 media.
Click Next at the welcome screen.
Enter the name of the Exchange server and domain controller, and click Next.
Select the name of the Exchange database to use (or click Select All) and click Finish.
Select Actions→ Preview All.
Select the container that houses the user accounts to match. Verify that the information is correct.
Select Actions→ Apply to connect the orphaned mailboxes to their user accounts.
Discussion
In Exchange versions up to 5.5 the DS/IS Consistency Adjuster was used to reconcile differences between the Exchange Directory and Exchange mailboxes. With AD and Exchange 2000, the mbconn.exe mailbox reconnecting tool was introduced to accomplish the same task with the integrated directory. The mailbox reconnect tool has two major tasks: first, it can examine the Exchange mailbox store and find unmatched mailboxes, and export them to an LDIF-compliant file for import into AD; and second, it can resolve these mailboxes with their user accounts in bulk. As with all Exchange utilities, you should use the version included on the latest Service Pack CD. Since Exchange Server 2003 includes the Mailbox Recovery Center within Exchange System Manager, this tool is really only necessary with Exchange 2000.
See Also
MS KB 271886 (How to use the Mbconn utility to generate AD accounts for information store mailboxes), and MS KB 301585 (Workarounds for Problems with Mbconn.exe)