This is the second post in my two-part series about best practices and “gotchas” for migrating emails to Office 365/Exchange Online. In this post we’ll look at the lessons learned while doing a Hybrid Exchange migration, a process we first covered in this post.
- It is a good idea to have your MX record pointing to Office 365 only, for many reasons. But be careful and make sure that if your organization uses a domain name like company.lan or company.local, keep in mind that in order for Directory Synchronization to work properly, and hybrid mail flow, that you will have to add an internet rout-able domain (.com) to your AD and assign that domain as your users’ UPN (User Principle Name). Otherwise you will run into problems with mail flowing to your on-premises mailbox after changing the MX record.
- As a part of the setup, the Hybrid configuration automatically sets up the outbound and inbound connectors to allow for mail flow to occur on-premises to Office 365. The Hybrid Configuration wizards will initially setup these automatically, but something to remember is to change these connectors to use Opportunistic TLS vs. Forced TLS that is originally set on. These settings can be changed from the Exchange Online Admin portal under Mail Flow, and then Connectors.
- Mail flow to the on-premises organization also may be stopped because of the name of the server displaying on the Exchange Servers Banner from an EHLO command. By default, the Hybrid configuration wizard will put the external FQDN of your Exchange Server on the internal receive connector. So when Office 365 connects via that connector, if the banner names don’t match, it will put a stop on all traffic being sent to that connector, i.e., all on-premises mailboxes.
- In case there’s a need to setup UM on a Lync on-premises server, make sure to add the hosted UM server as EXAP.um.outlook.com, and make sure to setup the custom domain name in Office 365 to be authoritative. This can only be done by using PowerShell with the Microsoft Online or Windows Azure AD module installed.
- Use the Exchange Online Portal to initiate Mailbox moves rather than using the on-premises Exchange Server to do the remote mailbox moves. This provides more insight on the status of mailbox moves, and will display any errors more easily by doing it from the Exchange Management Console on-premises.
These are the best tricks I’ve gathered so far in the migrations I’ve completed for various GNet Group clients. What other best practices or “gotchas” have you found helpful in Office 365 migrations?