My Articles Support Center

Contact Us

Office 365 Autodiscover Lookup Process

This is a post for reference purposes.  The intent is to look at how Outlook will locate the correct Autodiscover endpoint in a hybrid environment.  This Exchange 2010 SP3 lab has a hybrid configuration with Office 365.  The tenant is called TailspinToysCanada.  Our test mailbox was moved successfully to Office 365.  They are logging onto a domain joined machine which is located on the corporate network, using their credentials.


Autodiscover Configuration

The Autodiscover namespace in this lab is  This is the URL that users will leverage to get the XML response from Exchange.  How do they discover this URL?  

In short the Exchange 2010 CAS server has the AutoDiscoverServiceInternalURI set to the namespace.  This is shown below.

Get-ClientAccessServer | Select Name, *URI | Format-Table -AutoSize

Autodiscover Namespace Set On Exchange 2010 CAS

Note that we are NOT setting URLs on the Autodiscover VirtualDirectory.  Please review the myth busting post for the background on this urban legend.  Setting the AutodiscoverServiceInternalURI is the value which will be returned to Outlook when it does a SCP query.  That is great for internal domain joined machines, what about external or workgroup machines?

For external clients, Autodiscover is configured as a standard A record in the external DNS zone.  This is for  autodiscover.tailspintoys.caand points to the external firewall interface which is configured to pass the traffic to the Exchange 2010 CAS server.

Note that in a hybrid configuration the external Autodiscover namespace must point back to the on-premises Exchange infrastructure and not to Office 365.  This is a common configuration issue as the Office 365 portal complains about missing DNS records.  Ignore the GUI, and check the status of the custom domain using Get-MSOLDomain using PowerShell. The newer portal has addressed this, maybe I’ll add a post with details.  Leave a comment and let me know your thoughts please.

Now that we know the infrastructure, let’s see what Outlook does.


Testing Outlook Autodiscover Lookup Process

This is the Outlook 2013 ProPlus client, version 15.0.4693.1000.  We are using the Test E-Mail AutoConfiguration tool to review the Autodiscover process.

Guesssmart and Secure Guesssmart are for POP and IMAP clients so they are cleared to remove unwanted fluff from the results.

The below screen shot shows the steps Outlook has gone through to locate the correct Autodiscover endpoint for this Office 365 mailbox.  This has been edited to show the following:


Initial Autodiscover Process For Hybrid Mailbox

Line NumberComment
1Autodiscover endpoint located using SCP query
2Client attempts first URL
3Authentication successful to Autodiscover web service using logged on credentials
4Autodiscover unable to answer query as mailbox in O365. 0x800C8205,  Redirect to TargetAddress
5Start from beginning using new SMTP address:
6Autodiscover starts over. Endpoint located using SCP query
7Client attempts first URL
8Authentication successful to Autodiscover web service using logged on credentials
9Autodiscover unable to answer query as mailbox in O365.  Status code:  0x800C8205
10DNS lookup process starts: root domain lookup
11Root domain lookup fails with status: 12007
12Root domain lookup fails with status: 0x8004005
13DNS lookup process continues to next namespace:
14Lookup fails with status: 12029
15Lookup fails with status: 0x800C8203
16Local XML file lookup
17Local XML file lookup fails with status: 0x8004010F
18HTTP Redirect check to:
19Client redirected to shared autodiscover namespace:
20Client submits Autodiscover request
21Authentication needed – 401 response

At this point we are at the shared Outlook Autodiscover service.  We need to authenticate to Office 365 Autodiscover so that it knows who we are, and where to then redirect us.  This is shown in the second section below.  It picks up where the section left off:

Final Autodiscover Process For Hybrid Mailbox

Line NumberComment
22HTTP 302 redirect
23Autodiscover failed with status: 0x800C8204 – redirect was received to a more accurate location
24Autodiscover sent to accurate location
25Autodiscover request issued to
26Authentication needed – 401 response
27Authentication successfully provided
28Autodiscover request submitted
29Autodiscover XML data successfully received


At this point our Outlook client has received the Autodiscover XML response.  This took a few hops, but users do not see this background process so this does not really impact them.

One thing you may be wondering is the TargetAddress mentioned above.  If we look at the attributes defined on an AD user object whose mailbox was migrated to Office 365, we can see the TargetAddress attribute is present on those migrated accounts.

Attributes On Object User-1 - Note The TargetAddress

This is what allows Exchange to shim in the different SMTP address.  Exchange will NOT use as the ultimate delivery address, rather the TargetAddress is used.  In this case it is:

This is provided to the Outlook client when it initially contacted the on-premises Exchange server.  Outlook then uses this to chase down the correct location to send the Autodiscover request. 

Powered by HelpSite