A. Exchange Server recovery is a rather intricate and complex art. The Microsoft white paper “Microsoft Exchange 5.5 Disaster Recovery” (http://www.microsoft.com/exchange/techinfo/backuprestore.htm) devotes nearly 100 pages to the subject. You need to consider the potential ramifications of various disaster-recovery steps-some of which might result in data loss-before you proceed with any attempted recovery operation. That said, here are a few quick suggestions that might get the DS running.
Before you do anything, make online and offline backups of all the Exchange Server databases (i.e., dir.edb, pub.edb, and priv.edb) and any existing log files (some log files might include changes that haven’t rolled into the databases yet). Because disaster-recovery attempts sometimes make problems worse, these backups will provide a way to return to the state the system was in before you started your recovery attempt. An online backup takes place while the Exchange services are running and uses an Exchange Server-aware backup utility to back up Exchange Server to a tape drive or other backup device. An offline backup takes place while the Exchange services are stopped.
Next, run Eseutil (eseutil.exe)-one of Exchange Server’s troubleshooting and disaster-recovery tools-to determine whether Exchange Server believes that the Directory Store database (i.e., dir.edb) is corrupted. Eseutil is a command-line utility that resides in the \%systemroot%\system32 folder, so you can run it regardless of your current directory. (For more information about using Eseutil, see Paul Robichaux, Getting Started with Exchange, “The Sorcerer’s Apprentices,” May 2000.) To determine dir.edb’s integrity, type
eseutil /g /dsThe /g switch tells the tool to run in integrity check mode (this is a read-only mode and won’t make any changes to your database), and the /ds switch tells Eseutil to evaluate the Directory Store database. If you want verbose output, you can also use the /v switch; if you want detailed error messages, use the /x switch. (To view the available switches, run Eseutil with the /? switch only.)
Running Eseutil might provide additional information about the problem, including whether compromised database integrity-a likely though not guaranteed suspect-is to blame as well as the severity of any corruption. Assuming that database corruption is the problem, the next step is to use Eseutil’s /r (for recovery) option attempt a soft recovery. Type
eseutil /r /ds
Eseutil provides output during the recovery operation and informs you whether the recovery was successful.
At this point, try to start the DS through the Control Panel Services applet, or from the command line type
net start msexchangeds
If the DS still fails at startup, you might need to use Eseutil to run a repair operation on the database. To do so, from the command line type
eseutil /p /ds
A dialog box appears, prompts you to confirm the operation, and reminds you that to complete the operation you need to delete any log files that relate to the database you’re recovering. In the case of dir.edb, these logs files reside in \exchsrvr\dsadata\log on the volume that houses the Exchange Server log files (you specified this volume during Exchange Server setup). After you delete the log files, try starting the DS again.
In most cases, one of these steps will recover the directory. However, if none of the steps do the trick, or if the recovered directory contains garbage or is missing important data, you might need to restore an online or offline Exchange Server backup that you made before the corruption occurred. For information about the procedures for and ramifications of Exchange Server backups, refer to your backup-software vendor’s documentation or to the Microsoft paper I mentioned earlier. You can also read Paul Robichaux, Getting Started with Exchange, “Mitigating Disaster,” July 2000, and “The Six Deadly Backup Sins,” April 2000.
