Sign up for Office 365
Learn more about Office 365
Thanks for the feedback.
Hello KL Wong,
Are you trying to move mailbox for users to Office 365 with New-MoveRequest? Is there any error message during the movement?
Just for the information, the value of PositionInQueue specifies the request's position in the queue (Position/Queue Length). If you want to review the list of the current Move Requests and their status, you can use cmdlet Get-MoveRequest to retrieve all of the move requests information.
For more information about Get-MoveRequest, please see article below.
Yes I think I understand that is my queue position, but are there anyway to speed that up ?
The problem is we roughly know how long it will take to move the mailbox based on historical statistics, but the 'queue' time is unknown to us and we have difficulties to plan the mailbox migration, because not everybody can afford a longer than expected downtime.
It seems to me the queue size is a global setting and not by customer ??
Hello Kl Wong,
Thank you for your update.
Before going further, could you let us know the version of Exchange server you are running in your on-premise domain?
If the mailbox server is running Exchange 2007 SP2 or higher in your on-premise domain, the mailbox move from on-premise to Office 365 will be in online mode. With online move the user will have access of the mailbox until the last couple of minutes of the move when the mailbox is then locked and the user is locked out of access. And the user will have to close and reopen Outlook. After that, Outlook client will be updated with the new mailbox server location and the user will then be able to access their data.
Meanwhile, Move Requests can be managed in the Exchange Management Console (EMC) or using powershell commands. However, the time of mailbox moving depends on the size of mailbox and network bandwidth. The Percent Complete and Mailbox size are not displayed in EMC because the information that you see in the EMC the vast majority is pulled from active directory. If these information is pulled from the database for a large number of users, it would slow down the displaying information in EMC considerably. This is because that information on mailbox size and percent complete can change rather rapidly. To view the status of move request, you should run the cmdlet Get-MoveRequestStatistics to view in depth information.
By the way, the polling intervals for how often the mailbox replication service checks for move requests and the number of moves that a single CAS server can make is controlled by settings in file MSExchangeMailboxReplication.exe.config, which is located in the \Program Files\Microsoft\Exchange\V14\Bin folder on Hybrid server.
The queue is with Office365 not on premise. We sort of resolve the problem, being wait wait wait...
Thank you for letting us know the concern.
To load balancing the moves across multiple mailbox servers and protect server performance, the MRS service will throttle the number of mailbox moves that can be processed simultaneously. Other move requests will be queued and active once another request has been processed. For this situation, to reduce the impact of mailbox moving, I would suggest you to do this during non-peak or non-working hours.
Thank you for your understanding.
Jack, what is the non-peak and non-working hours. I am indeed performing my mailbox move during non-peak and non-working hours and it has been queuing for 4 hours now. !!
Thank you for your reply.
Before going further, could you let us know if the move request was processed? For non-peak and non-working hours problem, since the mailbox will be locked when moving mailbox from a legacy exchange server (earlier than Exchange Server 2007 SP2), you can move mailboxes for users in your non-peak or non-working time to reduce the impact of mailbox moving to users.
If the issue persist, please post back the result of following cmdlet to allow us to understand the problem status in more details.
Get-MoveRequestStatistics alias -IncludeReport | fl
Yes the move request eventually get processed, and we already schedule this during our non-peak non working hours. But consider the following:
- we have a request on queue for 10 hours now, the time I am typing this.
- we estimate the move will take 10 hours
So assuming the request start process now, it will take 20 hours to complete the move, which no matter we schedule it on our non-peak non-working hours, user wont be able to access their mailbox during business hours the next day. If we process it only over the weekend, then it will take us ages to finish all mailboxes.
Hope this make sense.
Do you still need the moverequeststatistics information ? As the output has got our organisation information in it which I do not know if it is appropriate to post it here.
Thank you for your update. I am glad that the mailbox move requests are processing now. For this situation, it is not necessary to review the output information of Get-MoveRequestStatistics cmdlet. If the move request is failed, you can send that log to me using private message.
Yes, since it may take some hours to allow move request to be started and completed, it is recommended to schedule this during your non-peak or non-working hours. Meanwhile, if any move request has not been complete on next business day, you can also remove that move request with Remove-MoveRequest cmdlet, and schedule it during next non-working time.
Thank you for your cooperation.
Yes I know. That is why it is very frustrated !!
Sorry for coming into this too late, the problem you are running into is throttling on the O365 side. I ran into this during the big BPOS to O365 transition a few months back. It wasn't anything we were doing but there were tens or hundreds of thousands of mailbox moves so we would see our mailboxes in 21/21 or something similar. We resolved it by requesting a temporary throttling increase through support, but it had to be escalated a few times before they did it. The initial response was 'we can't do that', but after pressing on A LOT they did it.
I have a similar issue. I have created 2 new users today and created on premises mailboxes for them. Forced a dirsycn and gave the users a E3 license. I have not logged into those mailboxes yet and therefore the size is 0KB yet then have both been queued for over 2 hours now.
Thanks for your post. ERS service busy will cause this kind of issue , you can wait couple hours more to see any improvement. Further, you can see the service health of your tenant to check the Exchange online service status.
Thansk, Neo Zhu
One has gone through after 4 hours but the other one is still in queue and it has been now 18 hours. The service health is shows no issue
Just as Jorge shared in the previous post, this behavior happens due to the throttling on the Office 365 to load balancing the moves across multiple mailbox servers and protect server performance. For your situation, to reduce the impact of mailbox moving, I would suggest you to do this during your non-peak or non-working hours.
Meanwhile, if these move request failed to be processed, to resolve the problem more effectively, it is recommended to post a new thread for your problem in the forum. Please include the output information of following cmdlet in the new thread.