In today’s post we will be discussing some of the problems Garage of Awesome Consulting (GoAC) encountered in a recent on premise Exchange to O365 migration, but before we get into the problem lets have a quick look at the existing configuration.
The company in question was using a 2010 Exchange server running on Windows Server 2008 R2, in a farm which included a 2008 R2 Exchange server purely for signatures.
Garage of Awesome was contracted to migrate to Exchange Online, so we had requested a 2016 Exchange server to be spun up and added to the farm right away. Once this was done, we began work on installing the hybrid connection. In part 1 we will look at our initial testing, the issue we encountered, and how we came to resolve it.
Testing hybrid connectivity
Using a Microsoft Hybrid Management PowerShell script, we can test connections to Exchange Online servers and services. This script is recommended by Microsoft, and gives good results with very few issues.
After calling the script we use the Test-Hybridconnectivity cmdlet and specify we want to test O365 endpoints:
- Test-HybridConnectivity -Test0365Endpoint
.
The result of our testing gave us the incredibly helpful “An unexpected error occurred on receive.” A quick Google search of the error shows nothing relevant.
Our first thoughts were obviously to check that all URLs and IP addresses required by Microsoft had been whitelisted in the company Firewall. If you are one of the unfortunates using a Firewall that doesn’t have an “Automatically whitelist all Microsoft” toggle switch you will need to grab all the URLs and addresses here and enter them manually. After updating a few URLs manually, and confirming they were correct, we tested again and received the same error.
Running through the server side logs we eventually found this was an issue with TLS versions and Ciphers used. This was deduced when the hybrid connector was also having strange issues that pointed to certificates.
Using a handy Exchange health PowerShell script (fully supported by Microsoft) we found that the 2016 and 2010 server where using multiple versions of TLS and Ciphers, with some mismatch between them.
Going by Microsoft best practice we know that we should only be using TLS 1.2 and AES Ciphers for the strongest cryptography. We ran through with some automated tools to do the heavy lifting and set the below registry keys.
After we enabled only the TLS and Cipher versions that are secure (and recommended by both MS and ASCS), one reboot later, and ran our TLS tests again to verify the changes in TLS as shown below
Running our Hybrid Connectivity test again also shows no more errors and what looks like a network connectivity issue is resolved:
It should be noted that to make the change to TLS 1.2 Exchange 2010 and 2013 boxes (if present) should be updated with the latest Cumulative Update rollups. Failing to do so will put a stop to mail flowing within your organization before you even make a start on hybridisation!
In part 2 we will move on to running through the Hybrid Connection Wizard.
Great post