In a short announcement posted over at the MTC, Microsoft announced plans to retire the self-service mailbox move functionality in Exchange Online. Said feature, made available via the New-MoveRequest cmdlet few years back, was initially launched as a tool to allow admins to initiate go-local moves.
Its use however quickly spread beyond that scenario, as moving the mailbox to a different database has the side effect of restamping some properties and fixing some rather common issues. It also helps in situations when the MRM processing of the mailbox fails, say due to some issue with the underlying hardware, which Microsoft’s monitoring failed to capture in a timely manner.
Personally, I’ve used the cmdlet several times in my own small tenant, mostly as troubleshooting tools for such minor problems. As I keep my PowerShell transcripts, I can see that the first such use was around the end of 2016, so the cmdlet has been useful to me for at least three good years. It’s biggest benefit is probably the fact that it allowed you to avoid raising a support issue and dealing with the not-so-competent agents.
As pointed by an observant user over at the MTC, even Microsoft’s own documentation articles recommend the use of this cmdlet as troubleshooting tool. So there is definitely some demand for it. But unless Microsoft steps back on their plans, you can expect the cmdlet to stop functioning in little more than a month’s time.
P.S. None of this affects the on-/off-boarding mailbox moves, just “in-service” ones.
2 thoughts on “Microsoft to retire New-MoveRequest for local mailbox moves in Office 365”
Until a few months ago, we used new-moverequest quite often as we have a reasonable size tenant and was frequently used to address odd problems that there was no other solution for. For the last month we have been arguing with a Microsoft support tech who insists this still works, even though we had it fail on us months ago and we have had to request Microsoft to do a number of move requests since. We currently have a number of moverequests ‘InProgress’, at the insistance of this support tech, which I am sure will eventually change their status to ‘Failed’ as did the last one we ran. Unfortunately it seems to takes days if not weeks for the status to switch to Failed and I can’t seem to convince this support tech that it doesn’t work until they see that it has failed.
I’ve used this around 4 times in the 4 years we’ve been in 365, and you’re right – it can actually appear at least to fix various issues we’ve seen ranging from performance to access problems. I get why it may be a pain for MS to keep having to honour these requests but surely if they’re happening they need to address why and give an alternative way to fix these things.
Agree on the support I’m afraid.