When configuring an Exchange Online hybrid deployment, there are many things to consider. Asides from the various networking, certificate and client discussions there is also a requirement to ensure that Autodiscover is functioning correctly. In addition to having Autodiscover correctly published to the Internet an additional wrinkle commonly pops up, which takes people down the wrong garden path… This is the helpful DNS page in the Office 365 admin center.
Before we move on, be clear that we are discussing Exchange hybrid and in this deployment model Autodiscover must point to the on-premises Exchange infrastructure.
Taking The Wrong Path
When opening up the admin center, the below sight will greet many – note that there is a reported “issue” with the custom domain which was previously added (tailspintoys.ca).
Clicking the “Fix Issues” link will show something like the below. We are interested in the highlighted Autodiscover line for the purposes of this discussion:
The Office 365 admin center is deeply unhappy since the Autodiscover namespace is NOT pointing to Office 365. If this were a simple cloud only deployment, then the UI is correct. However the UI is not checking to see if Exchange Hybrid is/was deployed, and this is where the wrinkle comes in. I have seen multiple deployment consultants blindly repoint Autodiscover to Office 365 just because the portal indicated so.
Taking The Correct Path
We must add and verify all of the required domains to use them with Office 365. Not adding a domain is not really a fix as it cannot then be used. What was added to help with this issue is actually on the previous screenshot, but is often skipped. The relevant area on the upper right hand side of the screen is highlighted below:
If we check the box to disable the DNS record checks, the page is updated to:
Clicking close will return us to the previous page. Note the difference compared to the very first image that we looked at. In the one below, note that there are no issues reported, but it does state that the DNS check is turned off. By doing this, the visual temptation to reconfigure Autodiscover is removed.
If there is a requirement to see what DNS records are required, for example to update the SPF or MX, the DNS check can be temporarily re-enabled the records reviewed and then disabled once again.
The Autodiscover lookup process for an Office 365 Outlook client is discussed in detail in this previous post.
Additionally there seems to be a desire to disable the SCP lookup for users when the mailbox is moved to Office 365. We need to ensure that the Autodiscover redirect process is applied so that the correct address is then used for the chase down. I can certainly see why people want to exclude the root domain lookup (https://contoso.com/Autodiscover/Autodiscover.xml), and that is something which I commonly do. This reviewed in Outlook Prompts For Domain Certificate Unexpectedly.
A lot of the online documentation is written for the cloud only customer, and the hybrid deployment is not the intended target for those pieces of documentaiton – example and example. This page does mention that the Autodiscover CNAME should not be created in the Exchange hybrid scenario, though the warning is not highlighted and is at the end of the section.