Having done some Office365 email migrations have seen quite a few odd error messages and collected a few of the most common below.
Microsoft technical support usually advise to retry the batch which is a valid request however most often than not it is far from a viable solution.
- Let’s see our first error!
ErrorSummary : Error: This job hasn’t made progress since
2/28/2017 1:44:55 AM. The job was picked up at
2/28/2017 1:44:41 AM. Last WLM Stalled check was
at 2/28/2017 1:44:39 AM.
I find this is the worst of all as it does provide any explanation other than no progress has been made. The only solution for this was to either remove the offending Move-Request from the batch or remove and redo the whole batch again. Most of times it worked without an issue at the second time but sometimes it needs a few more attempts.
- Next on the list
ErrorSummary : Error: This mailbox exceeded the maximum number of
corrupted items that were specified for this move
Request.
Fairly self explanatory and it happens quite a lot unfortunately!
The root cause can be a mixture of things and most often it boils down to AD permissions. Say some folders or calendars within the mailbox are shared with a deleted AD user. As Office365 can’t locate this user object in Azure AD the lookup will fail and the error message is triggered.
Removing these permissions manually won’t be an easy task as permission changes won’t propagate down from the main folders instead need to use Powershell to get it all stale permission entries removed. I have used a script available on Github which works really well. Bear in mind it may take a long time to go through the mailbox if it’s large. If all goes as planned you should see something similar on the console. Here you can find further reading on this PS script and its usage.
After permissions have been fixed the Move-Request will need restarting.
- Next up on the list has an odd name: “Lossy failover occured”
Fortunately the error explains what happened and the only remedy is to re-start the migration job however.
- No.4 error in our list
The job encountered too many transient failures (xy) and is quitting. The most common failure is SourceMailboxAlreadyBeingMovedTransientException with the hit count xy.
Fatal error SourceMailboxAlreadyBeingMovedTransientException has occurred
This appears to happen when the Exchange Online mailbox database failover occur – again only option is restarting the Move-Request.
- Last but not least a permanent exception
Error: MigrationMRSPermanentException: Error: Couldn’t switch the mailbox into Sync Source mode. This could be because of one of the following reasons: Another administrator is currently moving the mailbox. The mailbox is locked. The Microsoft Exchange Mailbox Replication service (MRS) doesn’t have the correct permissions. Network errors are preventing MRS from cleanly closing its session with the Mailbox server. If this is the case, MRS may continue to encounter this error for up to 2 hours – this duration is controlled by the TCP KeepAlive settings on the Mailbox server. Wait for the mailbox to be released before attempting to move this mailbox again.
As the error says it can be for numerous reasons. I have not found any pattern when this cropped up – just delete the job and restart it. I found it’s best to wait a little (couple of hours) before attempting the move again otherwise it may get locked after a short period of time – guess it’s due to replication delay.
This is all for now, thanks for reading and leave a comment or send a message if you found this helpful!