Exchange Server Backup Dilemma

I'm having a severe problem with a Microsoft Exchange Server 5.5 machine. The other day, I tried to delete several public folders that appeared in my organization's Exchange Server public folder list. However, I couldn't delete the folders or the items the folders contained—despite having the necessary administrative permissions. Shortly thereafter (and probably not coincidentally), the Exchange services became unresponsive and I could no longer connect to the server through Microsoft Exchange Administrator or Microsoft Outlook. At that point, I rebooted the server in hopes that the problem would correct itself. Now the Directory Service (DS) terminates during startup and displays error 1067. The Microsoft Knowledge Base doesn't seem to have any helpful information about this error, and the server's event logs provide no clues to the problem. What can I do to recover this server?

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.

First, 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.

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.

Next, run Eseutil—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 /ds

The /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 all 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 and the severity of any corruption. Assuming that database corruption is the problem, the next step is to use Eseutil's /r option to 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 at 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, at the command line, type

eseutil /p /ds

A dialog box appears, prompts you to confirm the operation, and reminds you 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.