AutoDiscover Configuration for Exchange 2007 and 2010
OverviewThe AutoDiscover feature in Exchange 2007/2010 is often overlooked during setup but is an important factor in ensuring smooth day to day running of your Exchange environment. Its main function is to provide the mail client with all the configuration options it needs, from only the user's email address and password. This is particularly useful for remote users and smartphone users, who no longer have to enter advanced settings like server names and domains. It is also vital for the correct functioning of features such as Out Of Office and the Offline Address Book in Outlook.
Why is AutoDiscover Important?The Exchange setup process doesn't mention AutoDiscover, and the official Microsoft documentation doesn't really stress the importance of it either, so it can easily pass you by. As part of the general OWA setup the Exchange installer creates an AutoDiscover folder and adds the internal URL to the Exchange configuration, so if your network consists of a single site with local desktops then it should work fine for you.
However, if you want easy email setup for mobile and remote users, or if your users are unable to set Out of Office via Outlook but it works in OWA, then you may well need to check your AutoDiscover configuration.
How to Check Your AutoDiscover ConfigurationThere are two tests you need to run to check that you have your AutoDiscover configuration correct, one from outside your network and one from inside. The outside test is probably the easiest so let's do that first. Open www.testexchangeconnectivity.com in your browser. By the way, if you haven't encountered this website before then add it to your Bookmarks; it's an exceptionally useful tool for various Exchange diagnostics. It's provided by Microsoft so it should be safe to trust with confidential information, but make sure you check the site's SSL certificate first to make sure you are at the correct one!
You will notice that there are two AutoDiscover tests listed, one for ActiveSync and one for Outlook, but in fact for this test we are only really interested in the AutoDiscover part which is the same for both. All the same, you may as well select the one which is more relevant for you now and click Next, then on the next page fill out the information requested. You don't have to enter a valid user account and credentials but if you do then it can test the process all the way through, so I would recommend it. You will also see there is a check box for Ignore Trust for SSL; for the moment it's easiest to tick this, we'll cover certificates later. Once you have done that and worked out the validation code you can click Perform Test and wait for the results page.
Chances are you will see a results page like the one above, which doesn't tell you much, so click on Expand All for more details. You will see that it has run a whole bunch of DNS lookups and tests, no doubt most of them have failed but don't worry about it too much for now as we will go through how to configure it shortly.
To test your AutoDiscover from inside your network the easiest way is to use a copy of Outlook 2007 or 2010 that is already setup and connected to your Exchange Server. Look down in the SysTray by the clock and locate the Outlook icon there, then hold down the Ctrl key and right-click it for the extended menu -- you will see that Test Outlook AutoConfiguration is an option so click that.
In the window that opens, your email address should already be entered so just add your password and make sure that only the Use AutoDiscover box is ticked, then click Test. The Results box should fill up with a bunch of text, look closer and you will see that it is split into two sections: Exchange RPC and Exchange HTTP, each with URLs for things like OOF (Out Of Office) and OAB (Offline Address Book). It should go without saying that these URLs should be resolvable from your internal network clients, or else you will have a problem!
Dealing with Common AutoDiscover ProblemsThere are usually just two common causes for AutoDiscover to not work, and the tests above will show clearly if you are suffering from one of them. The first problem is DNS resolution; either you do not have a DNS A record setup for autodiscover.yourdomain.com or it is resolving to the wrong address. Note that there are two different DNS resolutions involved here: the public DNS for external clients and the internal DNS for your network clients. If the Microsoft Remote Connectivity Analyzer website is showing a DNS resolution failure then it is referring to your public domain DNS record, which you probably have hosted at the same provider as you purchased your domain from, or another third party DNS service. The easiest way to check the public DNS record is using a website
If you have completely forgotten where your domain DNS is hosted then you can also use this site to find out -- just put in your domain name by itself and select "NS (Nameservers)" as your query:
The nameserver query will tell you the domain name of the DNS hosting service, and from that you should be able to get access to your DNS management with a little effort. Different DNS services have variations in their management interfaces but the basic principles are the same; you will need to create or edit the A record for autodiscover.yourdomain.com so that it points to the public IP address of your Exchange Server. You may need to wait a few hours for the change to propagate but then when you run the MS Connectivity test again it should report a successful resolution of the AutoDiscover address.
The remaining two problems you may encounter will only affect external clients, but usually those are the ones you want to make things easiest for, as you won't be there to assist them most of the time. You need to make sure that your Exchange Server is accessible for https on port 443 by configuring your firewall appropriately, although if you already have Outlook Web Access working for external users then you will have done this step already.
The next error you may encounter from the MS RCA website is common enough that it deserves its own section.
Solving Problems with Your SSL CertificateOften the main problem with your SSL certificate is that the name does not match. This usually occurs if you are using a self-generated certificate, or have purchased a basic single name certificate for OWA access, which might have a name like webmail.yourdomain.com. Now you can decide to just ignore this, if you only have a few users to worry about then you may well feel that the additional expense of a new certificate is not worth it. However an increasing number of mobile devices and mail clients will refuse to accept an unverified certificate nowadays, which is a sensible security measure, however it means you have to install your CA (Certification Authority) server certificate manually which can be a pain and defeats the purpose of AutoDiscover in the first place. The solution Microsoft recommends is to purchase a SAN (Subject Alternative Name) certificate, which allows you to register several DNS names on one certificate. Nowadays there are some certificate vendors who offer very cheap or even free certificates, but personally I prefer to stick with the well known trusted CAs like Digicert, who also have useful installation guides and utilities on their website.
For internal network clients, provided they are domain members, the SSL certificate should not be an issue as they will automatically trust your internal CA if you have self-signed. The only occasion it may be an issue is if you have installed a certificate for your public domain name (e.g. yourdomain.com) but you have a different internal domain name (e.g. yourdomain.local). In this situation the easiest solution is to change the internal AutoDiscover URLs to match your public domain name, and ensure you have the correct A records in your internal DNS -- resolving to the internal IP of your Exchange Server. In Exchange 2007 this requires a few PowerShell commands, rather than repeat them all here, the process has been well described in this MSExchange