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
- new-mailboxrepairrequest exchange 2010
hi. do you advise to regularly defrag an Exchange db for performance issues?
Exchange will automatically perform online defragmentation.
I personally advise against offline defragmentation, because I have seen it go bad many times.
Instead, if you have enough free disk space, I can recommend creating a new mailbox database and then moving the mailboxes from the old database to the new. Then delete the old mailbox database.
Just remember to ask yourself, what is it I want to achieve?
If you are trying to free up disk space, then you might not get much out of this process since e-mails will be stored in database whitespace and only when there are no more whitespace left will the database be expanded/grown.
I hope this explanation is useful?
Good explanation!!
Thanks for posting such good information. Corruption is really a very big challenge for Exchange server administrators. Although, to fix the corrupted items in Exchange database file, an inbuilt eseutil /p utility has been provided by the Microsoft Inc. But due to destructive nature of it, this inbuilt tool does not give the accurate results always . In such case users may face some critical data loss situations after running this tool.
In our case, we had gotten only 60 GB data from a 240 GB damaged database after running this tool. At last, we took help from a third party Exchange Server Recovery software and successfully recovered all data from damaged database.
Hope this tool would also help to those who are encountering data loss and corruption situation in their MS Exchange Server.
Thanks again for sharing this informative post.
thanks
Jim