Summary: In this post, we will be going through the “Remote move migration doesn't finalize” error in Exchange Server that occurs when moving mailboxes from one database to another or to another server. We will also discuss some possible solutions to resolve this error. Also, we will mention a reliable EDB converter software that can migrate mailboxes to a live Exchange Server database without any issue.
After initiating a remote move migration using the Exchange Admin Center (EAC) or via the Exchange Management Shell (EMS) using the New-MoveRequest PowerShell cmdlet, you may see that the move request doesn’t finish the migration to the destination mailbox database and returns an error similar to the below:
Cannot enter finalization because Data Guarantee is lagging behind by more than 00:05:00. Failure: Database GUID doesn't satisfy the constraint SecondCopy because the commit time <date and time> isn't guaranteed by replication time <date and time>
The error message indicates that the move request doesn’t satisfy the constraint and the database doesn’t meet the required conditions to accept the mailbox move.
You would clear the move request using the Remove-MoveRequest PowerShell cmdlet and re-run the New-MoveRequest command. But the problem reappears.
To further investigate the problem, you check the Event Viewer and configuration of the Exchange Server infrastructure. You may find that the move request fails to complete due to the DataMoveReplicationConstraint setting – a parameter configured in the destination mailbox database, which is set to SecondCopy.
The value of this parameter on the mailbox database determines how many database copies should be evaluated as part of a request. On a new database, this parameter will be set to none. But when it’s set to SecondCopy, this means that the database in question would have a second copy. When this value is set, the databases must meet the Data Guarantee API conditions. The Data Guarantee API checks the health of the database and copies of the database. This means that the error message has occurred because the database might not be healthy, the replay queue is within the 10 minutes of the replay lag time, and the copy queue length is less than 10 logs.
Possible Solutions to Fix “Remote Move Migration doesn’t Finalize” Error
The error can occur on both the source and the destination server. You need to investigate the matter to resolve the issue. Before starting, it is suggested to restart the services and possibly the server in a maintenance window to ensure that there is nothing pending on the Exchange Server or operating system.
Then, run the Get-MailboxDatabaseCopyStatus command in the Exchange Management Shell (EMS) to view the health and status of the mailbox database copies.
This will give an overview of the database in question. If the database is not mounted, then it means there are issues with the database. In addition, it might happen that there is a big lag between the database and the copy due to network, connectivity, or performance of the server. You need to investigate and resolve this.
After this has been resolved, you can try to restart the move migration. If still the problem persists, you can create a new database at the destination (if the issue is on the destination) and create a new move request.
You should always check the Event Logs in the Event Viewer to identify the possible issue which might be stopping the process.
If the problem is on the source database, an option is to migrate the data to a new database. But you cannot initiate a move. Another option is to disable the data move replication constraints from the source database with the Set-MailboxDatabase PowerShell command (see the below example).
Set-MailboxDatabase -Identity <mailbox database name> -DataMoveReplicationConstraint None
This will remove the constraints which are failing. However, it must be used as a last resort.
Conclusion
If the above solutions fail, then the option is to restore from the database from healthy backup or use the New-MailboxExportRequest command to export all the mailboxes to PST and then import them into a new database. This process is a very lengthy one with many points of failures. Also, you will not be able to export public folders.
In such cases, you can use third-party EDB to PST Converter software that can ensure full compliance, compatibility, and no data loss. Tools like Stellar Converter for EDB can assist in the matter. With this tool, you can open multiple Exchange Server databases – live or not mounted. You can granularly export the data to PST and other file formats. You can easily create a new database and export the EDB data directly to a live Exchange Server database, with automatic mailbox matching. This tool can process any resource of Exchange Server with ease, such as user mailboxes, shared mailboxes, disabled mailboxes, user archives, and public folders. This helps reduce the downtime for the users while resolving the problem with peace of mind.
