In Exchange Online, administrators sometimes consider using the New-MoveRequest cmdlet to move mailboxes within the same tenant or datacenter. While this command exists for historical reasons, Microsoft does not support local move requests. This post explains why, what risks they pose, and what alternatives you should use instead.
While Microsoft mentioned in the past that we would disable the local move requests, we did not. While we agree that sometimes they can be useful to fix things (in some specific circumstances), we want to be clear that we don’t support the use of local move requests nor do we recommend it. Use them at your own risk.
Why local moves are problematic
Local move requests were originally designed for cross-database moves in on-premises Exchange Server 2010 and Remote Move Requests for Exchange hybrid onboarding/offboarding scenarios where we move mailboxes to and from Exchange Online. Later, we added functionality to migrate mailboxes within two different tenants (cross-tenant migrations) that use the same underlying New-MoveRequest command, as well as multi-Geo customers who have mailboxes in different regions within the same tenant. In the Microsoft 365 cloud environment, mailbox placement and balancing are handled automatically by the service. Forcing a manual move intra-tenant introduces several issues:
- Unsupported: Microsoft Support cannot troubleshoot or expedite local moves. These requests are treated as low-priority background tasks and may take weeks to complete. For more information, see Resource Based Throttling and Prioritization in Exchange Online Migrations | Microsoft Community Hub. When the admin initiates a move to a random target server in the datacenter, you won’t know if that target server is overloaded or waiting to be put into maintenance soon. Or you might overload that server due to a big mailbox move and then we must wait on Automatic Load Balancing to detect and fix the server situation. Since local move initiated by the admin is not supported, there is no expected duration of the local move request. On the other hand, there is an estimate of durations for load balanced automated moves within Exchange Online: Microsoft 365 and Office 365 migration performance and best practices | Microsoft Learn
- Risk of orphaned data: Move requests can be used for Primary Mailboxes as well as MainArchive Mailboxes. While it is true that Local Move Requests can be used to move Primary and MainArchive shards within the datacenter environment, you should be very cautious in using it. When it comes to updating the user at the end of the local move, be aware that this update code knows only about the properties on the user that point to the Primary and MainArchive shards. If, somehow, you have managed to inject a New-MoveRequest against a MailboxLocation-based shard (e.g. ComponentShared or AuxArchive shard) then the completion code will not only not update the database of the MailboxLocation-based shard, but it will also dialtone (orphan) the Primary shard by resetting its own Database property. You have been warned.
- Automation has replaced manual moves: Exchange Online uses intelligent load balancing and automated repair processes. Manual local moves are unnecessary and often counterproductive.
Common misconceptions
- Local moves “repair” all mailbox issues and data corruption. At a basic level, a move request moves a mailbox from one database to another, and no explicit repairs are done. However, a mailbox move means that the service recreates all the items in the target mailbox, and therefore it can certainly leave some bad stuff behind if something was wrong in the source. But note that situations where a mailbox move is used to troubleshoot something are really exceptions rather than best practice, because it might do nothing about a particular problem the mailbox is experiencing and – even worse, it might make it impossible to track down the root cause of the problem.
- Local moves improve mailbox performance. They don’t. Mailbox performance depends on service-level optimizations, not manual relocation. Your mailbox can land on a more resource constrained server if you manually move it (successfully).
What to do instead of considering local moves
If you encounter mailbox issues or need to recreate data, use supported methods:
- Address the root cause: open a support case with Microsoft to properly investigate and resolve the issue. The engineering team can sometimes choose to move a mailbox, but this process is well thought out and with valid reasons. We also supervise it.
- Rely on Service Automation: Exchange Online continuously monitors and rebalances mailbox placement. Manual intervention is rarely needed.
Do’s and don’ts
Do:
- Investigate root causes of mailbox issues.
- Trust the service’s automated load balancing for optimal performance.
Don’t:
- Initiate local move requests within Exchange Online.
- Attempt shard-level moves or auxiliary archive moves using local move requests.
- Expect Support to accelerate or troubleshoot local moves.
Exchange Online Migration Team
