It used to be easy to complete an Exchange Server > Exchange Online move request that had bad items, but this has changed recently.
In the last short while Move Requests (and Migration Batches) have begun to include a property called DataConsistencyScore
Get-MoveRequestStatistics "Bill Gates" | fl DataConsistencyScore
If the result from the above is “Investigate” then you will not be able to complete the move even if you set the usual properties of -PreventCompletion $false and -CompleteAfter 1, that is – the following will not work:
Set-MoveRequest "Bill Gates "-SuspendWhenReadyToComplete $false -PreventCompletion $false -CompleteAfter 1
You will also need to set the following:
Set-MoveRequest "Bill Gates" -SkippedItemApprovalTime $(Get-Date).ToUniversalTime()
Upon running the above (the move request will auto resume in my tests), the move will start to complete if completion is allowed (the cmdlets at the top of the post). Obviously you will want to check why there are a number of bad items in the move and what you are going to try and do to fix them.
The SkippedItemApprovalTime property approves all bad items detected before the specified time. So in the above example we are approving all bad items to be discarded that were found before “now”. You could set an earlier specific time as well.
You now do not need to set a bad item limit (BadItemLimit) value as you are approving items by time instead.
You saved me, Thanks a lot!!!
Saved me too! Thanks!
Why is it getting so hard to discard corrupt items? It’d be one thing if you ever found out about them before your 12 hour migration was 95% complete.
Yes, I know what you mean – a lot of those with errors have no indication of error during prestage (unless you do Get-MoveRequestStatistics)