oeltayeb.com · Exchange Server Troubleshooting Toolkit

Checklist

Database won't mount checklist

Based on the article: Exchange database won't mount: Dirty Shutdown, ec=1108, eseutil /mh and soft recovery · 5 min read

A mailbox database that refuses to mount takes every mailbox on it offline, and the error in the shell is famously unhelpful. The database header, however, tells you exactly what Exchange is missing. In this post I'll show how to decode the mount error, read eseutil /mh, bring the database to a consistent state with soft recovery, and choose between reseed, restore and hard repair when that isn't possible.

Symptoms to confirm

  • Mount-Database (or Servers › Databases › Mount in the Exchange admin center) fails with a message like this:
Failed to mount database "DB01". Error: An Active Manager operation failed. Error: The database action failed. Error: Operation failed with message: MapiExceptionDatabaseError: Unable to mount database. (hr=0x80004005, ec=1108)
  • Admins report that the Exchange admin center version of the message starts with Couldn't mount the database that you specified., and that the underlying engine error is sometimes named instead, for example MapiExceptionJetErrorMissingLogFile: Unable to mount database. (hr=0x80004005, ec=-528) when a log file is missing.

Tip: ec=1108 is generic. Look in the diagnostic context for StoreEc values that start with 0xFFFF — they are negative ESE error codes. Type the value into PowerShell to decode it: 0xFFFFFE0B returns -501, a corrupt log file.

Likely causes

Exchange's database engine (ESE) uses write-ahead logging: every change goes to a transaction log first and into the .edb file later.

ESE errorMeaningUsual cause
-550 JET_errDatabaseDirtyShutdownRecovery must run before the database can be usedRequired logs weren't replayed
-528 JET_errMissingLogFileThe current log file (E01.log for prefix E01) is missingLogs deleted by hand, quarantined by antivirus or lost with a volume
-501 JET_errLogFileCorruptA log file is damagedStorage fault, crash while writing
-1216 JET_errAttachedDatabaseMismatchThe logs expect a database attachment that's missing or doesn't match the database fileWrong log folder, or an .edb replaced or restored without its matching logs
-1018 JET_errReadVerifyFailurePage checksum failureStorage corruption — see JET error -1018

Checklist

  1. 1

    In a DAG, switch copies instead of repairing

    If another copy is healthy, activate it and reseed the broken one later. That's faster and loses nothing:

    powershell
    Get-MailboxDatabaseCopyStatus DB01\* | Format-Table Name, Status, CopyQueueLength, ReplayQueueLength
Move-ActiveMailboxDatabase DB01 -ActivateOnServer EX02
  2. 2

    Protect what you have

    Leave the database dismounted and copy the .edb file, the whole log folder and the checkpoint (.chk) file to another volume before you change anything. Find the paths and the log prefix with:

    powershell
    Get-MailboxDatabase DB01 | Format-List Server, EdbFilePath, LogFolderPath, LogFilePrefix
  3. 3

    Read the database header

    From an elevated prompt on the server (eseutil.exe lives in %ExchangeInstallPath%Bin):

    cmd
    eseutil /mh "D:\DB01\DB01.edb"

    The lines that matter:

    State: Dirty Shutdown
Log Required: 5873-5875 (0x16f1-0x16f3)
Repair Count: 0
  4. 4

    Check that the required logs exist and are readable

    cmd
    cd /d "E:\Logs\DB01"
eseutil /ml E01

    This checks the log set for prefix E01 and should end with Operation completed successfully. If a required log is missing, look in your antivirus quarantine, the backup software and any folder someone moved files into, and put it back.

  5. 5

    Fix the cause, then let Exchange recover

    Free space on the log volume, add the antivirus exclusions and clear storage errors first. With the required logs in place, simply run Mount-Database DB01 again — ESE replays the logs as part of the mount.

  6. 6

    Run soft recovery manually

    If the mount still fails, run recovery yourself; the output is far more specific than the shell error:

    cmd
    eseutil /r E01 /l "E:\Logs\DB01" /s "E:\Logs\DB01" /d "D:\DB01"
  7. 7

    When the logs are gone for good

    • Restore the database from an Exchange-aware backup and let it replay the surviving logs. For selective recovery, restore into a recovery database (New-MailboxDatabase -Recovery) and use New-MailboxRestoreRequest. Dial-tone recovery — re-homing users to an empty database with Set-Mailbox -Database — keeps mail flowing while you restore.
    • Hard repair with eseutil /p only as the last resort, and on a copy. It discards whatever it can't read, so data loss is expected, and it asks you to confirm exactly that. Afterwards move the old logs and checkpoint aside, mount, run New-MailboxRepairRequest -Database DB01 -CorruptionType SearchFolder,AggregateCounts,ProvisionedFolder,FolderView, and move every mailbox to a new database. Microsoft's support policy for repaired databases, published by the Exchange team in 2015, expects a database with a Repair Count above zero to be evacuated.

Verify

  • eseutil /mh shows State: Clean Shutdown before you mount.
  • Get-MailboxDatabase DB01 -Status | Format-List Name, Mounted returns Mounted : True.
  • Test-MAPIConnectivity -Database DB01 reports Success, and a user can open their mailbox.
  • In a DAG, Get-MailboxDatabaseCopyStatus DB01\* shows one Mounted copy and the others Healthy.
  • A full backup completes, giving you a fresh recovery point.

Prevent it next time

  • Never delete transaction logs by hand; let backups or circular logging truncate them.
  • Exclude the database and log folders from file-level antivirus scanning.
  • Keep the log volume well away from full and alert on free space.
  • Run more than one database copy in a DAG so a damaged copy means a reseed, not an outage — and use maintenance mode when patching.
  • Test restores, not just backups.

Microsoft Learn references