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

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 Bad Items encountered error.
2. You kick off a new move request and it fails at x% with a Large Items encountered 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
Set-moverequest ‘Jackie Chan’ –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