In the previous articles I showed you how to implement DirSync, create an Exchange hybrid environment with a migration endpoint and how to migrate Mailboxes from Exchange on-premises to Exchange Online. Not a single word on autodiscover though, and even when autodiscover is pointing to your on-premises Exchange environment, it continues to work for Mailboxes that have been migrated to Exchange Online. This is one of the advantages of an Exchange hybrid scenario.
This is what happens: when you move a Mailbox from Exchange on-premises to Exchange Online, the Mailbox on-premises is converted to a Mail-Enabled User (Remote Mailbox) and a target address is set to Exchange Online (i.e. firstname.lastname@example.org).
When an Outlook client does an Autodiscover request to the Exchange environment it detects the user is a Mail-Enabled User, and that a target address is set. Based on this target address a new Autodiscover request is initiated. So, Outlook does a request for a user called email@example.com, Autodiscover returns a Mail-Enabled User with target address firstname.lastname@example.org. Next, Outlook wil try an Autodiscover request for this SMTP address.
The best way to show this is by using the Remote Connectivity Analyzer on http:/www.testexchangeconnectivity.com. In the RCA select the Office 365 tab and check Outlook Autodiscover in the Microsoft Office Outlook Connectivity Tests section.
Enter email address, user account and password, enter the verification code and click Perform Test. In the top section of the screen you’ll see that RCA is able to contact autodiscover.exchangelab.nl and retrieve an XML Autodiscover request for email address email@example.com:
When you expand the Additional Details, more information is shown about the information being returned by the Exchange server:
Clearly visible is the redirectAddr property and the email address firstname.lastname@example.org.
RCA will then try to continue based on this SMTP address. It will fail on several methods, but continue on the HTTP redirect option:
When you expand the Additional Details option under the HTTP redirect method, the autodiscover information is shown for the email@example.com (which is the same as firstname.lastname@example.org email address) user:
So, when moving Mailboxes from Exchange on-premises to Exchange Online in a hybrid scenario, there’s no need to change the autodiscover DNS record from on-premises to online. Even better, as long as there are resources on-premises you should leave the DNS record pointing to autodiscover on-premises.
7 thoughts on “Autodiscover in a hybrid scenario”
Hi jaap, we have ABC.com and DEF.com in hybrid , all DEF.com users are in cloud and some ABC.com users are in cloud or on-perm. We still have public folders on perm. Can we switch autodiscover for DEF.com to office 365?
As long as you have resources on-premises that need to be accesses you have to keep autodiscover pointing to on-premises Exchange. If not, the resource won’t be discoverable anymore.
autodiscover.def.com now points to Office 365 (prior to running the HCW) as all mailboxes are there.
when we run the HCW for both domains (abc and def) is it no problem to keep autodiscover pointing to office 365 or will HCW fail?
and what would be adviseable, run HCW and use ‘Autodiscover Domain Feature’ for def.com or use only autodiscoer def.com and not use ‘Autodiscover Domain Feature’ (autod:) ?
and lastly will DNS record autodiscover get higher prio or will autod: be used if both are configured?
Hi, we have Exchange 2010 on-prem where autodiscovers is not setup. Does this prevent us from deploying a Hybrid server? Do we need to configure Autodiscover before we can rung the HCW? If yes, do we then need to get a new SSL Cert with the Autodiscover URL in the subject alternative name?
The HCW will run, it will generate an error message at the end that autodiscover is not working, and you won’t have any functionality afterwards (well, maybe SMTP is configured correctly) so you have to configure Autodiscover. Yes, you need a SSL cert with Autodiscover in the subject alternative name field.
We migrated all mailboxes to 365. For internal domain-joined users autodiscover is pointed via SCP to look at 365. Users outside our network have autodiscover pointed to 365 via CNAME in external DNS. The problem is autodiscover is failing for non domain-joined users in our network (Cant connect outlook to 365 mailbox). Our internal domain is .local, while in 365 it is .com. Creating an internal cname record will not help since .local zone. Any ideas on a solution for this? Thank you very much.
I cannot remember the name of such a DNS solution, but basically you create a DNS zone autodiscover.contoso.com (including the autodiscover!) and point this to the correct location (i.e. your internal Exchange server or Exchange Online).