So far in this series of posts we have prepared our domain, firewalls and proxy servers for Office 365. We have configured our internal and external DNS. We have prepared our UPNs and built our Exchange 2016 hybrid migration server. We have also configured Azure to make sure that when it receives our Active Directory data it is secure. Then we configured Azure Active Directory Connect to sync our on-premise AD with Azure AD. The next step is now the fun part, to configure the Exchange Hybrid Migration Wizard. This is essentially making a forest trust between our on-premise environment and Exchange online. It will enable us to setup our full hybrid model so that mail will continue to flow through the existing Exchange 2010 server but allow us to move mailboxes to Office 365.
For us to proceed with the Exchange Hybrid Configuration Wizard we will assume that the following has now been done:
- Exchange Hybrid server built (verify ability to manage Exchange 2010 server from Exchange 2016 console)
- Exchange 2016 server updated to CU (see here for all build numbers)
- 3rd party certificate installed on hybrid server
- External DNS records added: hybrid.mydomain.com autodiscover.mydomain.com
- EWS URLs configured
1. Download the Hybrid Configuration Wizard from the download link here and run the executable.
2. Click Next to continue
3. We now choose the server that we want to perform the hybrid migration. This is the Exchange 2016 hybrid server.
4. At this step we enter the on-premise credentials, I created an account called O365onpremsvc this is a member of Domain Admins, Enterprise Admins and Organisation Management. Then enter the details for the Office 365 service account O365cloudsvc@mydomain.onmicrosoft.com (which is a global administrator).
5. At this point we discover if there are any connection problems, all being well we will get x6 green dots for both Exchange and Office 365, then click next to continue.
6. The next stage is regarding the mail flow within your organisation. As our current on-premise Exchange configuration is secure and compliant we will route through this for incoming and outgoing mail. To route though on-premise for incoming mail we just need to leave the mx record pointed to the on-premise infrastructure. To route outbound we need to check the box below to Enable centralized mail transport.
7. Click enable to setup the federation trust.
8. Select the domains from your existing configuration that you want to migrate.
9. Follow the instructions to create a TXT record with the tokens shown in each of your domains to prove domain ownership. Once you have done this click verify domain ownership.
At this stage this just seemed to sit there on ‘verifying domain ownership’. The only way to get more information is by consulting the Hybrid Wizard log, but you are still presented with a very generic error.
You must create a new file named SystemConfigurationTasks.Overrides.ini and save it to the Exchange config folder C:\Program Files\Microsoft\Exchange Server\V15\Config\
The content of the file must be as follows:
[SystemConfigurationTasks.settings.ini:FederationTrustFromCache]
Enabled=False
Once the file is created, you can either manually complete the Federation Trust setup through the Exchange Admin Center or run the Hybrid Wizard again.
10. Select Configure my Client Access and Mailbox servers for secure mail transport. Then select Enable centralized mail transport.
There is more information on centralized transport here. Essentially this is what the option does:
If you select the enable centralized mail transport check box, you’ll configure the routing of all mail from mailboxes in the Exchange Online organization through the on-premises organization before they’re delivered to the Internet. Because the Hybrid Configuration wizard doesn’t update the MX record for your organization, incoming email for Exchange Online-based mailboxes from external recipients is also routed through the on-premises Exchange organization. This approach is helpful mainly in compliance scenarios where all mail to and from the Internet must be processed by on-premises servers.
If you don’t select the enable centralized mail transport check box, Exchange Online mailboxes will be configured to deliver messages for external recipients directly to the Internet and bypass your on-premises organization.
For a complete description of the inbound routing process see here. As we want all inbound mail routed though the Exchange server what we want is this:
If you decide to keep your MX record pointed to your on-premises organization All messages sent to any recipient in either organization will be routed through your on-premises organization first. A message addressed to a recipient that’s located in Exchange Online will be routed first through your on-premises organization and then delivered to the recipient in Exchange Online. This route can be helpful for organizations where you have compliance policies that require messages sent to and from an organization be examined by a journaling solution. If you pick this option, Exchange Online Protection will not be able to effectively scan for spam messages.
11. At this stage we choose the Exchange 2016 server so that a receive connector can be created for incoming mail from Exchange online.
12. We then choose the Exchange 2016 server again as the Send Connector.
13. We can now choose the earlier installed GoDaddy certificate to use for securing the transport.
14. We next enter an externally resolvable FQDN for mail flow. This is the external DNS address of the Exchange 2016 server which is hybrid.mydomain.com.
15. Once we click the update button all the changes we have made will be committed.
16. Allow the wizard to complete all the changes requested.
17. Initially I received a few errors, this was all due to a routing problem with the company firewalls.
The wizard had set the Autodiscover endpoint URL that as the error above states was set to a domain that was not our primary I needed to change it from wrongdomain.com. This could be changed in the Office 365 Exchange admin center under Organization>Organization Sharing>Select Edit. I could then set the URLs correctly as below.
The next problem was that the HCW had failed to create a migration endpoint. The solution is to open the Office 365 Exchange Admin center and click Recipients>Migration>Migration Endpoints
Click to add a new Migration Endpoint and give it a name.
Enter the on-premise details when required.
Enter the external name of the hybrid Exchange server, then click Next and then New.
Initially mail flowed from the On-premise Exchange server and externally to the migrated Office 365 users but they could not send. After checking the mail flow logs in the Exchange Online Admin console I could see sent mail was successfully delivered to the hybrid server.
I next ran the following command on the hybrid server:
Get-MessageTrackingLog -ResultSize Unlimited -Sender "o365user1@mydomain.com" | export-csv c:\failedevents.csv
This showed me the problem which was this ‘No suitable shadow servers’. It basically meant that there were no servers to forward mail to. I was missing a receive connector on the Exchange 2010 server.
The final step was to create a receive connector on the Exchange 2010 server.
This was setup as follows:
18. You may see the error below in the Exchange 2010 console this is normal, this is just how it’s handled in Exchange 2010.
The value of the property “TlsDomainCapabilities” exists only on “EXCH2010\Default Frontend EXCH2010” receive connector on Exchange 2016 server and only after hybrid wizard completion. The Object is set and managed in Exchange 2016, Exchange 2010 doesn’t know how to convert the “DomainCapabilities” property.
The error can be safely ignored and there is no issue with your mail flow. We should not use Exchange 2010 to monitor Exchange 2016 objects. It is recommended to use Exchange 2016 management tool to manage objects and features in Exchange 2010.
