Exchange Database Recovery: ESEutil & Dirty Shutdown

Our emergency Exchange Server support team works dismounted-database calls on a regular basis, and the order of operations matters more than any single command. This page covers the recovery path for a database that will not mount: check the header state, run soft recovery, and only then consider a backup restore or a hard repair. The wrong first move — running ESEutil /p on a database that only needed log replay — converts a zero-loss incident into a data-loss incident.

Symptoms: database dismounted, mount fails

The typical presentation: the database shows Dismounted in the Exchange admin center after a reboot, a crash, a failed backup, or a full disk. A manual mount attempt fails with an error such as MapiExceptionCallFailed: Unable to mount database (hr=0x80004005, ec=-528) or ec=-515, or the mount terminates with error -550. Common causes: the server was restarted while the Information Store was still writing, power loss, antivirus or backup software locking transaction logs, or the log volume filling up.

A database in this condition is usually in a Dirty Shutdown state — logs exist that have not been committed to the .edb file. Dirty Shutdown is not corruption. Per Microsoft's ESE file documentation, a dirty (inconsistent) database can be brought to a clean state with soft recovery; a corrupt database — physical or logical damage such as page checksum failures — cannot. Determining which one you have is the first step, not mounting retries.

Step 1: check the database state with ESEutil /mh

From a command prompt on the Exchange server, read the database header:

eseutil /mh "D:ExchangeDatabasesDB01DB01.edb"

In the output, find the State: line. It reads either State: Clean Shutdown or State: Dirty Shutdown.

• Clean Shutdown: the database is consistent. The mount failure has a different cause — permissions, paths, a stale checkpoint file, or the Information Store service. Do not run any repair against a clean database.
• Dirty Shutdown: uncommitted log files must be replayed before the database can mount. The header also lists Log Required: with the range of log generations the replay needs. Confirm every log in that range exists in the log folder before proceeding.

Step 2: check disk space

Before any recovery attempt, check free space on both the database volume and the log volume. A full log volume is one of the most common reasons a database dismounts in the first place, and soft recovery itself writes to disk. If the log drive is full: free space by moving non-Exchange files off the volume or extending the disk. Do not delete transaction logs. The logs in the Log Required range are the recovery — deleting them forces a restore or a hard repair. Logs older than the required range are only safely removed by a successful full backup, which truncates them.

Step 3: soft recovery with ESEutil /r

Soft recovery replays the uncommitted transaction logs into the database and brings it to Clean Shutdown. No data is lost. The syntax, as documented in Microsoft's recovery database procedure:

eseutil /r E00 /l "D:ExchangeDatabasesDB01" /d "D:ExchangeDatabasesDB01"

• E00 is the log generation prefix for the database (E00, E01, E02, and so on). It is a required parameter — find yours by looking at the log file names in the log folder.
• /l points at the folder containing the transaction logs.
• /d points at the folder containing the .edb file.

When the operation completes successfully, run eseutil /mh again and confirm State: Clean Shutdown, then mount the database with Mount-Database DB01. Soft recovery fails when logs in the required range are missing, or when a log or the database itself is damaged — the error output states which. That failure moves you to step 4; it is not a signal to escalate to /p on the spot.

Step 4: when soft recovery fails — restore versus hard repair

Two paths remain, and they are not equivalent.

Restore path: the Recovery Database (RDB) workflow

A recovery database is a special mailbox database that lets you mount a restored copy and extract data from it without disturbing user access to production databases. The full procedure is in Microsoft's create a recovery database and restore-data articles. The sequence:

1. Restore or copy the database and its log files from backup into the RDB folder. Note that when a backup application restores to an alternate location, the restored database is in Dirty Shutdown — bring it clean with soft recovery first:

eseutil /r E01 /l "E:DatabasesRDB1" /d "E:DatabasesRDB1"

2. Create the recovery database, pointing EdbFilePath at the restored .edb:

New-MailboxDatabase -Recovery -Name RDB1 -Server EXCH01 -EdbFilePath "E:DatabasesRDB1DB01.edb" -LogFolderPath "E:DatabasesRDB1"

3. Restart the Information Store (Restart-Service MSExchangeIS), then mount: Mount-Database RDB1.

4. List the mailboxes in the restored copy with Get-MailboxStatistics -Database RDB1, then restore data into the production mailbox:

New-MailboxRestoreRequest -SourceDatabase RDB1 -SourceStoreMailbox "Morris Cornejo" -TargetMailbox [email protected]

5. Track progress with Get-MailboxRestoreRequest; remove completed requests with Remove-MailboxRestoreRequest. Cmdlet details are on the New-MailboxRestoreRequest reference. If the whole server or volume is gone rather than one database, database portability covers mounting a recovered database on a different Mailbox server.

Why transaction logs matter

Exchange writes every change to a transaction log before committing it to the .edb file. That write-ahead design is what makes soft recovery possible: after a crash, the engine replays the logs to bring the database to a consistent point. It is also why deleting logs is destructive and why log-volume sizing is an availability concern, not housekeeping.

Circular logging overwrites logs once their transactions are committed, which caps log-volume growth but removes the replay history. With circular logging enabled, point-in-time recovery is gone — you can restore only to the moment of the last full backup. It is a reasonable setting inside a DAG protected by Exchange Native Data Protection; on a standalone server that depends on backups, it narrows your recovery options and should be a deliberate decision.

DAG copies: the recovery path that skips all of this

If the database belongs to a database availability group, ESEutil is usually the wrong tool entirely. Activate a healthy copy on another DAG member (Move-ActiveMailboxDatabase), restore service in minutes, and deal with the failed copy afterward by reseeding it. Copy states, activation, and reseeding are covered in our Exchange DAG guide. A single-copy database is the scenario this whole page exists for; a DAG turns the same failure into a switchover.

Prevention

• Application-aware backups, tested by restoring. A VSS-based Exchange backup (see Microsoft's Windows Server Backup restore procedure) truncates logs on success and is the input to the RDB workflow above. A backup that has never been restored is an assumption.
• Monitor log-volume free space with alert thresholds well before full. Most dirty-shutdown incidents we see start as disk-space incidents.
• Shut down in order. Stop Exchange services before restarting the server; avoid forced restarts while the Information Store is running.
• Add a second database copy. A two-member DAG removes the single-copy failure mode this page describes.

If the database is down right now

Database mount failures do not wait for business hours, so Exchange Server support at Medha Cloud runs 24/7. An Exchange engineer is available on live chat at any hour; typical engagement on a dismounted-database case starts within minutes of contact. We handle state assessment, log replay, RDB restores, and post-recovery mailbox moves.