As many of you might know, we move mailboxes between different databases in the cloud to balance the load. This is done daily through local move requests automatically triggered by our Mailbox Load Balancing service.
A few years ago, we launched the GoLocal program, enabling customer data to reside in datacenters local to their geographic location (NorthAmerica, Europe, Asia/Pacific, etc.). As part of this program we also exposed New-MoveRequest to tenant admins to help them expedite the moves of individual or small sets of mailboxes. Currently the service that load balances mailboxes is used to manage these moves, and over the years our service has become quite efficient at managing the load, more so than tenant admins utilizing the admin portal or PowerShell.
As a result, we have decided to disable the use of New-MoveRequest for manual moves within our datacenters and only allow New-MoveRequest to be used for migrating to and off of Exchange Online.
We also understand that customers use New-MoveRequest to solve some minor configuration issues that occasionally cropped up, as the move would also re-stamp properties onto mailboxes, sometimes resolving issues with any values that needed correcting. In some cases, Support also applied this same method, but due to policies in place for either instance, this could often take days to weeks to complete. In many cases, a resolution can be achieved almost immediately without moving the mailbox, so our recommendation is that admins contact support for resolution of problems as opposed to attempting to fix the mailboxes on their own.
If you’ve ever used New-MoveRequest to creatively solve a problem we’d love to hear about it. We really want to make sure you have the tools you need to solve the problems you see, or if nothing else, to make sure we do!
Please expect to see this change take effect after April 15, 2020.
The Exchange Migration Team
Used this command countless times to fix random issues with mailboxes. One I could think of off hand is when we had some users in who couldn't access Outlook on the Web.
They were getting the error MailboxInTransitException when trying to access it.
New-moverequest saved the day and fixed their mailboxes.
I have, more than once. For those minor issues indeed, but nothing beats not having to go over the process of opening a support ticket :)
@Vasil Michev I hear ya....if Exchange Online Tier 1 support wasn't so bad it wouldn't be a problem to open a ticket when you would need help for these issues, but it's back and forth a few times before they realize you know what you are talking about and escalate. Having to NOT call support is my goal most the time.
I second JasonSCarter's comment. Tier 1 support is cumbersome and time consuming. If we have to open a ticket for minor issues that would be a bummer. It would also be interesting why you disable this functionality...? Cheers Christian
You might want to update pages that tell customers to resolve issues by doing mailbox move:
If Customer Key hasn't completely encrypted the mailbox after 72 hours from the time you assign a new DEP, initiate a mailbox move. To do this, use the New-MoveRequest cmdlet and provide the alias of the mailbox. For example:
This tool is a tremendous help to fix oddities with mailboxes. One of the most common issues is when the Deletions folder (under Recoverable Deleted Items section) is not properly purging items. One of the user visible symptoms is rejecting Calendar requests.
new-mailboxmove also resolves search issue in Outlook Web (your request can't be completed right now). I believe it re-indexes the content during move.
It is a shame that this will be depreciated. In many cases this is the only thing that helps in case of random oddities.
I agree with the above posts. You're taking away a tool that I've regularly used to resolve user problems in a more timely manner than I could by opening a ticket. I'm not happy about this heavy handed move that impacts my ability to manage my company's environment.
Sounds like a bad idea..
i always try to fix it on my own before I have to open a ticket. And that’s just because of all the sometimes really questions the first support service is asking.
Is this deprecation because of a technical background?? Maybe someone knows more about it ?
This seems like a super bad idea. Countless times we have fixed broken mailboxes by initiating a move, and your own documentation and premier support have suggested it on multiple occasions. Admittedly it is a hack in that the move process effectively runs a sanity check on the mailbox and corrects problems, but removing this functionality without providing an alternative will leave us with broken mailboxes that will take weeks to solve via the very slow support processes.
As a member of Microsoft support team who works with mailbox moves a lot, I wanted to add a few thoughts on this subject. We know that this CMDlet has been used to temporarily solve issues. Fact is that moving mailboxes around the datacenter with the hope to find a ‘better database’ or a ‘different server’ which might temporarily fix a particular issue is definitely not something that we expect (or want) our customers to do. Engineering and support want to be aware of issues so that they can be permanently addressed. Also note that if you move mailboxes around, the event history data might be lost so we, support, can't analyze things and tell you what went wrong in the first place.
That is why it is important to call support and ask for help.
I am sorry to hear about poor experience with us, support team, but we are trying to do our best. We also need time to understand your issue so when you talk to us, we need to collect data and do troubleshooting before trying to fix it. We know that before engaging us, you already spent some time understanding the problem and testing it thoroughly. But have patience with support, we are helping both customers and engineering when customers engage us, and the fact is that vast majority of our customer interactions are solved once we learn what is really going on.
Mirela, thank you for the answer but the issue is not that we are hunting for a better server, is that various mailbox corruption issues are fixed in the move processes. I don't think we much care in which data center a user resides, and if we had a way to run a mailbox health check and correction process outside the mailbox move process we would not need this particular cmdlet. Multiple types support engineers have suggested this exact process, usually after days of debugging while the user is broken and can not get work done. In one such occasion we had a suicide hotline mailbox stuck for about a week while waiting on an answer, via premium support, and a mailbox move fixed the issue. I hope you understand that this is not the sort of thing we can wait on.
Let me expand on the post just a little. Someone above requested the technical background so I'll try to include some of it here also. The reasons for removal are basically 3-fold:
It masks issues in the service:
Performance / Hardware / Environmental issues - if there are issues with a particular database or server and for some reason our monitoring fails to detect it: If customers move their mailbox for troubleshooting in this scenario, it could fix their issue, but how many more mailboxes are still on that database/server that are impacted? Additionally, if it's a performance issue, your move will likely be heavily throttled on the source side and not be able to move anyway. If the move finally is able to complete, it is probably because the load had already been reduced by our other self-healing processes inside the service, which means the issue was probably already resolved before it completed and it gives you a false sense of accomplishing something.
Software Issues - new software versions deploy in Exchange Online continuously, we do our best to be bug-free, but there is the occasional problem that needs to be addressed. If you are affected by some issue caused by a software update, moving your mailbox to another server might temporarily provide some relief but it is likely to come back very soon when your new server gets updated to the same version. If we don't know about a problem, we can't fix it.
It delays issue resolution:
Moves take a long time and they don't solve most issues. We're talking about tons of data in mailboxes these days. Moving a mailbox can mean moving up to 300GB of data with Primary + Archive + Recoverable items in both. This means moves today can take an incredibly long time to complete both due to the size and the fact that we can't prioritize these moves over critical things like mail flow and client access. If we wait for a move to complete every time we have a problem, we could be adding weeks or even months to resolving a problem. It is much better to get the problem to the right people so they can fix it permanently. That's why we're here; please let us know if you're having a problem so we can make the product better.
MoveRequests for local moves are difficult to maintain:
Exchange doesn't just store mailbox data anymore. That's right, we've got lots of data in Exchange mailboxes for services across the Office 365 suite of services. Most of this data is stored in mailboxes that are linked to users, similar to primary mailboxes and archive mailboxes, but not exactly the same. Internally our load-balancing machinery uses new technology that understands all these different types of mailboxes; unfortunately New-MoveRequest does not. New-MoveRequest for Exchange Online is intended for moving mailboxes into and out of Exchange Online from on-premises environments. Continuing to use New-MoveRequest for local moves would create a situation where customers executing local moves are the only ones running some of this code; this makes it very easy to introduce bugs. Bugs in moves are scary, because they likely result in data loss. Instead, we will limit New-MoveRequest to onboarding and offboarding which it knows how to do well, reducing the likelihood of introducing bugs that result in potential data loss.
Do you think you can make available the error correction part of the cmdlet as a standalone tool for the reasons multiple people have listed in this thread?
If that is the case, then you really need to make Tier 1 support WAY better. If we are going to be unable to fix our own issues, we don't want to have to jump through hoops with basic troubleshooting we have already done before opening a ticket. I don't know how many times I have provided logs upon opening the ticket, for those to be ignored by Tier 1, and they just read from a script and ask for them again. Some cases just aren't meant to be handled by Tier 1, and there seems to be roadblocks put in place to prevent us from getting to the person who can actually understand the problem. We pay for Premier support, and since we can no longer do Office 365/Azure tickets through that method, and have to use the ticket mechanisms in the portals, the support experience has gotten so much worse.
@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.
@Otavio_MSFTI understand the logic and I can appreciate that position. One the other hand I have submitted Design Change Requests that were accepted by the product team that are not actually implemented a year later, so I may be a bit mistrusting of the notion that identified issues would have fixes or tools implemented in a timely manner while losing the only tool we currently have to fix those issues.
Perhaps as an alternative leave the cmdlet in place but add logging and reporting to it that you can collect and analyze to determine the root causes of the issues we are solving using this method instead of removing it.
@Otavio_MSFT I understand the need to make the product better, but until tools are developed and worked on and made available to us, we are stuck waiting days for support to even start getting to the root cause on a issue because of all the hoops Tier 1 makes you jump through that 9 times out of 10, aren't useful to the overall solution to the case. Customers will be struggling, and us admins will have users who have issues that will be getting upset with us sys admins over our inability to provide a fix in a timely manner. If you make our support experience much better, we may not be so resistant to this. We have other things to do besides go back and forth collecting some of the cumbersome information asked of us sometimes and it gets frustrating. Especially when have encountered the issue before. Once you get passed that Tier 1 roadblock, Tier 2 and above have always been knowledgeable and helpful and quick to solve issues.
In my case the New-MoveRequest was the only way to complete a public folder onboarding from onprem to Exchange Online. As you know, the onboarding process is all or nothing, and might takes days to sync the data from on-premises to Exchange Online. In all 4 attempts, the Exchange Online DB load scheduler actually locked down the target databases, preventing us from completing the migration. The only solution that worked after 2 SEVA tickets was to actually move the PFmailboxes using the CMDlet.
In my case, I have used many times to fix Mobile Outlook(Intune) issues and also to fix corrupt items. The command is useful at any point when to fix a issue before contacting Support.. There should be some alternate to this one atlest for admins.
I recommend figuring out a way to run a capture of when this cmdlet is run to identify patterns and corruption in databases. This makes more sense than taking away a valuable tool from your customers and requiring them to jump through an additional hoop to resolve an issue. Taking this approach would be a win win for Microsoft and the customers rather than essentially forcing administrators to open a ticket which in turn introduces burden and impacts customer experience.
I use 'New-MoveRequest ' solved many issues for my staffs, like the search index does not work. I don't understand what's the reason to take out 'New-MoveRequest ' but no replacement. I do not like the change, don't see the point to get rid of 'New-MoveRequest '.
Is there another way now to instantly revoke an "access token" for a user on Exchange Online? We have the means to revoke a "refresh token" but existing access tokens would still be valid on the EXO back-end for up to 1hr. Today in our playbooks we do a "move request" on EXO side to invalidate the access token. So now that the move request cmdlet is going to be removed will there be another way to accomplish this?
I've been using mailbox moves for 23 years to fix weird issues, including corrupted items. I really hope Microsoft will reconsider keeping this command.
This is bad move on Microsoft's part. This is used to fix countless issues with mailboxes. We as an Admin of our own environment that PAY for a subscription, can't fix our own data. We now need to call Microsoft to fix an issue. This wastes more time on the end users who may be down. Last time I called for this it took two weeks to move the mailbox, and Microsoft said tier 3 said there was nothing else they could have done to fix the issue. I was almost better off exporting to a PST removing the mailbox and re-create it, then import it again. Again this is a bad move!
I don't agree with de-commissioning this command. After our migration, I've had at least four user's mailboxes that needed to be re-indexed. It will not be the last time I hear about it either.
We are talking about mailbox sizes of 11GB all the way up to 82GB. It is necessary for the continuation of this command to be executed by Exchange Admins because the Search function in OWA are very explicit when accepting the orders to search for a specific name, subject, email address. It works if you're savvy with using the Search functionality and my users are understanding of it's capability however, in four cases already, non of the workarounds I provided are working.
So I have to execute New-MoveRequest -Identity UserName@contoso.com in order to get this functionality back to our users.
Please reconsider the tickets you will be receiving globally at your Help Desk from organizations like ours.
@bradhugh Then please instruct your Tier 1 to read the initial ticket information, since it happens too often that support are asking initial questions where the answer is already given when submitting the ticket.
I almost feel like just submitting an incident topic and nothing else.
We use this to fix corrupted mailboxes as a new-morerequest forces a consistency check on the mailbox. This saves us from at-least 1-2 calls a week.
Please Please Please re-consider!
This is problematic for us. We use new-moverequest to force mailbox move between mult-geo datacenters to be GDPR compliant. We have noticed that the "automatic" moves are not timely.
Please give an alternate method of performing this function.
@dheymanatl as we understand it (but I'm not a lawyer), there is no requirement for data residency in GDPR. We also did not sell the multi-geo feature to help meet any regulatory requirement. Multi-geo relocations that are automatically scheduled by our system run at a higher priority than those you would create manually. If you find something isn't working or we're not meeting the expected times documented with relocating mailboxes, please open a ticket. We definitely want to know these things.
I litterly just use this cmdlet today to resolve an issue where our law department was running an export of a mailbox and was getting errors with the export. After disabling and recreating the mailbox on the exchange server (which did not resolve the issue), i moved the mailbox using this cmdlet and this has resolved the issue.
i could not count how many times i have run this cmdlet and it has helped troubleshoot/resolve mailbox issues. if I had to call into a support ticket each time I ran into issues like this, it would really limit my ability to quickly resolve mailbox issues.
if we are going to repurpose this cmdlet can we have an alternative cmdlet we can use for these purposes?
Just in the last month I have had to use this command over 20 times and who knows how many times my exchange team has used it total. We had somewhere between 20 - 50 conference rooms stop working. Meetings would only show up on the organizer's calendar and not attendees calendars. After uploading countless logs over many days, Microsoft told us to move the calendars. This worked great. I also had 2 users that out of the blue could not access their email. Both outlook and owa would not let them in. I moved the mailbox and they work fine. If this command is removed, we will be opening a few sev A tickets each week.
Now for my personal view on a few things. As someone from Microsoft said above, "new software versions deploy in Exchange Online continuously, we do our best to be bug-free, but there is the occasional problem that needs to be addressed." This is very obvious to the company I work for. We have had probably 3 company wide issues in the last 2 weeks related to new software being deployed in Exchange Online. STOP! How about a quarterly update or some type of a schedule? Also from above, I keep reading that Microsoft says open tickets so we will know there are problems. Does anyone else see this as Microsoft asking it's tenants to de-bug their code?
I basically get what the team is trying to achieve. Fixing those bugs that are normally undetected because admins use a move request to "fix" things is a good thing. However, as many mentioned before, working with 1st level support is often a hassle. Those people obviously only follow some predefined lists of things and don't look left or right. Meaning that even if you send all the evidence - logs, etc. - they still ask for the evidence :( So PLS(!) if you remove the tool, work together with support to improve the experience! Otherwise customers (admins) will be very upset and spread the bad news. Not a good scenario for Microsoft...
The last two IMAP migrations I performed required me to run this command to complete the cutover in evening hours during scheduled downtime due to I have no idea what corruption took place from the migration tool, your migration tool. If I had to call support and submit a ticket to perform a simple mailbox repair I would have had 3 clients with inaccessible mailboxes on the first project and 1 on the second. Those tickets likely would have taken days to resolve. The mailbox moves for the mailboxes that were mostly a couple gig in size, took a couple hours, and were all done before the maintenance windows ended.
And now I'm reading that you want to take that tool away because people being able to run mailbox repairs using the only tool you have provided is de-prioritizing your development of a proper tool to repair mailboxes. After spending literally over two decades repairing mailboxes with move requests per your documentation you now decide it is not proper and want to take the ability away prior to developing a proper tool for the process.
I don't see the logic...
Disappointing that we now have to log a ticket with MS to resolve mailbox issues, another solution should have been given prior to removing functionality..
I have a user who can't access his email via Outlook365 all of sudden, it keeps asking for password. The OWA and Phone App are working fine. I tried a couple of different computers, all have the same issue with this user's mailbox. I have opened a ticket with MS support, and it has been 4 days with no progress.
I was planning to move his mailbox this weekend and I am pretty sure this will fix this weird issue. Then I found this article, what a bummer.
However, I did a test using new-moverequest on one mailbox, it still worked and got the mailbox moved to a different datastore.
Can someone please confirm if this command gets retired or not?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.