In our previous blog post we covered an overview of what migration endpoints are, how to find them and what makes them tick. In this post, we will cover related troubleshooting. Note that this post h...
Updated Mar 30, 2020
Version 5.0
Blog Post
Mirela_Buru
Microsoft
Microsoftmuraly005 , glad to hear initial issue is fixed. Regarding the root cause, this was published on the Service Incident:
Root cause: The authentication method associated with tenant instance routing for migrating mailboxes in this scenario was configured incorrectly.
Next steps: We're reviewing our Domain Name System routing configurations to gain a better understanding of what caused the instance routing to become initially misconfigured.
For the mailflow issue, this should be treated separately as SMTP traffic doesn't traverse Hybrid Agent. If issue is on-prem to cloud, you would need to enable protocol logging on SMTP send connector and check SMTP Send logs. Additionally, checking message tracking or event viewer logs might help. As common causes: network devices in between, on-premises remote mailbox object missing user@tenant.mail.onmicrosoft.com target address or this missing as a proxy address on the cloud mailbox, certificate or TLS issues etc.
If you are having issues onboarding the mailbox to O365 but Migration Endpoint was created successfully (as original issue has been fixed), you would need to check the Migration Reports (Get-MigrationUserStatistics <user> -IncludeReport -DiagnosticInfo Verbose |FL and Get-MoveRequestStatistics <user> -IncludeReport -DiagnosticInfo Verbose |FL see where exactly it is failing. If a move request is not created, then most likely it fails migration user validation. Again, could be user@tenant.mail.onmicrosoft.com proxy address missing or maybe another smtp domain on the user that is not added as accepted domain in exo, etc.