다음을 통해 공유

Managing failed mailbox move requests

  • 아티클

If you haven’t seen my mailbox migration tool yet, go and have a look at it here. It’s been working great for me and my customers that have been using it. If you have a large amount of mailboxes to move it definitely helps with the management and automation of the process.

I'm also working on one for on-premise migrations and will hopefully release it soon. 

In a previous article, I mentioned that I’ll be giving you some tips on what to do with Failed move requests...the time has arrived.

First, it’s important to understand how move requests work. I highly recommend that you read the TechNet article on mailbox move requests.

https://technet.microsoft.com/en-us/library/dd298174(v=exchg.141).aspx

Then, understand the parameters of the new-moverequest cmdlet:

https://technet.microsoft.com/en-us/library/dd351123(v=exchg.150).aspx

First, I need to check why my move requests failed. Let's use the following PowerShell code:

 get-moverequest -movestatus Failed|get-moverequeststatistics|select DisplayName,SyncStage,Failure*,Message,PercentComplete,largeitemsencountered,baditemsencountered|ft -autosize

Let’s cover a few scenarios (there is obviously many other scenarios that you might experience):

  1. You kick off a new move request and it fails at x% with a Too Many Bad Items error.
  2. You kick off a new move request and it fails at x% with a Too Many Large Items error.
  3. You kick off a new move request and it fails at x% with a HTTP request is unauthorized error.

So, what do we do in the above scenario’s, let’s cover each one and you’ll get the picture on where I’m trying to go with this article.

Scenario 1:

This issue occurs when the number of bad items encountered exceeds the bad item limit. By default if you don’t specify a bad item limit the move request will fail if it encounters any bad items.

I’m not going to go into much detail around bad items, but from my understanding these items are usually MIME properties from e-mail clients that do not comply with the MIME standard.  In the past Exchange (E2k3 and E12) didn’t understand the illegal properties that do not comply with the MIME standard so when it tries to index these illegal properties it may encounter corruption. Exchange 2010/2013 simply excludes these items in new messages and blocks these corrupted properties when mailbox items are moved from older Exchange versions, thus the bad items.

You can see a report of the bad items by running the following:

 get-moverequeststatistics –includereport

Pheeww, ok let’s get back to the issue at hand. We need to skip these bad items, but we don’t want the move to start from scratch. Huh? That doesn’t make sense.

Well, many folk think that when a move request fails the data disappears on the target side, when in actual fact the move request is still available and the synchronized data will not be removed unless you clear the move request for that specific mailbox.

Let’s say we encountered 9 Bad Items. We checked the move request report and confirmed its bad properties or calendar properties.

So we modify the current move request to skip those items.

 get-moverequest 'Jackie Chan'|set-moverequest –baditemlimit 10

Next, we resume our move request to continue where it failed:

 resume-moverequest 'Jackie Chan'

You'll notice the move request just continues and doesn't start with an InitialSeeding. Happy days !

Let’s move on to the next scenario.

Scenario 2:

I’m sure you already know that moving a mailbox to Exchange Online requires that individual item sizes be less than 35 MB. If you kick of a move request it will fail with a large item limit exception when it hits that item that’s larger than 35 MB.

I covered the large items in this article where I gave you a PowerShell script that you can run to report on any mailboxes that have items larger than 35MB. You can use the report to find the item and get the user to back up the item somewhere safe.

So you’ve cleared all the large items (let’s say there were 3 items) in the mailbox and you don’t want to restart the 10GB mailbox move…aargh!

Don’t fret, let’s modify the move request.

 get-moverequest 'Jackie Chan'|set-moverequest –LargeItemLimit 3

Next, we resume our move request to continue where it failed:

 resume-moverequest 'Jackie Chan'

Happy days are here again...

Scenario 3:

I personally haven’t encountered this scenario a lot, but what seems to happen is the connection to the remote server encounters some kind of issue and the move request fails with a HTTP request unauthorized error.

In this scenario, I re-credential the move request with the remote credentials for the Exchange On-Premise organization.

 $onpremcreds = get-credential
get-moverequest 'Jackie Chan'|Set-moverequest –remotecredential $onpremcreds

Next, we resume our move request to continue where it failed:

 Resume-moverequest 'Jackie Chan'

Are you getting excited about this? I hope so, because this saved me endless migration issues, especially migrations to Exchange Online where you don’t have gigabit connectivity to the target database.

The above approaches can obviously be used with on-premise migrations as well.

Until next time,

Happy mailbox migrations!!

Michael Hall

Comments

  • Anonymous
    January 01, 2003
    I can not tell you how helpful this was for us.. Currently in the middle of several massive migrations at once. Awesome share Michael!

    Dame Luthas
    Senior Technical Architect
    United Nations International Computing Centre

    www.luthas.com

  • Anonymous
    January 01, 2003
    valuable information indeed !!!!

  • Anonymous
    January 01, 2003
    this is a good post clearing the different types of moverequest error.

  • Anonymous
    January 01, 2003
    Thank you very much.

  • Anonymous
    January 01, 2003
    Great information, thank you very much.

  • Anonymous
    November 26, 2013
    Great info... very useful. I ma just wondering if you ever encountered a failed migration due to  "TooManyMissingItems" ? I can't seem to see an option on set-moverequest for "TooManyMissingItems"... your input on this would be much appreciated. Thank you.

  • Anonymous
    February 19, 2014
    Thanks for the useful information !!!

  • Anonymous
    February 19, 2014
    Good explanation !!. Corrupted items in Mailboxes create problem in migration from one version to another version of Exchange Server. Due to the corrupt items in Exchange databases, It takes too much time and efforts to move from one platform to another. But, there are some third party tools available in the market which has made this process simple, quick, and easy by providing excellent features. Such tools are designed with advanced scanning technology to rebuilds the corrupted items prior to migration. One such program that helped us, is here: http://www.techricky.com/exchange-server-recovery/

  • Anonymous
    April 03, 2014
    Thanks for this helpful information.

  • Anonymous
    August 27, 2014
    Thank you very much. My night just started to be a good night.
    Bye

  • Anonymous
    May 26, 2015
    so... i did a move request batch of users, ended up running out of disk space so the last user who happened to have a 10GB+ mailbox failed. So I extended the disk space, then kicked off the request again, but now it just sits there - just says 'sync'ing' in the console, doesn't get passed 0%. its stuck. now what???!!!

  • Anonymous
    September 02, 2015
    Thank you for this, saved me in a late night mailbox migration :)

  • Anonymous
    November 11, 2015
    Thank you verry Much
    saved me

  • Anonymous
    November 13, 2015
    @ Ricky Mitchum - It worked!. It saved us a lot of time and effort.

    Thank you so much!
    Cris Gates

  • Anonymous
    November 27, 2015
    Thank you so much!

  • Anonymous
    February 11, 2016
    Very informative. Its help me to solve my problem

  • Anonymous
    March 08, 2016
    Thanx a lot, this helps us very very at SBS Migration!!

  • Anonymous
    March 08, 2016
    Wow Awesome Michael. It helped a lot. Can you also provide resolution steps for below FailureType?
    "MAPIExceptionNoAccess"

    Thanks!

    • Anonymous
      October 10, 2016
      This is communication error.Create your EndPointes again and start the move
    • Anonymous
      October 31, 2016
      Wouldn't resume work, as soon as you've solved the access issue?

  • Anonymous
    October 12, 2016
    Thanks! I had started a batch with an old on prem password a couple of days ago and changed password before I finalized. The whole batch failed. Starting script over again with correct password helped nothing. Trying to finalize a single user helped nothing. It was scenario 3 that saved the day. Error: The call to 'https://owa.contoso.com/EWS/mrsproxy.svc' failed. Error details: The HTTP request is unauthorized with client authentication scheme 'Negotiate'. The authentication header received from the server was 'Negotiate,NTLM,Basic realm="owa.contoso.com"'. --> The remote server returned an error: (401) Unauthorized.. --> The HTTP request is unauthorized with client authentication scheme 'Negotiate'. The authentication header received from the server was 'Negotiate,NTLM,Basic realm="owa.contoso.com"'. --> The remote server returned an error: (401) Unauthorized.

  • Anonymous
    April 04, 2017
    I was so after resume-moverequestThanks for that.

  • Anonymous
    April 27, 2017
    Appreciating the dedication you put into your website and detailed information you present. It's awesome to come across a blog every once in a while that isn't the same outdated rehashed information. Great read! I've saved your site and I'm adding your RSS feeds to my Google account.