Today I had a customer where his Exchange server was unfortunately not properly shutdown and after powering on the mailbox database was unable to mount.
First I checked the state of the database using:
eseutil /mh “d:\path\to\store.edb”
Unfortunately the state was “Dirty Shutdown”. Next step was to check the state of the log files using:
eseutil /ml “d:\path\to\log\e00”
Unfortunately more bad luck, this showed all sorts of error messages like:
ERROR: Cannot read log file header. Error -4001.
ERROR: Missing log file(s). Log file is generation 77410 (0x12E62), but expected generation is 387171 (0x5E863).
ERROR: Log damaged (unusable). Last Lgpos: (0x5e870,9,0). Error -501.
The next problem was the customer did not have a backup of this server. This meant we had to run a hard repair (Please note this took 13.000 seconds or more than 3,5 hours to complete):
eseutil /p “d:\path\to\store.edb”
Next step is to perform an offline defragmentation of the database. This requires approximately the same amount of disk space as the database plus some more. I would say 120% just to be on the safe side! In this case there was (Again) unfortunately not enough disk Space to perform this, but hey! its a virtual machine so just expand the drive right? WRONG! The VMDK was configured as IDE and thus could not be expanded, at least not without modifying the vmdk file and doing funny stuff with adding drivers into Windows. Fortunately (finally!) there was enough room on the VMware datastore to create an extra drive with enough room to move the mailbox database including log files and perform the offline defragmentation.
The mailbox database was offline defragmented using:
eseutil /d “d:\path\to\store.edb”
After 2,5 hours this finally finished. Next is to either delete the old log files or my favorite: move them to a different location for safe keeping for now.
Now make sure you can mount the mailbox database. If it mounts successfully (it should), then run this PowerShell command from Exchange 2010 Shell:
New-MailboxRepairRequest -Database “Name of database to be fixed” -CorruptionType SearchFolder, AggregateCounts, ProvisionedFolder, FolderView
It may seem like the command completes instantly, but you will need follow its progress in the Event Viewer instead.
After it finishes I strongly recommend creating a new mailbox database and moving the mailboxes to the new database.
REMEMBER! If your user is not a member of active directory group “Organization Management” then you will not see the move request features in the Exchange Management Console.
Next issue you might hit is that the mailbox is above quota and you therefore cannot move it! The error could be similar to this:
Mailbox size 20.8 GB (22,334,233,515 bytes) exceeds target quota 2.3 GB
If you see this error then you can disable the quota for this user by opening Properties -> Mailbox Settings -> Storage Quotas and simply deselecting “Use mailbox database defaults” – just leave the fields empty!
After you start moving the mailboxes you might hit an error like I did:
Error: MapiExceptionNotFound: Unable to synchronize manifest. (hr=0x8004010f, ec=-2147221233)
This Means the mailbox is corrupted. Luckily you can easily resolve this with a Powershell command:
New-MailboxRepairRequest -Mailbox [email protected] -CorruptionType SearchFolder, AggregateCounts, ProvisionedFolder, FolderView
Again, remember progess for New-MailboxRepairRequest MUST be followed trough Event Viewer and not Powershell command line. After it finished running you should see something like this:
Online integrity check for request 1aecd6f9-e54a-4d48-bff5-ae54598f9191 completed successfully.
After that, simply re-try the move request (but remember to remove the initial move request).
Incoming search terms:
- repair exchange 2010 database
- mapiexceptionnotfound: unable to synchronize manifest
- error: mapiexceptionnotfound: unable to synchronize manifest
- new-mailboxrepairrequest exchange 2010