Autodiscover Troubleshooting
On This Page
- Introduction
- Background on Autodiscover
- Common Symptoms with Autodiscover
- Issues With Autodiscover
- Correct Configuration of the Autodiscover Service
- Exchange Server Configuration
- DNS Configuration
- Resetting the Autodiscover Virtual Directory
- SSL Prompts when using Exchange 2003
Introduction
Autodiscover is one of the major pain points for Exchange administrators, but is actually quite easy to troubleshoot and resolve as the main issues with it are well known.
Background on Autodiscover
First, some background.
Autodiscover, and its companion, the availability service, are key to the operation of Exchange. Primarily designed for hosted Exchange operations, it is used by all Exchange server implementations of Exchange 2007 and higher and is not an optional function.
Not only does it do the first time configuration of the Exchange client, but they also tell the client whether anything has changed, as well as provide the means to get free/busy information. Outlook 2007 and higher uses Autodiscover.
The Autodiscover lookup takes place frequently in the background by Outlook 2007 and higher, no matter which version of Exchange you are using, so it is possible to get issues with Autodiscover with an Exchange 2003 server involved. As the process is constantly being used, it is not something that administrators can simply ignore and configure the clients manually.
Autodiscover works in one of two ways.
- A lookup from the domain.
- DNS records.
The first method is for clients that are members of the domain and can reach the domain controller. That means they are on the LAN, or connected via a VPN. Exchange publishes a URL in to the domain, which the clients query and this tells them where to go to get further information from Exchange for the Autodiscover information.
The second method involves the Outlook client making DNS lookups against a number of preset host names. These host names are derided from the user's email address. If the user's email address is john.smith @ example.com then the autodiscover process will query example.com, autodiscover.example.com and then an HTTP request.
This occurs for clients that are both members of the domain, if they cannot reach the domain controller, and for non-members.
Outlook can also query SRV records, which is useful when an Exchange server is hosting multiple
In both cases, the autodiscover process will use SSL, so the actual host name queried will be https://host.example.com/ .
Common Symptoms with Autodiscover
The most common problems that are connected to Autodiscover include:
- Frequent prompts for SSL certificates on clients (including those on Exchange 2003).
- Frequent user name and password prompts.
- No free/busy information
- Unable to set Out of the Office (OOTO).
Issues with Autodiscover
The problems with autodiscover usually fall in to one of three main areas:
- SSL Certificate issues.
This is the most common, and is usually caused by having the incorrect names on the SSL certificate, or attempting to use the self signed SSL certificate. - DNS Issues.
This is usually a matter of not having autodiscover.example.com on the external DNS. - On the domain only, incorrect or invalid URLs being published.
Correct Configuration of the Autodiscover Service
If you get autodiscover to work correctly, then you will usually find that the availability service will also work.
Exchange Server Configuration
Starting with the Exchange server itself, the configuration is carried out on the server with the Client Access Role.
The get-autodiscovervirtualdirectory command, and setting internal and external URLs on the autodiscover virtual directory have no affect on the operation of Autodiscover and should be left alone in their default state.
There is only one value that you need to worry about, and that is the value of AutodiscoverServiceInternalURI which is on get-clientaccessserver
Run the following command:
You will get a response back similar to this:
Name
AutoDiscoverServiceInternalUri
----
------------------------------
exch-server https://exch-server.example.com/Autodiscover/Autodiscover.xml
The value returned is published to the domain by Exchange at regular intervals, therefore it should:
- Resolve to the Exchange server.
- Be one of the names in the SSL certificate.
If both of those are not correct, the Autodiscover is likely to fail.
If the URL is incorrect, then correct it using this command:
Where exch-server is the name of the Exchange Server, exch-server.example.com is its FQDN.
Browse to the URL mentioned in the URL - if you get an SSL prompt, then you will need to correct the SSL certificate.
Multiple Exchange Servers
If you have multiple Exchange Servers in the same AD site, then you can get the issue of the server's overwriting each other at frequent intervals. This isn't a problem if the SSL certificates are setup correctly, with every server holding the Client Access Server role being listed. However if that isn't the case, then you should set all of the servers in the same AD site with the same host name.
Multiple AD Sites
Autodiscover is AD site aware, which means that you have can have multiple internal Autodiscover URLs, one for each AD site. This stops the domain joined clients from querying a remote Exchange server. This is known as Site Affinity. It is configured thus:
Where Office 1 is the name of the AD site being configured (all other values as above).
Changes from 2015
In 2015 the rules around SSL certificates will change. You will not be able to get SSL certificates issued to host names that are not valid on the internet. This means that domains using .local or other non-registered domains will have to use a split DNS system so that an external host name can be used.
DNS Configuration
Other than ensuring the host name used internally resolves, you also have to ensure that public DNS is configured correctly, particularly if you are going to use Outlook Anywhere.
If you do not have any clients on the LAN which are NOT members of the domain, then you do not need to do anything internally for DNS.
However if you have clients on the network which are not members of the domain, using Exchange, this could be Windows, MACs or mobile devices, then you should ensure that autodiscover.example.com resolves internally to the Exchange server via a split DNS system.
For external DNS, the most configuration is to have autodiscover.example.com resolve to the external IP address of the Exchange server, along with your preferred URL for OWA, ActiveSync and Outlook Anywhere and then have the correct names in the SSL certificate.
However if you are hosting multiple domains, then having many Autodiscover entries can get expensive and difficult to maintain. Therefore an alternative existing using SRV records. Your external DNS provider must support SRV records for this to work. The configuration of SRV records for Autodiscover is covered in MSKB 940881 and applies to all version of Outlook from 2007.
You can also use the HTTP redirect method for public Autodiscover, but this requires additional IP addresses and web sites and is therefore not commonly implemented.
For general DNS configuration for Exchange servers, see the DNS Configuration page.
Resetting the Autodiscover Virtual Directory
In some cases, it can be just as quick to reset the virtual directory. If you have been changing authentication settings and other settings to try and correct issues, then it can mean you are simply going round in circles.
In Exchange 2010, there is a wizard to reset the virtual directory which should be used.
For Exchange 2007, you have to use Exchange Management Shell:
Where server is the netbios name of the server which holds the Client Access Role and is the one you want to reset the virtual directory.
Then you need to recreate it using the following command on the server where you want to reset the virtual directory.
After recreating, run IISRESET for the changes to write to the IIS metabase correctly.
SSL Prompts when using Exchange 2003
If you are still on Exchange 2003, but Outlook 2007 and higher is generating SSL prompts, then this is probably caused by a DNS issue - specifically an SSL certificate on the root of the domain or a wildcard in the DNS (or both).
A wildcard in the DNS is very common setting applied by web hosts, so that anything.example.com resolves to the public web site.
It is also best practise for the root of the domain (example.com) to resolve to the public web site, as many people no longer enter www when entering a URL.
If the server holding the web site is shared, and has an SSL certificate installed on to another web site which is using the same IP address, then you will get prompts, often from another domain to your own. This is most often the case where your internal WINDOWS domain is different to your EMAIL domain (so example.local and example.com).
Resolution - remove the wildcard from the public DNS so that autodiscover.example.com doesn't resolve.