Pages

Wednesday, 28 March 2012

AutoDiscover Configuration for Exchange 2007 and 2010

AutoDiscover Configuration for Exchange 2007 and 2010

Overview

The 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.

AutoDiscover simplifies email client configuration for remote and mobile
users; you may not have noticed it but most email clients nowadays will simply
ask for your email address and password first, e.g. the Android email setup
screen:

What actually happens after you have entered your details is that the client
looks for autodiscover.yourdomain.com and attempts to
retrieve the rest of the server configuration details from there. If you've set
that up properly then no more information is required, making the setup process
very simple for non IT-literate users and saving you from having to deal with
support calls.

The second main function of AutoDiscover in Exchange is
linked to the Offline Address Book and "Out of Office"
settings, as Outlook uses part of Outlook Web Access for them, rather than the
MAPI based connections used for mailbox access. The Outlook client actually uses
the AutoDiscover address to retrieve the Exchange Server details for these, so
if it is incorrectly configured you may find these features don't work, even
though everything else does.

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 Configuration

There 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 Problems

There 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.

For your internal network clients fixing the DNS resolution should be even
easier, as you will have your own internal DNS server, so you just need to open
up the management console for that and add in the appropriate A record to
resolve to the internal address of your Exchange Server. Once
you have changed it you can try the Outlook Email AutoConfiguration test again,
however make sure the DNS cache on your local machine is updated first, either
by simply rebooting it or running ipconfig /flushdns from a
command prompt.
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 Certificate

Often 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

Completing Your AutoDiscover Configuration

Once you have worked your way through the above steps you should be able to
successfully test your AutoDiscover configuration both externally and
internally. If you had experienced problems with your Offline Address Book in
Outlook before, or users could only set their Out of Office by using OWA then
you should find that these problems have been solved as well. The best part
though is how easy it becomes to set up new mail clients and smartphones, in
fact most users should be able to do it themselves now without having to seek
your assistance!