Microsoft warns IT admins against using this unsupported Exchange Online configuration

Exchange Online is heavily used in enterprise environments. While Microsoft bows to the will of its customers in this space many times - as seen in recent instances of imposing rate limits for external recipients and Auto-Archiving - this is not always the case. Now, the Redmond tech giant is discouraging IT admins from leveraging an Exchange Online configuration, emphasizing that it is unsupported.

Sometimes, IT admins use the New-MoveRequest cmdlet to perform local moves of mailboxes within the same tenant or datacenter. Microsoft explains that while this command exists for historical reasons, the company does not officially support this functionality due to multiple factors.

For starters, Microsoft cannot troubleshoot local moves easily or expedite them. Once these requests get initiated, they are assigned as low-priority background tasks that sometimes take weeks to complete. Moreover, Exchange Online has automated processes (more on those later), so local moves are not really needed as they are quite manual and inefficient. Additionally, there is also the risk of orphaned data, which is defined as follows:

"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."

Microsoft says that local move requests exist because they were originally needed for scenarios like cross-database moves in on-premises Exchange Server 2010. However, this is not required anymore as Exchange Online intelligently handles mailbox placement and load balancing. The cmdlet can still be used to move mailboxes across two different tenants, which is why it still exists.

The Redmond tech giant notes that some IT admins still have misconceptions about local moves, believing that they repair mailbox and data corruption issues or improve performance, but this is not the case. If you do run into these issues, contact Microsoft Support to investigate the root cause instead of initiating a local move, or simply trust Exchange Online automation services, which balance load to resolve performance issues.