Autodiscover automatically configures profile settings for Exchange clients. These clients include Microsoft Outlook 2007 or Outlook 2010, Outlook for Mac, Mail.app in Mac OS X, iPhone, iPad and ActiveSync enabled phones. Autodiscover is often made out to be complicated. There’s an Autodiscover service that gets installed when a Client Access Server (CAS) role is setup for Exchange 2010 in the form of a default virtual directory named Autodiscover for the default Web site in Internet Information Services (IIS). You then forward an autodiscover service locater record in DNS in the form of _autodiscover._tcp.
The virtual directory handles Autodiscover requests. But what about other vendors, and even for Exchange, how do you verify that it’s working correctly? If clients automatically configure then it’s working, obviously. But when it isn’t, what do you need to do? The most obvious step is to check that the DNS record responds appropriately. To do so, we can use nslookup. To use nslookup, run it from the command line, followed by the DNS name. For me.com, this might be:
But note that there’s not a response. This is because me.com doesn’t use _autodiscover (why would it, it’s not EWS/ActiveSync after all. But other domains that are configured for autodiscover would respond. For example, look at the output for 318.com:
Which looks like this:
Provided that the answer section is the address of the CAS Exchange server that sits in front of your organization (the one that runs the Autodiscover virtual directory in IIS) then you are more than likely off to a great start using autodiscover. If not, then that’s the first thing that likely needs to get fixed if you actually want clients to use autodiscvoer. Also keep in mind that you’ll want to check internally and externally, as you will likely have different domain names setup for these. I often find that people will configure the _autodiscover records in their public DNS but not in their private views. Also keep this in mind when acquiring SSL certificates for Exchange’s CAS instance.
Note: Autodiscover, as its implemented in Office Exchange clients, also has the ability to change configurations in Office on the fly as network settings change on internal networks (e.g. users get moved to different information stores, IPs of servers change, etc). This does not seem to work with Apple’s Mail. One could write a script to check for a change in the records nightly (or more frequently of course) if this is needed.
Sometimes the mail clients can interpret things differently than we do manually from the command line, including autodiscover. When the Apple Mail client is attempting to connect to Exchange, you can also get more information about the EWS autodiscovery process by capturing logs about it, not done by default, but invoked by firing up mail using the –LogEWSAutodiscoveryActivity option followed by a YES, as follows:
By reading these logs, you can learn way more than you ever wanted to know (or thought was possible) about Autodiscover. Given that Autodiscover is similar in iOS, most of this rings true in the Mail app there as well. However, given that you can’t view the activity in as granular a detail by invoking Mail through the command line, you can watch it in the logs in iPhone Configuration Utility while you’re setting up Mail, Contacts & Calendars in the Settings app, which should provide information about any connection failures.
While Autodiscover is awesome, you should still be able to connect without it. The only time I really both to troubleshoot Autodiscover itself is when I can install an account but I cannot get Autodiscover to eliminate the need for the second setup screen in Mail on iOS and OS X (possibly with the exception of Lion). If you can setup mail, but it requires two screens then the problem is basically always Autodiscover. If you can’t setup mail at all then the problem is basically never Autodiscover. Good luck, and hope someone finds this useful!
krypted January 6th, 2012