Office 365 Exchange Hybrid Deployments Busting The Autodiscover Myth


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).

Office 365 Admin Center - DNS Possible Service Issues

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:

Office 365 Admin Center - Add The Following DNS Entries

 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:

Office 365 Admin Center - Ignore These False Prophets

If we check the box to disable the DNS record checks, the page is updated to:

Office 365 Admin Center - DNS Check Disabled

 

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.

Office 365 Admin Center - DNS Check Disabled

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.

 

Bootnote

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.

Do Not Add Office 365 CNAME DNS For Hybrid Deployments

 

Cheers,

Rhoderick

Comments (2)

  1. David says:

    Can you confirm as well as doing these Externally. Should the same records be done Internally for O365 mailboxes even on a hybrid configuration. And also should the SCP Internal Autodiscover be set to NULL

Skip to main content