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.

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

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

http://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 (23)

  1. Anonymous says:

    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

    http://www.luthas.com

  2. Anonymous says:

    valuable information indeed !!!!

  3. Anonymous says:

    this is a good post clearing the different types of moverequest error.

  4. Anonymous says:

    Great information, thank you very much.

  5. Golfer_Kuno says:

    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.

  6. Robin Mathur says:

    Thanks for the useful information !!!

  7. John Constantine says:

    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/

  8. Wim Prins says:

    Thanks for this helpful information.

  9. Mats Rosendahl says:

    Thank you very much. My night just started to be a good night.
    Bye

  10. anon says:

    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???!!!

  11. Alex Pinto says:

    Thank you for this, saved me in a late night mailbox migration 🙂

  12. anas says:

    Thank you verry Much
    saved me

  13. Cris Gates says:

    @ Ricky Mitchum – It worked!. It saved us a lot of time and effort.

    Thank you so much!
    Cris Gates

  14. Fadi says:

    Thank you so much!

  15. zubair says:

    Very informative. Its help me to solve my problem

  16. Roman Black says:

    Thanx a lot, this helps us very very at SBS Migration!!

  17. Lakshman Raju says:

    Wow Awesome Michael. It helped a lot. Can you also provide resolution steps for below FailureType?
    "MAPIExceptionNoAccess"

    Thanks!

    1. Farooque says:

      This is communication error.

      Create your EndPointes again and start the move

    2. Wouldn’t resume work, as soon as you’ve solved the access issue?

  18. Neverest says:

    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.

  19. AJ says:

    I was so after resume-moverequest

    Thanks for that.

  20. Chester says:

    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.

Skip to main content