Hybrid Exchange Batch migration to cloud - Mailbox is locked

Question

Hello Team,
Could you please tell where could we find the reason for the issue of "mailbox is locked" report message?
"The job has been paused temporarily because the mailbox is locked. The job will attempt to continue again after..."
Fortunately this is not a common issue, and it only happens before the last delta sync (incremental) - concerns approximately 1 mailbox out of a thousand or more.
The mailbox stays locked, and thus the incremental sync is stuck at 95% - is there a way to figure out the exact reason for such a phenomenon? Is there a way to remove this lock?
We migrate 300-500 user per batch on a weekly basis, and the rest of the mailboxes (in a batch) are moved to cloud just fine - thus network\firewall\etc issue can be ruled out, it is definitely on the application level.
Thanks in advance for the explanation!

Answer 1

@Tibor.Szakacs

Which version of Exchange on-premises server that you used?

I would suggest you stop creating additional migration request temporarily. Check whether this migration request could continue later. Because there exist some limitation on Mailbox Replication Service.

You can also try to modify the "receiveTimeout" (Such as modify to 00:05:00) for "MSExchangeMailboxReplication.exe.config" under "C:\Program Files\Microsoft\Exchange Server\V15\Bin\" folder. The restart the "Microsoft Exchange Mailbox Replication Service", check whether could migration successfully now.

Based on my searching, there exist may thing may caused this issue. We could take step below to narrow down it:

Check whether there exist other migration request occupied this mailbox:

Get-MoveRequest -Identity '******@domain.com' | Get-MoveRequestStatistics -IncludeReport | fl  

Remove this migration request, then try migrate this mailbox to anther database, it could help us check whether there exist issue with database or this mailbox.

---

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

---

Answer 2

This another way seems to be way more complicated and time consuming than just removing\readding the mailbox for migration via the O365 portal - but anyhow, thanks for mentioning it.

With regards to your suggestion, we would like to avoid any kind of impact on our prod enviroment - and while restarting the repl. service might not affect the users, it is better to be afraid than getting scared.. :-) and furthermore I don't see how this would affect (the receivetimeout) the mailbox lock. And further-furthermore we cannot test this on an actual issue, because such lock occurs only seldom, and we apply the workaround of moving the db copy to another member of a given DAG (have done already, with success).

It would be great even to comprehend what exactly this message (mailbox is locked) mean - how exactly it is being locked. Our guess is that the user (or application) is actively using the mailbox, but we cannot test this either.

Probably the MS case will be the way, I do agree.