The Exchange Autodiscover service automates the configuration process for Outlook clients and certain mobile operating systems that connect to Exchange 2007 and Exchange 2010. While the Autodiscover service isn’t something you normally have to worry about, problems do creep in. When they do, it’s important you know how to troubleshoot them.
The Autodiscover service runs on your client access server (CAS), from which Outlook automatically acquires Exchange configuration information. To retrieve that info, Outlook opens the following XML file:
If you need to troubleshoot the Autodiscover service, the first thing you should do is to open the aforementioned URL in a Web browser from a computer on your corporate network. When you do, remember that Microsoft Outlook automatically passes account credentials to the CAS; Internet Explorer does not.
Therefore, you will most likely be prompted for your credentials; this is normal and does not indicate a problem. The Autodiscover.xml file should resemble the one shown in Figure 1.
Figure 1. First, see if you can access Exchange’s Autodiscover.xml file.
If the .xml file opens, your CAS is working properly and you should move forward with the troubleshooting advice outlined below. If the .xml file does not open, try substituting the CAS’s IP address in place of the domain name. If the file opens, you probably have a Domain Name System (DNS) issue. I will also discuss the proper DNS configuration later in this tip.
Using the Remote Connectivity Analyzer
After confirming that your CAS is hosting the Autodiscover.xml file, the next step is to utilize the Remote Connectivity Analyzer. The Remote Connectivity Analyzer is a Web app that verifies connectivity to your Exchange Server organization.
After launching the Remote Connectivity Analyzer, select the Exchange Server tab, then the Outlook Autodiscover option (Figure 2).
Figure 2. The Remote Connectivity Analyzer will help diagnose Autodiscover problems.
Click Next and you’ll be prompted to enter an email address and set of account credentials. I highly recommend selecting the Ignore Trust for SSL option. If you don’t, the test can fail because Microsoft does not recognize the certificate authority (CA) that issued your CAS’s SSL certificate.
In my example, my tests failed because I do not expose my Autodiscover service (Figure 3). That said, you can still see that the tests were based on attempts to download the Autodiscover.xml file.
Figure 3. The Remote Connectivity Analyzer made several attempts to contact the Autodiscover service.
Repairing Exchange Autodiscover: Checking firewalls, certificates and DNS
If you can’t access the Autodiscover service, the next step is to check firewall settings. HTTPS provides Autodiscover access, so make certain that port number 443 is open on your CAS’s firewall, as well as all other firewalls between the Outlook client and your CAS.
You should also check to make sure the CAS’s SSL certificate is valid and the certificate authority that issued the certificate is trusted by the end users’ computers. The CAS uses a self-signed certificate by default. While this certificate is adequate for Autodiscover to work properly on your corporate network, you should use a Subject Alternate Name (SAN) certificate from a trusted commercial certificate authority If you plan on providing Autodiscover services to external clients.
As you saw in Figure 3, there are two URLs that Outlook checks when it attempts to download the Autodiscover configuration file:
Either URL should work fine, but Microsoft recommends creating a Host (A) record to your DNS for autodiscover.<your domain>. For example, if you want to create an Autodiscover record for the Contoso.com domain, you can create a Host record that associates the CAS’s IP address with autodiscover.contoso.com. If you create the record on an external DNS server, it can take up to 48 hours for the DNS record to propagate.
Earlier I noted that your CAS should use a SAN certificate. A SAN certificate allows you to associate multiple subject alternate names with a single certificate. The autodiscover.<your domain> name should be included in the certificate so that connections to autodiscover.<your domain> can be SSL-encrypted.
After you’ve properly configured both the DNS record and SSL certificate, try opening https://autodiscover.<your domain>/autodiscover/autodiscover.xml in a Web browser. If the certificate, firewall and DNS record are configured properly, you should have no trouble accessing the XML file.
ABOUT THE AUTHOR:
Brien Posey is an eight-time Microsoft MVP with two decades of IT experience. Before becoming a freelance technical writer, Brien worked as a CIO at a national chain of hospitals and health care facilities. He has also served as a network administrator for some of the nation’s largest insurance companies and for the Department of Defense at Fort Knox.