I'm in the middle of migrating from Exchange 2013 to 2016. Most of the moves have gone well, however, some mailboxes seem to be getting stuck at Initial Seeding, and then after some hours of stalling here, fail at FailedStuck.
Running Get-MailboxStatistics -IncludeReport shows that the move is stuck running IsInteg because they are large mailboxes. This seems to basically be a New-MailboxRepairRequest that just gets queued indefinitely.
I can run New-MailboxRepairRequest with -Force and it will complete immediately, so I think it's just a workload management issue, but it's been a few days and repairs are still not completing.
Possible Solutions
How can I tell
New-MoveRequestto skip the IsInteg run upfront? I will happily manually run them after the move.How can I edit the Mailbox Repair Requests that the Move Requests creates, with the -Force flag? As far as I can tell there is no
Set-MailboxRepairRequest.How can I disable workload management for mailbox repair requests? As this seems to be what is stalling my moves/repairs, even when nothing is going on (it's the weekend at 4 AM on new hardware, and they won't budge).
How can I raise the "Large Mailbox" threshold (message below alludes to it being a config option). If I set it to something like 50GB, all of the mailboxes will be moved without doing a repair.
More Info
The report shows:
Report : 18/03/2017 12:34:12 AM [EXCH16-SYD-01] Setting up ISInteg repair run upfront for this mailbox since it's a large mailbox.
"Primary mailbox size = 11120110046, Archive mailbox size = 0, Large mailbox size threshold config value = 10737418240
Then:
18/03/2017 12:54:33 AM [EXCH16-SYD-01] Store IsInteg task is pending completion for mailbox '6e6a0983-02ab-4d1d-84ea-d0071e7e6536'. IsInteg
The report repeats this for hours, until it eventually times out because no progress has been made. I eventually found that there is a corresponding
To prove that the workload management is causing problems, I checked for all mailbox repair requests across all mailboxes, and confirmed none of them were in progress.
[PS] C:\Windows\system32>Get-Mailbox -Server EXCH01-SYD | Foreach { Get-MailboxRepairRequest -Mailbox $_.PrimarySMTPAddress.tostring() }
Identity Task Detect Only Job State Progress
-------- ---- ----------- --------- --------
62d54094-6b61-4f1c-a... {MessageId} False Queued 0
...
62d54094-6b61-4f1c-a... {FolderView} False Queued 0
There's 29 repairs here, all of them are queued.
Things to Note
This only happens to mailboxes 10+ GB in size, because that's the threshold limit that causes an IsInteg task to be run before doing the move.
It's the IsInteg that is causing things to get held up. Yet if I do an IsInteg repair with
-Forcethen the repair happens immediately.Even for the IsInteg repairs I am able to do with
-Force(which show as successful), I do not see any event log entries like I am supposed to.My environment is 1x 2013 Exchange and 2x 2016 Exchanges, and 1x 2010 Exchange. All are running the latest CU or RU version.
Moving from 2010 is not a problem, even for mailboxes > 10 GB.
I've been running in Co-existence for a few weeks and migrated my own mailbox from 2013 to 2016 as a test. My mailbox is 15 GB and it did not get queued. This leads me to think if I was patient enough, the others might succeed. But my mailbox did not show FailedStuck and showed constant progress.
I am wondering if I just need to wipe out all the failed moves (right now I simply resume them) and re-try them one by one.
I feel like I've exhausted most of my options, so any advice is appreciated. Even if someone could tell me how to execute some of the "possible solutions" listed. As these are just theoretical solutions to me, I haven't found ways to actually do them.
I found a simple solution to this problem: Downgrade your Exchange 2013 box.
As part of my migration plan, we had 2013 also in its own 2-node DAG. The 2nd node was brand new and had been patched up to the latest CU at the time:
AdminDisplayVersion : Version 15.0 (Build 1236.3) (Exchange 2013 CU14)
The old 2013 node was just patched enough for 2016 co-existence:
AdminDisplayVersion : Version 15.0 (Build 1178.4) (Exchange 2013 CU12)
I recalled that before I'd built the new 2013 box, I was successfully able to migrate a few 15 GB mailboxes over to 2016 without any issues.
During the course of my migrations, I had activated all the mailbox databases on the new node, so of course the CU version on the new node meant all future mailbox moves required a mailbox repair when > 10GB.
The difference is: for the older CU patch level, no mailbox repair is required over 10GB. Similar to Exchange 2010 in this sense. So because no repair/isinteg took place, the move succeeds. I am not sure exactly at what point Exchange 2013 began to require an IsInteg check as part of the migration. I am also not sure if this is "fixed" in later versions.
If need to downgrade to a lower CU, you might be able to build a new 2013 box, setup a DAG and then migrate all your databases over to the older versions.
You can see by comparing the move request reports, that IsInteg is run before any attempt is made to begin transferring the mailbox data, and this is why everything stalls.
Here's an excerpt of a move request that failed, due to the IsInteg check:
Here's an excerpt of a move request that worked, going from 2013 to 2016: