A common bad practice when it comes to migrating mailboxes, is to set the badItem limit to 10, 20, 30, 40, 50 etc, and keep incrementing until Resume-MoveRequest finally works. When you do this, you’re blindly accepting large data loss, without knowing exactly what kind of items are corrupt or the total amount beforehand.
Here is a simple way of determining the total number of corrupt / bad items a mailbox move request has encountered, and exactly what type/kind the bad items are. In order to utilize this guide, you will need to connect to Exchange Online PowerShell if you’re moving the mailbox to o365, or use the on premises Exchange Management Console if you migrating on premises.
Before we start I will provide you with a basic summary of what we’re doing to accomplish this task. We are going going to take the MoveRequestStatistics of the mailbox and export that data to XML. Doing this supplies us with a number of details that are not prevalent within the standard -IncludReport switch. Once we have exported the data to XML, we will import it back into powershell and store it in a variable, which we will access using dot notation.
Step 1. Connect to Exchange Online Powershell OR open Exchange Management Console.
Step 2. Export the MoveRequestStatistics Report to XML:
Get-MoveRequestStatistics -Identity firstname.lastname@example.org -IncludeReport | Export-CliXML C:\Location\of\YourChoice\FileNameGoesHere.xml
Step 3. Import the XML data and store it in a variable:
$BadItems = Import-CliXML C:\Location\of\YourChoice\FileNameGoesHere.xml
Step 4. Review the total number of items and the kind of items that are corrupt:
$BadItems.report.baditems.count (this is to get the total count)
$badItems.report.baditems.kind (this is to view the kinds of bad items)
BadItems.report.baditems | Out-GridView (This will open a GUI explorer to review all of the bad items and their kinds.
Before we go on to step 5, I would like you to understand a few types of acceptable bad data… that would be Security Descriptors and Calendar Properties. Those tend to be the most common. Be careful not to accept actual corrupt items. Once you have determined the kinds of items are within scope of acceptable data loss.. move on to step 5.
Step 5. Increase the bad item limit to the total number you retrieved for the cmdlets above:
Set-MoveRequest -Identity email@example.com -BadItemLimit 25
Step 6. Resume the move request (or set -CompleteAfter switch to $null, depending on your scenario)
Resume-MoveRequest -Identity firstname.lastname@example.org
OR Set-MoveRequest -identity email@example.com -CompleteAfter:$null