For a long time now, I have been associated with migrating user mailboxes from an older Exchange version to a higher one. Our organization has thousands of users and each migration involved moving tens of thousands of mailboxes. Users would normally delete the corrupt items in their mailbox and the export becomes easy.
Recently, as I was moving a mailbox to Exchange 2010 Server, the process got interrupted with a message to increase the 'BadItemLimit' value and then retry. This was possibly happening due to corrupt items in the mailbox and I had a fear of losing precious user data. I ran the 'New-MailboxRepairRequest' with the '-DetectOnly' option. But it seemed that the command failed to identify and repair individual mailbox items. It works similar to the 'ISINTEG' tool. I again ran the command with different options this time:
'New-MailboxRepairRequest -Database DB1 -CorruptionType Folderview, SearchFolder, AggregateCounts'
I was examining the Event viewer for the events '10047' and '10062'. These show up when the repair process starts or whenever the corruptions are repaired. However, I was able to find nothing and it appeared as if the 'New-MailboxRepairRequest' doesn't work for damaged mailbox items. We do not have these problems for every user mailbox, but only a small percentage of mailboxes. The question was how we got corrupt items that were working fine in prior to this migration. Also, the process was extremely exhaustive and unreliable that asked every time to increase the 'BadItemLimit' value until it finally works. I personally called the user to determine what was going wrong and carefully examine the mailbox. There were some items from the Exchange 5.5 migration like calendars, appointments etc. It would have been much better if we found all the corrupt items at once.
For verifying the integrity of all data in the mailbox, we followed the below procedure:
- Ran ESEUTIL from the '\EXCHSRVR\BIN' directory as follows: eseutil /mh “database name”
- Initiated a soft recovery using the 'eseutil /r' switch. Also used the '/I' and '/D' parameters as the databases were stored in different locations.
- Performed a hard repair with the help of 'eseutil /p'.
We still encountered the same problem and this time I practically gave up. I decided to try hands at commercial Exchange Server recovery tools. Yes, this time it ran with no errors. The Exchange recovery software helped us to recover every item in the mailbox with a little effort. I used them for each mailbox flagged as corrupt.
About the Author:
Axel Culver is an active blogger and a technical writer. She has approx. 6.0 years of experience in working with MS Exchange Server. She is doing research on some commercial Exchange recovery and Exchange BKF Recovery programs.
