Many organizations are migrating from on-premises Exchange Server to Office 365 (Exchange Online) due to the attractive prices and the number of features that latter offers. There are different approaches for migration, such as staged migration and cutover migration. But when you need a smooth migration with no business interruption, the best approach would be to use the hybrid migration method.
With the hybrid method, you can have the Exchange Online and on-premises Exchange Server working as one and you can gradually move the mailboxes to the Exchange Online. When all the resources and mailboxes have been moved, you can decommission the local Exchange Servers. Migration of mailboxes can be done one-by-one depending on the batch sizes and the size of the mailboxes. This can be done without user interruption.
Once a batch job is created and confirmed, the process will start to synchronize the mailboxes selected. If all is configured well and there is no issue with your Exchange Server and tenant configuration for Exchange Online, you’ll face no issues.
However, during the synchronization of the mailboxes, you may find that the Exchange Server certificate has expired. This could have been tackled beforehand. In such a case, the migration can take a long time to complete. So, something like this might have been overseen by the migration and Exchange Server admins.
The certificate was renewed and the renewed certificate was installed. So far so good! But after looking at the status of the mailboxes being synchronized, you may notice that the state is FailedOther (see the below screenshot).
This can be noticed by running the below PowerShell command in the Exchange Management Shell (EMS).
Get-MigrationBatch
This will get you a summary of all the migrations, along with the status of the migration. To get more information on the failed mailboxes, you need to note the email address and use the FL parameter to get all the information.
Get-MigrationBatch <user email address> | FL
This will return a lot of information.
RunspaceId : fd25c343-7be6-4ca4-a3f4-9ee0a17a40ad Identity : bob smith Status : Synced State : Active DataConsistencyScore : Good Flags : None WorkflowStage : Processing TriggeredAction : None BatchGuid : 323f1939-a28a-4d1c-aa55-d378c769b596 TotalCount : 1 ActiveCount : 0 StoppedCount : 0 SyncedCount : 1 FinalizedCount : 0 FailedCount : 0 CompletedWithWarningCount : 0 PendingCount : 0 ProvisionedCount : 0 ValidationWarningCount : 0 ValidationWarnings : {}
Still there will be no specific information on why the synchronization is stopped. If there is no relevant information, you need to use a different approach to dig deeper into the affected mailbox to get more information. You can use the below command.
$mbreport = Get-MoveRequestStatistics <Affected User> -IncludeReport $mbreport.report.Failures[-1]
This will show the relevant errors in the move request of the specified user. If the issue was during the renewal of the certificate, you will see a similar error as given below.
DataContextData : StackTrace : InnerException : CommunicationError TransientException: The call to 'https:// srv-tst-001.ex2019.lan /EWS/mrsproxy.svc' failed. Error details: Could not establish trust relationship for the SSL/TLS secure channel with authority ' srv-tst-001.ex2019.lan. --> The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. --> The remote certificate is invalid according to the validation procedure.. --> Could not establish trust relationship for the SSL/TLS secure channel with authority 'srv-tst-001.ex2019.lan'. --> The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. --> The remote certificate is invalid according to the validation procedure. UnknownElements : UnknownAttributes : XmlSchemaType :
As you can see from the message, the issue is with the security validation and the trust between the parties cannot be established.
In such a situation, there are two things to try. The first one is to wait until the migration process tries to restore the migration. But if the issue persists, check that all the other mailboxes have finished and take stock of what was synchronized. Then, you can stop the migration batch by using the below command.
Stop-MigrationBatch -Identity <Migration batch name>
It may happen that you have various failed mailboxes in different batches. In this case, you need to make a list of all the mailboxes that have failed as once the migration is deleted, you cannot have a list of the mailboxes. So, it’s best to first make an inventory of failed mailboxes and the corresponding migration batch.
Once the migration batch is at a full stop, a new migration batch needs to be created with the missing or failed mailboxes. This should work and the synchronization should restart. There could be cases where after the migration batch has been recreated, you may face the same or new issues.
In such cases, it is suggested to use a third-party application, such as Stellar Converter for EDB ( https://www.stellarinfo.com/email-repair/edb-pst-converter.php ).
The application comes in handy in sticky situations like these. The application can open live and offline EDB files from any version of Exchange Server and migrate Exchange database (EDB) to PST and other formats. You can also export directly to a live Exchange Server database or Office 365 tenant. This EDB to PST Converter is the right tool to reduce cost, administration burden, and complications while gaining performance and peace of mind.
Conclusion
Hybrid migration can be a bit complex and would require additional administrative efforts to set up. When an issue occurs, you might find a lot of burden trying to fix the issue while migrating the mailboxes. This would result in more delays for the migration to happen. With the above-mentioned tool, you can reduce the waiting time for migration. It offers great performance, migration of mailboxes with auto matching, and supports migration of public folders with minimal impact and administrative effort.
