How Autodiscover works in Outlook 2011

Fellow Exchange MVP Rajith Enchiparambil, proprietor of the excellent How Exchange Works blog, asked an interesting question the other day: how does Autodiscover work in Outlook 2011? Is it different from the way Autodiscover works in Outlook for Windows?It turns out that the answer is (as you might have predicted) “it depends.” To answer that question in depth, we have to dig into the guts of Autodiscover (or AutoD, as its friends call it).

The first thing to know is that there are two parts to AutoD. One is the service that runs on Exchange 2007 and later. This service is implemented as a virtual directory named “Autodiscover” on the CAS role. When you install the CAS role, the vdir is automatically created and provisioned for you. In addition to the vdir, an Active Directory service connection point (SCP) object is created. (For probably more detail on SCPs than you’d want, see this article.)

See, in Windows Outlook, there are two primary ways that AutoD can work: domain-joined Windows machine can perform an LDAP lookup to find an AD SCP, or any machine can try to hit a predefined series of URLs. Why are there two methods? Because this design allows a computer, or device, to find the correct Exchange CAS whether it’s domain-joined or not, and whether or not it’s on the internal corporate network.

(See what I did there? I said device, because mobile devices can use AutoD also. Currently, iOS and Windows Phone 7.x devices use AutoD, as do some Exchange ActiveSync clients on some Android devices. For our purposes, we’ll treat mobile devices just like Macs insomuch as they use similar web-based queries for the AutoD vdir.)

So let’s ignore the SCP lookup process. How does Mac Outlook 2011 use AutoDiscover?

First it tries to connect to the standard AutoD URL, which is made up of the primary Exchange SMTP domain plus /Autodiscover/Autodiscover.xml. For example, https://robichaux.net/Autodiscover/Autodiscover.xml would be the first URL Outlook would try for an account in the robichaux.net domain. If that works, great. If not, it will then try tacking “autodiscover” onto the FQDN and keeping the same relative path.

If neither of those standard URL requests, both of which are made using HTTPS, bear fruit, the next attempt will be to do an HTTP request for the second URL. This request will be redirected if HTTP-to-HTTPS redirection is in use, which is what we want– if a redirection occurs, Outlook will catch the HTTP 302 response and make an AutoD request against the redirected URL.

If that check fails, the next step is to perform a DNS SRV lookup to try to find the FQDN of an Exchange CAS. If the SRV query returns a target machine, Outlook will tack on /autodiscover/autodiscover/xml to it and perform an AutoD query against the result.

Once Outlook or a mobile device gets back an Autodiscover manifest, of course, what it does with the result will vary according to its capabilities. For example, Outlook 2011 and mobile Exchange ActiveSync clients don’t (currently) use the returned URL for the target mailbox’s Exchange unified messaging (UM) server.

This process is generally pretty robust unless you’ve misconfigured the Autodiscover or service URLs on the CAS. It turns out that there’s a separate Exchange Web Services (EWS) external URL property on the CAS, and if you fail to set that properly– say, if some of your users snuck some Macs or iPads or something onto your network– then AutoD will return the EWS URL that you set, which will be wrong, so Mac Outlook won’t connect properly. The Test-* cmdlets are very useful in tracking this kind of problem down; Exchange MVP Tim Harrington has written a good primer on their use.