Disabling New-MoveRequest for Local Mailbox Moves

vgabriel That's part of what we intend to accomplish with this change. As of today, moves can fix a large set of issues and that's why they became popular as a troubleshooting tool. But to play with a couple of examples. Let's say a user search catalog becomes corrupt, which is essentially what happens when OWA can't run searches, and you as the tenant admin trigger a move for that shard. The nature of moving will, as of today, recreate the catalog which will fix the problem. However, it took you multiple days to copy the entire content of the mailbox to fix this while we could have a simpler tool that simply recreated the catalog in place and fixed the problem much faster. Today we might get an occasional escalation of a user in this state since most of the time moves are being used to self-fix this. This means that practically we won't give much priority to fixing this over introducing new features or investing the time into areas that improve user experience in other ways. Another scenario that moves were used to fix a problem was when specific properties on an item got corrupt. For example, a calendar item start time got modified so it now starts after the meeting ends. If we use a move for this scenario we end up re-writing the entire content of the mailbox to fix a single item, and this is rather heavy handed. So the ideal solution here is to have a mailbox repair action that can fix this. 

I know this change sounds heavy handed and inconsiderate, but our aim here really is to force us to make the product better. If you can't use this catch-all tool to fix random issues we must either automate detection and fix of certain cases or provide tenant admins with a way to trigger the fixes. For example, if search index corruption is a common occurrence we must be able to detect and react to it before admins have to, or if the occurrence is rare enough that detection becomes too expensive we may provide a New-MailboxRepairRequest fix or similar tool that allows admins to correct the problems. However, as long as people hide the problems from us by simply moving the mailboxes we cannot know which issues need to be addressed automatically and which ones need a dedicated tool, or even if there's an issue we're unaware of.