Attempting to move an archive mailbox from one mailbox database to another in Exchange 2016 takes a long time

Problem

You’re attempting to move an archive mailbox of a user from one mailbox database to another in Exchange 2016 but notice that Status in the EAC appears to be stuck in Syncing for a long time and does not complete:

The statistics of the migration request indicates data is either being moved very slowly or not moving at all because the Last synced time can be hours before the current time:

Statistics

Created by: a-tluk@domain.com

Create time: 4/10/2017 8:51:52 AM

Start time: 4/10/2017 8:51:52 AM

Initial sync time:

Initial sync duration:

Last synced time: 4/10/2017 10:24:29 AM

Opening the details of the migration request via the View details link shows the migration rate listed as 0 bytes

mjoell@domain.com

Status: Syncing

mjoell@domain.com

Skipped item details

Data migrated: 1.376 GB ‎(1,477,282,535 bytes)‎

Migration rate: 0 B ‎(0 bytes)‎

Error:

Report: mjoell@domain.com Download the report for this user

Last successful sync date: 4/10/2017 10:41:38 AM

Status:

Queued duration: 00:00:09.5392418

In-progress duration: 00:12:19.0602398

Synced duration: 00:00:00

Stalled duration: 01:32:35.5891119

Opening the properties of the move request and navigating to the migration reports section does not show any reports available:

Solution

There could be various reasons why a migration request could appear to be forever syncing and not completing but for the example above, the reason why the move is taking a long time can be found by using the following cmdlets to obtain more information.

Begin by verifying that the cmdlet is displaying the same results as the EAC GUI:

Get-MigrationBatch -identity "Move Marchelle's archive to EMAR02" -includereport

Continue by listing the detailed statistics of the move requests in the queue:

Get-MoveRequest | Get-MoveRequestStatistics

Notice that the StatusDetail column display StalledDueToTarget_Mdb… in the screenshot above.

To view the full description of the StatusDetail column, execute the following:

Get-MoveRequestStatistics -Identity "Marchelle Joell" | Format-Wide -Property StatusDetail

Notice that the StatusDetail is shown as StalledDueToTarget_MdbReplication.

Reviewing the following TechNet article:

---------------------------------------------------------------------------------------------------------------------------------------------------------

Exchange 2016 Migration Status
https://social.technet.microsoft.com/wiki/contents/articles/36516.exchange-2016-migration-status.aspx

Explains the Stalledduetotarget_mdbreplication status as:

Stalledduetotarget_mdbreplication:
This value is also returned from Data Guarantee API on checking the replication health of the target database copies if they are a member of DAG and have database copies.
We might get this message if the MRS service is waiting to get this information from the target server about the replication status of the database copies.

So, in this case, the passive copy must be:
1) Healthy.
2) Must have a replay queue with 10 mins of replay lag time.
3) Have a copy queue length less than 10 logs.
4) Have an average copy queue length less than 10 logs.

---------------------------------------------------------------------------------------------------------------------------------------------------------

In the example above, the reason why the migration is taking so long is because there is a delay with the replication between the servers in the DAG hosting the target mailbox database.  This can be determined by reviewing the passive copy’s Copy queue length:

I’ve noticed that the environment I was working in would have this value jump between 0 to 50, which basically indicates there’s a slight replication delay between the two servers in the DAG.  The archive mailbox move is indeed being moved but at a very slow pace.  This can be verified by executing:

Get-MoveRequest | Get-MoveRequestStatistics

… or:

Get-MoveRequestStatistics -Identity "Marchelle Joell"

… and confirming that the value for PercentComplete is indeed increasing:

The only options you’ll have if the above is your scenario is to either correct the replication delay or simply wait for a longer duration to move the archive mailbox due to the problem.