Autodiscover exposed
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’
- site= entry in keywords matches your Active Directory site
- no site= entry in keywords
- 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).
Key | Description |
---|---|
ZeroConfigExchange | Prevent the Wizard UI from displaying, but runs as if you click next to each screen |
DisableAutoStartup | Prevent the Wizard from running altogether |
ExampleName | Set the Name field in the Wizard |
ExampleAddress | Set the Email Address field in the Wizard |
AllowAutoDiscoverToAutoLogonToInternetDuringAccountCreation | Allow Outlook to send the logged on user’s NTLM credentials over the Internet to set up an in-place Exchange account for the logged on user |
Timeout | Number of seconds to wait for each step to timeout |
PreferLocalXML | Use the local XML file if it exists in preference to any other method |
ExcludeSCPLookup | Prevent method 1 from running |
ExcludeHttpsRootDomain | Prevent method 2 from running |
ExcludeHttpsAutodiscoverDomain | Prevent method 3 from running |
ExcludeHttpRedirect | Prevent method 5 from running |
ExcludeSrvRecord | Prevent method 6 from running |
ExcludeLastKnownGoodUrl | Prevent method 7 from running |
ExcludeExplicitO365Endpoint | Prevent method 8 from running |
AttemptPreAuth | Use Pre Authentication for each web request (i.e. assume that the server requires authentication instead of waiting for the 401 HTTP response) |
ShowCertErrors | Show an certificate errors like non-trusted, invalid time period, etc. |
MaxRetriesOnTimeout | Maximum number of times to retry when a timeout is encountered |
<email address> | Path to the local XML file for this user |
<email domain> | Path to the local XML file for this domain |
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