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 straight forward 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 :
C:\Program Files\Microsoft\Exchange Server\V15\Bin
You can find some useful input on this here : Social Technet Exchange 2016 Migration Status
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 :
New-MoveRequest -Identity “Mailbox.You@WantTo.Move” -TargetDatabase “TargetMailboxDatabaseName” -Priority Emergency
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 !1 Like