How Exchange's Autodiscover Works With Mail.app

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:

nslookup _autodiscover._tcp.me.com

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:

nslookup _autodiscover._tcp.318.com

Which looks like this:

Non-authoritative answer:
Name: _autodiscover._tcp.318.com
Address: 66.209.67.173

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:

/Applications/Mail.app/Contents/MacOS/Mail 
--LogEWSAutodiscoveryActivity YES

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!

8 Comments

  • Rich Trouton
    January 6, 2012 - 10:47 am | Permalink

    We had a mail server migration this summer (moving from our location’s Exchange 2010 to a consolidated Exchange 2010 setup with another location), with a mix of Outlook 2011 and Apple Mail clients on 10.6.x and 10.7.x (all were set up with the Exchange 2007 account type.)

    I found that the 10.6.x Mail clients needed to have the server addresses manually updated, but that the 10.7.x Mail clients picked up the new server address from autodiscover like our Outlook 2011 clients did.

  • Pepijn Bruienne
    January 6, 2012 - 1:00 pm | Permalink

    Their Lync service also heavily relies on SRV record autodiscovery and if you don’t set it up *exactly* as they tell you to in the setup docs including the correct order of SRV responses on both internal and external DNS, all sorts of wonky stuff will happen. Autodiscovery is great but it greatly increases the potential for goof-ups if the responsible service admins are not 100% on the ball. But then, they always are, right?

  • Joe
    May 28, 2012 - 4:32 am | Permalink

    HELP.

    I am using Apple’s latest MacOSX 10.7.4 in conjunction with Exchange 2003. All goes well, except that somehow and once every couple of days, the domain name gets overwritten mysterically with a mistyped name, where three letters are exchanged.

    We have changed all equipment internally, and are pretty sure that the typo is not on our equipment, or one the hoster’s. It must reside somewhere else.

    Has anyone heard about something like this?

    • June 28, 2012 - 8:58 pm | Permalink

      Haven’t seen anything like that. Seems like something in some Exchange file might be redirecting or something. Sounds like a fun one to find…

    • August 17, 2012 - 1:51 pm | Permalink

      I’ve got a similar issue except that it happens every day in 10.8. Something is buried in our autodiscover.XX.edu settings and OS X keeps pulling and over righting my domains. I’m wondering if there is anyway to turn the auto discover option in OS X off? This would solve my problems.

      • September 21, 2012 - 6:57 pm | Permalink

        I’ve found no way to disable autodiscover. You can hack the hosts file, but then you’re just defining the record, not disabling the feature. Good luck!

  • Pete
    July 24, 2012 - 3:33 am | Permalink

    Excellent post.
    Quick question though. Is there a way to disable autodiscover for Mail? I have an applescript that works with Outlook, but can’t figure out how to disable it for Mail. The reason I want to disable it, is because the Exchange in my place, pushes down a certificate that changes the Internal server. While this is fine on the corporate network, it is not when off the corporate network.

    Thanks,
    Pete

    • September 21, 2012 - 6:11 pm | Permalink

      You can’t disable autodiscover. You can trick your hosts file into having an autodiscover record in there, but you can’t disable it outright. Sorry.

  • Comments are closed.