I recently ran into an issue migrating a mailbox from one version of Exchange to another. There have been instances where we had to move mailboxes back to Exchange 2007 due to 3rd party applications not fully supporting Exchange 2013. While the migration to Exchange 2013 went flawlessly, the move back stalled and threw an error I hadn’t seen before. If you ran a Get-MoveRequest –identity <Displayname> and piped that to a Get-MoveRequestStatistics you would see the following error.
When I researched the above error, the only association I found was with migrating mailboxes to Office 365. Michael Van Horenbeeck wrote an article on this very issue. http://vanhybrid.com/2013/07/07/you-get-an-error-stalledduetomailboxlock-when-moving-mailboxes-to-office-365-in-a-hybrid-configuration/
But for me, I was moving from 2013 to 2007 and none of the problems that faced Michael’s scenario were playing a role here. To rule out some things I first activated the source DB to another server, I tested replication health and everything was as it should. I decided to run New-MoveRequest from the shell and see what additional information I could find.
I keyed in on the StatusDetail that was saying the move request was stalled due to a lock on the mailbox
Now, I was confused, poisoned job? I’ve had poisoned messages but not a poisoned job. Could it be the mailbox was quarantined by Exchange due to some level of corruption in the mailbox? If I was to run a Disable-MailboxQuarantine, I would see that this wasn’t the case and the issue has to be in the mailbox itself. I went back to the original move request statistics message and looked at what stage in the move the mailbox was failing at. Looking at the SyncStage piece of the request I found that it was failing creating the folder hierarchy. My next step was to open the mailbox in outlook and see if there were folders with non approved characters or perhaps a folder name that was extremely long. But non of these proved to be the case so I decided to check under the hood via MFCMAPI. At first glance, I didn’t see any issue, but I decided to expand the Finders folder. I had previously had an issue with this hidden folder when a user had more then the than 75 search folders causing emails to bounce back with the following NDR.
Remote Server returned ‘554 5.2.0 STOREDRV.Deliver.Exception:StoragePermanentException.MapiExceptionMaxObjsExceeded; Failed to process message due to a permanent exception with message Cannot set search criteria in SearchFolder. Try using fewer keywords at the same time, reducing the number of users in the From, To, Cc, and Bcc fields, and reducing the number of mailboxes that are searched at the same time.
This was easily remediated by adding the /cleanfinders switch when calling the outlook executable. But in this instance, it was not due to a large number of folders, but either something in the search folder or how the folder was named as you can see the odd search folder names below.
From what I can tell, those restriction folders are corrupted search folders. I saw a similar restriction folder when I check skipped items during mailbox batches.
I just simply hard deleted the folders while in MFCMAPI and then submitted a new move request. I was happy to see the following message and begin my drive home.