1

Office 365 Autodiscover Lookup Process

Update 12-1-2022 Please see this post which covers the newer Outlook client logic.  Content below will be left as-is for a historical perspective.

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 User-1@tailspintoys.ca 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 autodiscover.tailspintoys.ca.  This is the URL that users will leverage to get the XML response from Exchange.  How do they discover this URL?  See this post for the full details.

In short the Exchange 2010 CAS server has the AutoDiscoverServiceInternalURI set to the autodiscover.tailspintoys.ca 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.ca and 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:

  • User SMTP address is highlighted
  • Currently viewing the Log tab
  • Each response line has been manually numbered
  • Since the dialog cannot be resized the bottom portion was overlaid so all results were in a single image for readability purposes

Initial Autodiscover Process For Hybrid Mailbox

Line Number Comment
1 Autodiscover endpoint located using SCP query
2 Client attempts first URL
3 Authentication successful to Autodiscover web service using logged on credentials
4 Autodiscover unable to answer query as mailbox in O365. 0x800C8205,  Redirect to TargetAddress
5 Start from beginning using new SMTP address:  user-1@TailspinToysCanada.mail.onmicrosoft.com
6 Autodiscover starts over. Endpoint located using SCP query
7 Client attempts first URL
8 Authentication successful to Autodiscover web service using logged on credentials
9 Autodiscover unable to answer query as mailbox in O365.  Status code:  0x800C8205
10 DNS lookup process starts: root domain lookup  domain.com
11 Root domain lookup fails with status: 12007
12 Root domain lookup fails with status: 0x8004005
13 DNS lookup process continues to next namespace: autodiscover.MicrosoftOnlineRoutingdomain.com
14 Lookup fails with status: 12029
15 Lookup fails with status: 0x800C8203
16 Local XML file lookup
17 Local XML file lookup fails with status: 0x8004010F
18 HTTP Redirect check to: autodiscover.MicrosoftOnlineRoutingdomain.com
19 Client redirected to shared autodiscover namespace:  autodiscover-s.outlook.com
20 Client submits Autodiscover request
21 Authentication 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 Number Comment
22 HTTP 302 redirect
23 Autodiscover failed with status: 0x800C8204 – redirect was received to a more accurate location
24 Autodiscover sent to accurate location pod51042.outlook.com
25 Autodiscover request issued to pod51042.outlook.com
26 Authentication needed – 401 response
27 Authentication successfully provided
28 Autodiscover request submitted
29 Autodiscover XML data successfully received

Phew!

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 user-1@tailspintoys.ca as the ultimate delivery address, rather the TargetAddress is used.  In this case it is:

User-1@TailspintoysCanada.mail.onmicrosoft.com

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.

DNS Records We Met Along The Way

<Tenuous link to Bob Marley>

We looked for the following DNS records in our journey so far:

  1. autodiscover.tailspintoys.ca
  2. TailspinToysCanada.Mail.OnMicrosoft.com
  3. Autodiscover.TailspinToysCanada.Mail.OnMicrosoft.com
  4. autodiscover-s.outlook.com
  5. pod51042.outlook.com (this is where my tenant exists, yours will likely be different)

The Autodiscover.TailspinToysCanada.Mail.OnMicrosoft.com is used twice.  Once with HTTPS and then for the HTTP redirect.

Some of these names do not exist in DNS, whilst others have some additional aliases.  We can use Nslookup to query for records.  The DNS server in the internal DC which is then performs recursion on behalf of the resolver.

Nslookup Showing DNS Records Used With Autodiscover

(Click to zoom in to the image)

Outlook 2010 And Outlook Autodiscover 2013 Differences

Outlook 2013 changed its Autodiscover behaviour slightly.  In short it does the SCP lookup but also chases down DNS entries simultaneously so that should the SCP lookup fail, the DNS records are already cached.  It does not really show you this in the Test E-Mail AutoConfiguration tool, but Netmon never lies!  In addition Outlook 2013 also introduced the feature of caching the last successful URL.

The below is an example of Outlook 2010 running on the same machine, as the user above.  Note that with Outlook 2010 there is a single HTTP redirect query which consists of a question and answer.  The destination IP is an external IPv4 address 157.244.217.  This IP is shown in the Nslookup results above.

Outlook 2010 Network Monitor HTTP Traffic

Outlook 2013 has two separate queries.

Note that you can see Outlook 2013 querying for an HTTP redirect to an internal IP in this example 10.0.0.8 which is the IP of the CAS.  Then 5 seconds later it does the same external HTTP redirect check that Outlook 2010 performed above.  The HTTP 302 redirect is also highlighted in the bottom section

Outlook 2013 Network Monitor HTTP Traffic

 

To filter out unwanted junk, the following Netmon filter was used to filter out two unwanted process from the results leaving the remaining HTTP traffic displayed:

HTTP and  !(ProcessName == "WaAppAgent.exe") and !(ProcessName == "WindowsAzureGuestAgent.exe")

Netmon Filter Used To Filter Out Multiple Process

Outlook Diagnostic Logging Reference

It is also possible to see the Autodiscover flow through Outlook diagnostic logging.  To apply the change, Outlook must be restarted.  The logs are kept in the %TEMP% folder, and we are interested in the olkdisc.log file.  I use the %TEMP% variable as that removes having to consider where that user’s temp location is.  On the above test machine it is currently C:UsersUser-1AppDataLocalTemp3.  Using %TEMP% is way easier!

An excerpt from this test account shows:

  Autodiscover to https://autodiscover.tailspintoys.ca/Autodiscover/Autodiscover.xml Failed (0x800C8205)
  Autodiscover to https://TailspinToysCanada.mail.onmicrosoft.com/autodiscover/autodiscover.xml starting
  AutoDiscover doing Pre-Auth with saved data.
  AutoDiscover PRE-AUTH pcreds->dwAuthScheme:
    <NONE>
  GetLastError=12007; httpStatus=0.
  Autodiscover to https://TailspinToysCanada.mail.onmicrosoft.com/autodiscover/autodiscover.xml Failed (0x800C8203)
  Autodiscover to https://autodiscover.TailspinToysCanada.mail.onmicrosoft.com/autodiscover/autodiscover.xml starting
  AutoDiscover doing Pre-Auth with saved data.
  AutoDiscover PRE-AUTH pcreds->dwAuthScheme:
    <NONE>
  GetLastError=12029; httpStatus=0.
  Autodiscover to https://autodiscover.TailspinToysCanada.mail.onmicrosoft.com/autodiscover/autodiscover.xml Failed (0x800C8203)
  Local autodiscover for TailspinToysCanada.mail.onmicrosoft.com starting
  Local autodiscover for TailspinToysCanada.mail.onmicrosoft.com Failed (0x8004010F)
  Redirect check to http://autodiscover.TailspinToysCanada.mail.onmicrosoft.com/autodiscover/autodiscover.xml starting
    Autodiscover URL redirection to https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml
    Autodiscover to https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml starting
    AutoDiscover doing Pre-Auth with saved data.
    AutoDiscover PRE-AUTH pcreds->dwAuthScheme:
      <NONE>
    GetLastError=0; httpStatus=401.
    GetLastError=0; httpStatus=401.
    AutoDiscover disabled auth schemes:
      <NONE>
    AutoDiscover supported auth schemes:
      Basic
    AutoDiscover attempting Exchange Credentials.
    User-1@Tailspintoys.ca
    AutoDiscover USING pcreds->dwAuthScheme:
      Basic
    GetLastError=0; httpStatus=302.
    Autodiscover to https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml Failed (0x800C8204)
      Autodiscover URL redirection to https://pod51042.outlook.com/autodiscover/autodiscover.xml
      Autodiscover to https://pod51042.outlook.com/autodiscover/autodiscover.xml starting
      AutoDiscover doing Pre-Auth with saved data.
      User-1@Tailspintoys.ca
      AutoDiscover PRE-AUTH pcreds->dwAuthScheme:
        Basic
      GetLastError=0; httpStatus=200.
      Autodiscover XML Received

 

For more details on Outlook diagnostic logging please see KB 2862843 -- How to enable global and advanced logging for Outlook 2010 and Outlook 2013.

 

Cheers,

Rhoderick

Rhoderick Milne [MSFT]

One Comment

  1. This article is far beyond good - its fu**** awesome ! Thanx for sharing your knowledge and that deep dive !
    Can you maybe explain why outlook 2016 sometime wants to create a new profile after a mailbox is migrated to Office365, Outlook does not connect to the migrated mailbox in O365 for some users here - some people in the internet say "its because autodiscovery is wrong configured" (thats how i found your blog while searching for a solution).
    Other people say "it is because your existing user profile is corrupt"
    Do you know why this can happen for only some users ?
    (When i migrate a mailbox other users can not see the migrated calendar until they enter their password that their outlook can "connect to Office365" then the migrated calendar gets loaded and shows in their Outlook - there are users that can not enter the password because their Outlook does not ask for it - so they do not see the migrated calendars anymore until they get a new outlook profile for themself - this creates a kind of "domino effect" for creating new profiles through the whole company.
    A hint for these problems would be awesome !
    Thank you very much

Leave a Reply

Your email address will not be published. Required fields are marked *