In this post, I would like to share how I got around a Mailbox Locked Mailbox Move issue. After we have successfully moved several hundred mailboxes to their new location some issues occurred with a few mailboxes.

Moves for those mailboxes could not be started with the -priority switch due to the fact that the target location wasn’t on-premise.

As a result, some of those boxes just stalled. Restarting the Mailbox Replication Service on the relevant source server did the trick. The stalled move requests could be reinitiated. Only one mailbox remained.

However, the remaining mailbox was locked. I tried to move the mailbox to another mailbox database but received the same error as with the move-request:

It seemed like the mailbox had a locked flag ( or something similar ) set in the information store of the source server that mounts the mailbox database for this mailbox. If so, I would have to restart the information store or reboot the server to wipe this flag. Not the first choice for a production server.

I never had this kind of mailbox locked mailbox move issue before.
So I started to google and fortunately found this article on dirteam.com.

The article made me confident that it is most probably locked in the information store on the source server. Switching the mounted mailbox database where the locked mailbox resides to another server just did it. Simple as that. Thank you, DirTeam!

Here the short procedure to solve the mailbox locked mailbox move issue:

After the mailbox database was mounted on another server I was able to start and complete the move of the last mailbox successfully.

Have a nice day!
 
 
If you run into other issues with move requests this could also be of interest:

Mailbox Moves
 

The post Mailbox Locked Mailbox Move Issue appeared first on Webbanshee.

If you are reading this you have certainly noticed a Stalled Move Request at times. Exchange 2016 ( we have CU8 in place ) utilizes throttling on move requests as well. This happens when the threshold for certain resources has been reached.

Some Stalled Move Request errors are straightforward and highlight an existing problem. Some on the other hand just make no sense because there seems to be no problem with the mentioned resources.

In our case, we have triggered just one move request at a time and the I/O operations on the disk where the target mailbox database resides were minimal. But we still got a StalledDueToTarget_DiskLatency status and a Stalled Move Request.

While move requests with a status like Stalledduetohigherpriorityjobs continued after a while , others went in status StalledDueToTarget_DiskLatency or Relinquishedwlmstall and stalled for hours just to resume and stall again and kill the move request.

You can find more on status monitoring of move requests here :   Move Request Status Monitoring

The thresholds , which cause a move request to stall, and the durations are defined in the MSExchangeMailboxReplication.exe.config file located at :

You can find some useful input on this here  : Social Technet Exchange 2016 Migration Status

At the end of the day the most convenient way  for me to make sure that a move request completes was to prioritize each mailbox move request with the -priority switch.

To be honest I never gave high or highest a try , instead of them Emergency was the winner. We still got stalled statuses after triggering move requests with -priority Emergency , but no killer ones.

Avoid a Stalled Move Request with the -priority switch :

As mentioned before, you will probably still see some kind of stalled statuses on your move requests, but they will not end in a loop of stall and resume.

Have a nice day !

 
Got a stalled export request? Read more here:
Stalled Mailbox Export

The post Stalled Move Request Exchange 2016 appeared first on Webbanshee.

Get-MoveRequestStatistics and the switch -IncludeReport

Let’s assume you have triggered a couple of move requests to run at night and you want check their result in the morning.

The following command provides a good overview of the completed move requests :

Next we want to see if there are move requests in any other state than completed :

The output will show moves in states like Queued, InProgress, Failed or any other state.
Should you have move requests with status failed you can grab them and gather more information using the following line :

Message, FailureType and FailureSide will show you the reason for a failed move request and provides information where the error ouccured. ( Source or target side )

Report lists the details step by step for a move reqeust.

BadItemLimit , BadItemsEncoutered, LargeItemLimit and LargeItemsEncountered will show you limits and possible encountered items which quantities are over the given limits.

In many cases corrupted items in the source mailbox can cause the move to fail with too many bad items.
Too many large items can cause the move to fail as well.

With this information at your hand you will hopefully have an entry point to solve the problem and get the move request completed when you resume it. You will need the output of Identity to resume a certain move request.

To only resume the move request :

To resume a move request caused by bad or corrupted items : ( for LargeItems use -LargeItemLimit )

To resume a move request with a BadItem count higher than 50 :

 
Monitoring a New-MailboxExportRequest is similar.
You can use some of the attributes in a MoveRequest as well:

Export Mailbox – New-MailboxExportRequest
 

The post Move Request status monitoring appeared first on Webbanshee.

Removing ( if still there ) the move-requests does not help, even not through ADSIedit.

You think propably moving these mailboxes to another mailbox database again would solve the problem. But you cannot trigger a new move-request for these mailboxes since you receive warnings like this :

The solution is to start the move-request as follows :

-MRSServer :
There will be no switching between CAS servers when peforming the move-request. The move request will completly handeled by the given CAS server.

-DonNotPreserveMailboxSignature : This one is the real solution. Where MailboxSignature is not the lokal Outlook signature you use at the end of an email. This parameter is responsible ( Exchange 2010 ) for the fact , that the user will not notice the mailbox move. Otherwhise the users needs to close Outlook and reconnect. ( This is what will happen when you use the move-request above )

We noticed this behaviour after we have rolled up to 2010 SP3 RU14 .

The post Your mailbox is being moved – Exchange 2010 appeared first on Webbanshee.