Exchange 2013 mailbox database evacuation after eseutil offline repair
After eseutil.exe offline repair is performed on an Exchange 2013 mailbox database, Exchange emits hourly warnings that Exchange-level logical consistency can no longer be guaranteed and requires the database to be evacuated. The recommended remediation is to use New-MoveRequest to migrate all affected mailboxes to a healthy database, which is more reliable than PST export/import. Individual item-level corruption encountered during migration can be handled by increasing the BadItemLimit parameter on the move request.
Indicators
- Event log warning: 'Database has been offline-repaired (eseutil.exe) one or more times in the past'
- Hourly event log reminders to evacuate and retire the affected database
- Exchange warning that Exchange-level logical consistency can no longer be guaranteed
- Database-level (ESE) logical consistency confirmed but Exchange-level consistency uncertain
- Potential for unexpected behaviour caused by Exchange-level logical inconsistency
Likely causes
- Previous use of eseutil.exe to perform offline repair on the mailbox database
- Database corruption requiring manual intervention outside normal Exchange recovery mechanisms
- Hardware or storage failure leading to database inconsistency
- Improper shutdown or system crash resulting in unrecoverable database damage
Diagnostic steps
-
Review Event Viewer on the Exchange server to confirm the eseutil offline-repair warning event and note how many times it has been emitted to assess ongoing risk.
-
Identify all mailboxes hosted on the affected database using Exchange Management Shell: Get-Mailbox -Database <DatabaseName>
-
Assess mailbox sizes to estimate migration time and target database capacity requirements: Get-MailboxStatistics -Database <DatabaseName> | Select DisplayName, TotalItemSize
-
Confirm a healthy target database exists and has sufficient free space; create a new database if required.
-
Initiate move requests for all mailboxes to the healthy database: New-MoveRequest -Identity <MailboxIdentity> -TargetDatabase <HealthyDatabaseName>
-
If move requests fail due to item-level corruption, increase the bad item limit and re-run: New-MoveRequest -Identity <MailboxIdentity> -TargetDatabase <HealthyDatabaseName> -BadItemLimit <number> -AcceptLargeDataLoss
-
Monitor move request progress until all mailboxes report Completed status: Get-MoveRequest | Get-MoveRequestStatistics
-
Once all mailboxes have been successfully evacuated, dismount the compromised database and retire it from the Exchange environment.
Resolution path
- Confirm the eseutil offline-repair warning in Event Viewer to establish that database evacuation is required.
- Enumerate all mailboxes on the compromised database using Get-Mailbox -Database <DatabaseName>.
- Verify a healthy target database exists with sufficient capacity; create one if necessary.
- Use New-MoveRequest to migrate all mailboxes from the compromised database to the healthy database — no mailbox size limit applies to this method.
- For any move requests that fail due to item-level corruption, increase the BadItemLimit parameter and re-submit the move request with -AcceptLargeDataLoss.
- Monitor all move requests to completion using Get-MoveRequest | Get-MoveRequestStatistics.
- Verify every mailbox reports Completed status before proceeding.
- Dismount and retire the compromised database once fully evacuated; do not remount it.
Prevention
- Maintain regular, verified database backups to avoid needing eseutil offline repair as a recovery measure.
- Deploy Database Availability Groups (DAGs) to provide high availability and automatic failover, reducing the risk of unrecoverable single-copy corruption.
- Monitor Exchange database health proactively using built-in Managed Availability alerts and respond to early warnings before corruption becomes critical.
- Preserve transaction logs and avoid circular logging where point-in-time recovery may be needed.
- Perform non-destructive integrity checks with eseutil /g periodically to detect corruption before it reaches a state requiring offline repair.
- Ensure underlying storage (RAID, SAN, HBA drivers) is healthy and firmware is current to reduce the risk of hardware-induced database corruption.
Tools
- New-MoveRequest (Exchange Management Shell cmdlet)
- Get-MoveRequest (Exchange Management Shell cmdlet)
- Get-MoveRequestStatistics (Exchange Management Shell cmdlet)
- Get-Mailbox (Exchange Management Shell cmdlet)
- Get-MailboxStatistics (Exchange Management Shell cmdlet)
- New-MailboxExportRequest (PST export alternative if move requests are not viable)
- eseutil.exe (reference only — do not run additional repair passes on the affected database)