for Exchange & O365

Autodiscover is a fundamental technology in Exchange and Office 365.  When Outlook first starts the ‘out of the box experience’ is that it will first of all figure out if it can find an email address for you on the account you’re logged in with and then takes you through a wizard driven interface to ultimately run an autodiscover sequence.

The autodiscover steps

Autodiscover tries various methods to attempt to reach a web service that will give it the settings needed to connect to your mailbox.  The steps are as follows (in order)

1. Active Directory Service Connection Point (SCP)

Outlook looks in the Active Directory that you are connected to using LDAP://RootDSE and then getting the configurationNamingContext partition.  It then runs an LDAP query on the configuration partition with the following filter

(&(objectClass=serviceConnectionPoint)(|(keywords=67661d7F-8FC4-4fa7-BFAC-E1D7794C1F68)(keywords=77378F46-2C66-4aa9-A6A6-3E7A48B19596)))

It takes the results of this query and first of all splits them into SCP records that have a keywords entry starting with ‘domain=’ and those that don’t have any ‘domain=’ keywords entries.  If it finds an SCP where the domain= entry has your email domain after the equal sign then it uses the serviceBindingInformation attribute to either look in another LDAP (if the GUID in keywords was 67661d7F-8FC4-4fa7-BFAC-E1D7794C1F68) or post to a web service.

If there is no SCP with a domain= matching your email domain, then it checks to see if there are any SCPs without any domain= entries in keywords.  If there are then it will sort these into three ‘buckets’

1. site= entry in keywords matches your Active Directory site
2. no site= entry in keywords
3. site= entry found in keywords but they do not match your Active Directory site

It will then start with bucket 1 followed by 2 and finally 3 and tries each serviceBindingInformation link in turn looking for a valid response.

Now if you’re not connected to Active Directory then this step is skipped altogether.  This can be switched off with the ExcludeScpLookup registry entry.

2. Email domain via https

Using your email address autodiscover checks your email domain (the bit after the @ sign) and sends a post to https://emaildomain/autodiscover/autodiscover.xml  This generally doesn’t yield a good result, in fact I don’t know why Microsoft chose to put this option 2nd and not 3rd…  Anyway, generally this will either fail because there is no DNS entry for emaildomain or it hits your corporate web site, which is unlikely to have an autodiscover.xml file in the autodiscover directory.  This can be switched off with the ExcludeHttpsRootDomain registry entry.

3. Autodiscover email domain via https

Using your email address autodiscover checks your email domain with a preceding autodiscover, and it sends a post to https://autodiscover.emaildomain/autodiscover/autodiscover.xml.  For an on-premises Exchange environment this often does yield a successful result.  This can be switched off with the ExcludeHttpsAutodiscoverDomain registry entry.

4. Local XML file

A local XML file can be placed in %LOCALAPPDATA%\Microsoft\Outlook and called autodiscover.xml.  This xml file will then be read by Outlook and used to obtain settings for the user.  This can be made the first method using the registry entry PreferLocalXML and adding a registry entry for the user’s email address of email domain and specifying the full path to the local XML file.

5. Email domain via http

Using your email address autodiscover checks your email domain (the bit after the @ sign) and sends a get to http://autodiscover.emaildomain/autodiscover/autodiscover.xml and it is looking for an HTTP redirect, i.e. a 301 or 302 status code telling it what URL to try next.  This can be switched off with the ExcludeHttpRedirect registry entry.

6. DNS SRV record

Finally autodiscover will look up an SRV record in DNS based on your emaildomain.  It will look for _autodiscover._tcp.emaildomain and the host and port settings on that SRV record will tell it which URL and port to try to connect to.  This can be switched off with the ExcludeSrvRecord registry entry.

7. Cached URL in Outlook Profile

In Outlook 2010 Microsoft started to cache the last known good autodiscover URL in the profile so that they could refer back to that if needed in future.  This can be switched off with the ExcludeLastKnownGoodUrl registry entry.

8. Direct Connect for Office 365

This is a new method in Outlook 2016 which assumes that the email domain is on Office 365 and so tries three requests to confirm if this is an Office 365 hosted domain.  This can be switched off with the ExcludeExplicitO365Endpoint registry entry.

https://odc.officeapps.live.com/odc/emailhrd/getfederationprovider?domain=emaildomain

https://odc.officeapps.live.com/odc/emailhrd/getidp?hm=0&emailAddress=emailaddress

https://login.microsoftonline.com/emaildomain/.well-known/openid-configuration

Autodiscover Scenarios

Autodiscover for Exchange On-Premises in the User Forest

In a pure Exchange on-premises environment where Exchange is in the same forest as your user accounts then the ‘SCP method’ is most likely to give you a success (as long as Exchange is configured correctly)  When you are at home then if your company has published Exchange to the Internet then the ‘autodiscover email domain via https’ method is likely to give you the right answer.

Autodiscover for Exchange On-Premises in a resource forest

In an Exchange resource forest scenario either the SCP method is successful (if your Exchange admin has used PowerShell to export the SCP settings from the resource forest and put that into the user account forest.  It would have created a single SCP in the user account forest with a serviceBindingInformation of LDAP://exchange-forest-fqdn.  Causing autodiscover to query the Exchange forest for SCP records and generally succeeding there.  (NOTE that since autodiscover will look for AD Sites it is important to be aware of site names in both the user and Exchange forests)

If your admin has NOT exported the SCPs then the next most likely option to succeed is again the ‘autodiscover email domain via https’ method.

Autodiscover for Office 365

In Office 365 we’re asked by Microsoft to create an autodiscover.emaildomain CNAME in DNS and point it at autodiscover.outlook.com.  This is so that the ‘Email domain via http method’ can get a redirect from autodiscover.outlook.com which will be autodiscover-s.outlook.com and sometimes it will then get another redirect to podXXXX.outlook.com before finally getting the settings it needs.

Autodiscover for Office 365 in Hybrid

In a hybrid configuration autodiscover will first find the on-premises Exchange server as if Office 365 wasn’t there, however if the user making the autodiscover request is looking for a mailbox in Office 365 then the on-premises user object will have a targetAddress entry with @O365domain.mail.onmicrosoft.com (where O365domain is the tenant short name).  The fact that the object has a targetAddress causes autodiscover to switch to use that targetAddress email domain and runs through the above options.  Now that the targetAddress points to Office 365 it uses the Email domain via http method to get redirected and ultimately finds its settings

Controlling Autodiscover

I have done a blog many months ago on how to control the autodiscover process via registry keys

Testing Autodiscover

There are many ways of testing autodiscover.  The three best ways I’ve found are

• testconnectivity.microsoft.com is a great tool to check if autodiscover works from the Internet
• Remote Connectivity Analyzer is a client that can be downloaded from testconnectivity.microsoft.com to run the autodiscover tests from a machine within your network (or over a VPN)
• Outlook itself has a Test Email AutoConfiguration tool, which can be accessed by finding the Outlook icon in your system tray and right-clicking on that icon while holding down the Control key.

Here is an example of my autodiscover test using Outlook on a hybrid account in our lab

Here you can see it go through the following steps

• Locate the SCP, get a 401 http status code meaning authentication required, followed by an http status code 200 meaning success, the failure code 0x800c8205 means that a targetAddress was found

Now autodiscover switches to using that targetAddress domain

• Locate the SCP and gets a 200 http status code and again with a failure code of 0x800c8205, so fails this step since we’re already on a targetAddress redirect
• Try the email domain and fails with 0x80004005, meaning unable to connect
• Try autodiscover plus the email domain and fails with 0x80004005, meaning unable to connect
• Try the local xml file, but fails with 0x8004010F, meaning file not found
• Do the redirect check to the email domain, gets autodiscover-s.outlook.com back (some software shows this as a failure code 0x800c8204) and tries that.  First gets a 401 again in order to authenticate and then a 200 http status code and it succeeds with error code 0x00000000

Analysing Autodiscover

Using tools like Process Monitor from Microsoft/Sysinternals and Fiddler from Telerik we can see deeper into autodiscover.  I’ve tested using the mail applet from control panel but you can use any tool that runs autodiscover and then trace them with Process Explorer and Fiddler.  If you want to see inside the HTTPS stream then in Fiddler you’ll need to enable decryption and accept the prompts about trusting a self signed root certificate.  This makes Fiddler your proxy server and it will pretend it is the website you’re after by creating a valid certificate on the fly and then establish a connection to the real web server on your behalf.  This allows it to see inside of the encrypted HTTPS stream.  Anyway I digress.

Looking at Process Monitor and filtering to only RegQueryKey commands we can see that a number of registry key entries are checked.

The majority of these have been mentioned above already but here is a summary of the ones that are in HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Autodiscover (where the version number is the version of Office you’re using).

There is also a subkey called RedirectServers which can be populated with one value per autodiscover host for which you do NOT want to be alerted about a redirect happening. By default Outlook will prompt the user to ensure they trust the redirection.

Now using Fiddler we can see the autodiscover steps in action, let’s look at three examples in more details

Autodiscover for Office 365

Here we can see autodiscover use the following methods

• Method 1 is not applicable since I’m not in Active Directory
• Method 2 (Email Domain) is sessions 7 to 9
• Method 3 (Autodiscover Domain) is sessions 10 to 12
• Method 4 is not shown, I also don’t have a local XML file
• Method 5 (Redirect) is session 13-19 where it gets a 302 redirect, then tries autodiscover-s.outlook.com and finally gets an HTTP 200 status
• Session 20 is the connection establishing to Office 365 itself

Autodiscover for Office 365 in Hybrid

Here we can see autodiscover use the following methods

• Method 1 (SCP record) is sessions 3 to 7 where it gets an HTTP 200 status, and since this account is on Office 365 it is returned the targetAddress
• Method 1 (SCP record) for the targetAddress is sessions 8 to 10 where it gets an HTTP 200 status, but we know it will again get a targetAddress and so fails this step
• Method 2 (Root Domain) for the targetAddress is session 11 where it gets a 502 error when trying to set up the tunnel, i.e. unable to connect
• Method 3 (Autodiscover Domain) for the targetAddress is session 12 where it gets a 502 error when trying to set up the tunnel, i.e. unable to connect
• Method 4 is not shown, I also don’t have a local XML file
• Method 5 (HTTP redirect) for the targetAddress is sessions 13 to 16 where it gets an HTTP 302 status, and then connects to autodiscover-s.outlook.com, gets a 401 status first for authentication followed by 200
• Sessions 17 onwards are then connecting to Office 365 itself

Autodiscover for an invalid email address

Here we can see autodiscover use the following methods

• Method 1 is not shown since we’re not in Active Directory
• Method 2 (Root Domain) is sessions 64 to 65 and get an HTTP 502 status, i.e. unable to connect
• Method 3 (Autodiscover Domain) is sessions 66 to 67 and get an HTTP 502 status, i.e. unable to connect
• Method 4 is not shown as there is no local XML file
• Method 5 (HTTP Redirect) is sessions 68 to 69 and get an HTTP 502 status, i.e. unable to connect
• Method 8 (Direct Access) is sessions 70 onwards, and the final HTTP 400 status tells us it was not successful

In summary, autodiscover is a complex piece of software and what is worse is that not every client uses the same set of methods, for example Lync/Skype for Business don’t use SCP or the local XML options.  So this is still a bit of a black art but hopefully the above gives you some insight into how autodiscover works