Let's share an unpleasant truth that a lot of Exchange 2007 administrators have not yet learned: the Autodiscover service is not an optional component
of an Exchange organization. It may seem as if it's optional,
especially if you haven't yet deployed a version of Outlook, Windows
Mobile, or Entourage that takes advantage of it. More than that, you
can't get rid of it—Autodiscover is on from the moment that you install
the first Client Access role in the organization. You can't shut it off,
you can't disable it, and you can't keep clients and Exchange servers
from trying to contact it (although you can cause problems by not
properly configuring Autodiscover, breaking features, and forcing
fallback to older, more error-prone methods of configuration).
We know several Exchange
2007 organizations that limped along seemingly just fine with
Autodiscover improperly configured or just plain ignored. However, when
Autodiscover has been neglected this inevitably signals an Exchange
organization with other problems—and this is even truer in Exchange 2010
than in Exchange 2007. Autodiscover is more than just a way to ease
administration of Outlook client profiles. Other Exchange components,
servers, and services also use Autodiscover to find the servers and
settings they need to communicate with. In order for the Outlook 2007 or
Outlook 2010 client to leverage many of the advanced features of
Exchange 2010, including the new high availability features, the client
depends on a functional Autodiscover service. And if you want to use the
external calendar sharing or Office Communications Server integration,
you'd better get Autodiscover squared away.
The good news, though, is that
in order to properly plan and deploy Autodiscover, you have to work
through some of the most potentially confusing aspects of an Exchange
2010 deployment. Once you've got these issues solved, you will have
headed off some confusing and annoying errors that might otherwise cause
problems down the road. These issues include namespace planning and
certificate management. Trust us that getting these issues sorted will
make your client access deployment and your overall management tasks a
1. What Autodiscover Provides
We made the point
that Autodiscover is a necessary part of your Exchange deployment. It is
necessary for far more reasons than that it makes configuring your
Outlook 2007 and 2010 clients easier. In Exchange 2007, the clients did
benefit a great deal, which is part of the reason why many people did
not see the point of learning about the service. In Exchange 2010, the
non-client benefits get better, but the client benefits do, too. Some of
the information provided by Autodiscover includes the following:
Client Access server names that Outlook should use to access a user's mailbox
Configuration URLs for the offline address book (OAB)
Configuration URLs for free and busy information
Outlook profile configuration information
1.1. Client Benefits
Exactly what benefits you get from Autodiscover depend on which client you're using:
2007 (SP2 recommended) and Outlook 2010 fully supports Autodiscover.
Outlook 2010 will support Autodiscover when it's released. Outlook
versions prior to 2007 do not use Autodiscover, but they don't support
many of the other cool features of Exchange 2010—so why are you still
Mobile 6.1 and later support Autodiscover for the most part; they don't
support the use of DNS SRV records, instead reverting to the baseline
Outlook 2007 behavior. Earlier versions of Windows Mobile, sadly, don't
support Autodiscover, but they also support down-level versions of the
Exchange ActiveSync protocol, which means you've already lost some cool
2008 for the Macintosh, which still relies on the WebDAV protocol for
mailbox access, supports some limited Autodiscover benefits, but the
forthcoming update to Entourage 2008 that fully supports Exchange Web
Services will also take full advantage of Autodiscover. If you're a Mac
user, this new version of Entourage is the only way to integrate with
Although these are the main
Autodiscover-aware clients, they're not the only ones. For example, the
Microsoft Office Communicator client and devices use Autodiscover and
Exchange Web Services. The behavior of Autodiscover has been clearly
documented by Microsoft, so other third-party clients and devices may
also make use of it. Features that Outlook and Windows Mobile will
leverage include the following:
- Support for DNS A Records
By default, external
clients attempt to find the Autodiscover service through DNS lookups
against well-known hostname (A) records. While CNAME records can be
used, they cause a nonconfigurable security warning to be displayed that
some organizations find provides a less than desirable user experience.
The CNAME warnings can be disabled via the Registry, though. See this
Microsoft Knowledgebase article for more information: http://support.microsoft.com/?id=956528.
- Support for DNS SRV Records
Due to popular
demand, the Exchange and Outlook teams provided support for the use of
Service Locator (SRV) records for organizations that couldn't use A
records and didn't want to use CNAMEs. Unfortunately, use of the SRV
record also results in a warning dialog, so it's still not the best
approach (though it can be disabled via the Registry).
- Support for Active Directory Service Connection Point Objects
clients that can contact Active Directory—effectively any Windows
machine running Outlook 2007 or greater—can make use of an Active
Directory feature called service connection points (SCPs). SCPs provide a
number of benefits that aren't available with plain DNS lookups. SCPs
allow internal clients to locate resources via SCP objects within the
- Internal Organization Settings
Services on Exchange
2010 and Exchange 2007 Client Access servers have both internal URLs for
clients within the firewall (such as Outlook and Communicator on
domain-joined Windows machines) and external URLs for pretty much
everything else. Internal settings use the appropriate Exchange server
FQDNs by default, unless you modify them (such as when using load
- External Organization Settings
External settings allow
services to be reached through Internet-available hostnames and FQDNs.
For some reason, many organizations don't like publishing the internal
FQDNs of their Exchange servers. Using external settings may also ensure
that connections are load balanced or sent through firewalls, such as
ISA Server 2006 or Forefront Threat Management Gateway.
Location of the User's Mailbox Server
The location of the
user's mailbox server is in Active Directory, stamped on the user
object. However, with the use of Exchange 2010 high availability
features and the RPC Client Access service on the Client Access server,
Outlook may connect to one of several Client Access servers. With the
RPC Client Access Array feature, the Client Access server that Outlook
is using may change quickly. Autodiscover can get this information,
which allows the client to quickly reconnect to the correct Client
- Location of the Availability Service
Calendar items are
stored in each user's mailbox. However, their free/busy information has
historically been placed in a system public folder, which could suffer
from latency due to replication lag. The Exchange Availability Service
allows current information to be quickly looked up by clients (both in
the organization and in federated organizations) as they need it, rather
than having them dependent on stale data in public folders.
- Location of the Exchange Unified Messaging Service
voicemail messages created by Exchange Unified Messaging are placed in
the mailbox, additional controls and features are available to users
through this Exchange Web Service.
- Location of the Offline Address Book Service
If you have taken
advantage of the ability to publish your OABs to web virtual
directories, your clients can use HTTP to download them in the
background (using the Windows Background Internet Transfer Service, or
BITS) instead of having to connect to a system public folder.
- Outlook Anywhere settings
Having the external URL
information is a good start for clients outside your corporate firewall,
but more settings are necessary for a successful Outlook Anywhere
session to be established, such as the certificate validation name.
1.2. Server Benefits
Autodiscover isn't just
useful for clients connecting to the Exchange server infrastructure;
it's also useful for other servers, both within the organization and
within the same organization and Active Directory forest use
Autodiscover to locate various services on a user's behalf. For example,
when a user performs a logon to Outlook Web Access, the CAS role
handling the OWA session needs several of the pieces of information
provided by Autodiscover. Using Autodiscover reduces the load on Active
Directory domain controllers and global catalog servers and removes
reliance on cached information. This is true whether you're in a mixed
Exchange 2010/2007 organization or are deploying Exchange 2010 fresh.
within the same organization but in a different Active Directory forest
depend on cross-forest service connection points and internal
Autodiscover to cross the forest boundaries and discover the appropriate
servers to use. In this situation, one CAS server in the source forest
will often act as a proxy for the appropriate services in the target
forest, or it may simply redirect the client. In multiple forest
deployments, the use of Autodiscover is pretty much mandatory to ensure
that Exchange servers in separate forests can interoperate properly.
within separate federated organizations require the use of the external
Autodiscover information to reach federated Availability services.
This, plus the relevant authentication information, allows users to
securely share calendar and free/busy information with their
counterparts in federated Exchange 2007 and 2010 organizations. To share
availability information with a federated Exchange 2007, you have to
jump through a number of hoops. With other Exchange 2010 organizations,
the new Windows Live–based Federation Gateway greatly simplifies the
configuration and management of these types of operations.
So, let's take a look at the nitty-gritty of how Autodiscover works.
2. How Autodiscover Works
Don't be fooled by the
seeming complexity you're about to see. Autodiscover is pretty simple to
understand. The biggest complications come from certificates and
namespace planning, which we'll get to in a bit.
2.1. The Service Connection Point Object
The first piece of the
Autodiscover puzzle lies with the Service Connection Point (SCP) object.
As each CAS role instance is installed into your organization, it
creates an SCP object in the Configuration-naming partition of the
Active Directory domain to which it is joined, at the following
CN=<CAS Server NetBIOS Name>, CN=Autodiscover, CN=Protocols, CN=<CAS Server
NetBIOS Name>, CN=Servers, CN= Exchange Administrative Group
(FYDIBOHF23SPDLT), CN=Administrative Groups, CN=<Organization Name>,
Here's what a typical SCP object looks like when dumped from the LDP (LDP.EXE) tool:
Expanding base 'CN=HNLEX05,CN=Autodiscover,CN=Protocols,CN=HNLEX05,CN=Servers ,There are a few key properties of these entries you should take note of:
CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups ,
CN=Ithicos Solutions,CN=Microsoft Exchange,CN=Services,CN=Configuration ,
Getting 1 entries:
CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative
Groups,CN=Ithicos Solutions,CN=Microsoft Exchange,CN=Services,
CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),
CN=Administrative Groups,CN=Ithicos Solutions,CN=Microsoft Exchange,CN=Services,
dSCorePropagationData: 0x0 = ( );
instanceType: 0x4 = ( WRITE );
keywords (2): Site=Redmond; 77378F46-2C66-4aa9-A6A6-3E7A48B19596;
objectClass (4): top; leaf; connectionPoint; serviceConnectionPoint;
systemFlags: 0x40000000 = ( CONFIG_ALLOW_RENAME );
whenChanged: 6/7/2009 2:48:22 PM Pacific Daylight Time;
whenCreated: 6/7/2009 2:48:10 PM Pacific Daylight Time;
The objectClass property includes the serviceConnectionPoint type. This identifies the entry as an SCP, allowing it to be easily searched.
The serviceClassName property identifies this particular SCP as an ms-Exchange-AutoDiscover-Service
entry. The computers searching for Autodiscover records can thus
determine that this is an entry pertaining to Autodiscover and that they
should pay attention to it. The client searches the
configuration-naming context for any objects that have a serviceClassName= ms-Exchange-Autodiscover-Service. Using the combination of objectClass and serviceClassName
allows computers to efficiently find all relevant SCP entries (through
an indexed search from a domain controller) without knowing any computer
names ahead of time.
points to the actual Autodiscover XML file that the client should
access in order to retrieve the current Autodiscover information.
The keywords property holds additional information that the clients use. Specifically, take note of the Site=
value. This value helps you control site affinity, ensuring that
clients and servers aren't using servers in far-off sites to provide
their Exchange services.
The rest of the properties on an SCP object are fairly standard for Active Directory objects, so we won't discuss them further.
Now that you know what a service
connection point is and where they're located, you're mostly set. The
distinguished name of each SCP object uniquely identifies the host
associated without that object. If the client search returns multiple
SCP objects that the client will use, it will select between them
according to alphabetic order.
Note also that a CAS
role instance only publishes its corresponding SCP object to Active
Directory when it is installed. If you change something about the
CAS—such as which site it's located in—it will not update its SCP
object. You have to do that manually. The best way is to use Exchange
Management Shell. Here is a sample command:
"<CAS Server NetBIOS Name>" -AutodiscoverServiceInternalURI
"https://<CAS Server FQDN>/autodiscover/autodiscover.xml"
-AutoDiscoverSiteScope "<Site Name 1>", "<Site Name 2>"
2.2. DNS Options
The SCP is used when the client
or server is joined to an Active Directory domain and can retrieve the
search from the domain controllers. When the discovering computer is
external or not domain joined, another mechanism is used: DNS lookups.
The following list
describes the DNS lookups that are performed for the Autodiscover
service in a given domain. For this example, let's use the user firstname.lastname@example.org. The client (or server) takes the domain portion (somorita.com) of this address and performs the following lookups in order until it finds a match:
If the requested hostname
is returned through either a CNAME record or an SRV record, then be
aware that your clients (Outlook in particular) will display a warning
dialog with the following text:
Allow this website to configure email@example.com server settings?
Your account was redirected to this website for settings.
You should only allow settings from sources you know and trust.
This warning will appear
every time the client performs Autodiscover unless you check the Don't
Ask Me About This Website Again check box. You can also prepopulate the
Registry key to prevent this warming. See the Knowledge Base article at http://support.microsoft.com/?id=956528.
Note that Autodiscover expects
the use of SSL. Don't publish it over insecure HTTP and expect clients
to be happy about it. You have a lot of sensitive information going
through Autodiscover, including user credentials. As a result, SSL
certificate considerations will play a large part in your Autodiscover
2.3. Two Step-by-Step Examples
Enough theory. Let's dive into our example with the ithicos.com
domain and show you a walkthrough of a common scenario: a domain-joined
Outlook 2007 SP2 client performing Autodiscover behind the organization
firewall. To illustrate this scenario, we'll use a tool every Exchange
administrator should know well: the Outlook Test E-mail
AutoConfiguration tool, shown in Figure 1.
As shown in this example, when using this tool be sure to uncheck the
Use Guessmart and Secure Guessmart Authentication options.
Figure 1. Using the Test E-mail AutoConfiguration tool
You can access this tool from
Outlook 2007 and later by holding down the Ctrl key while
right-clicking the Outlook icon in the notification area on the taskbar.
This opens the menu shown in Figure 2. From this menu, select the Test E-mail AutoConfiguration option.
Figure 2. Accessing the Test E-mail AutoConfiguration tool
When a domain-joined machine performs Autodiscover, it steps through the following process:
first performs an LDAP search for all SCP objects in the forest.
Outlook enumerates the returned results based on the client's Active
Directory site by sorting the returned SCP records using the keywords
attribute; if there are no SCP records that contain a matching site
value, all nonmatching SCP records are returned. If there are multiple
matching SCP objects, Outlook simply chooses the oldest SCP record as
the list is not sorted in any particular order. In our case, we return
three SCP objects for our Redmond site: HNLEX05 (an Exchange 2007
server), HNLEX05 (an Exchange 2010 server), and HNLEX06 (an Exchange
2010 server), so Outlook picks the HNLEX05 SCP object.
attempts to connect to the new URL, the XML file is generated based on
the client request, and the client successfully receives the XML file
shown in Listing 1.
Example 1. An Autodiscover XML Response
<?xml version="1.0" encoding="utf-8"?>
Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=HNLEX05
Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration
/cn=Servers/cn=HNLEX05/cn=Microsoft Private MDB</MdbDN>
There are five key sections to note in Listing 1:
The User and Account sections list the user information for the authenticated user.
The EXCH protocol section (identified by the EXCH
tag) is MAPI RPC over TCP, or traditional MAPI connections. These
settings control how Outlook will connect inside the firewall, over a
VPN, or in other situations where direct connectivity via MAPI is
possible. The URLs provided in this section are based on the InternalURL values.
The EXPR protocol section (identified by the EXPR
tag) is Outlook Anywhere—RPC over HTTPS. These settings control how
Outlook connects over slow connections or when a direct MAPI connection
is not possible. The URLs provided in this section are based on the InternalURL values.
The WEB protocol section (identified by the WEB tag) is used for OWA and other types of clients. The URLs provided in this section are for clients and are based on the ExternalURL values.
If the client had been
outside the firewall, it would have followed a similar process, but
instead steps through the hostnames and URLs as described in the
previous section on DNS names. An external client (for the domain somorita.com) using Autodiscover goes through these steps:
The client tries to connect to the Active Directory SCP, but is unable to do so.
The client retrieves autodiscover.xml from the Autodiscover HTTPS host.
The client parses through the WEB sections of the autodisover.xml file in order to determine the correct URL to which it should connect.
The client initiates a connection to the appropriate external URL.
To help step through and
troubleshoot external connectivity, you should be aware of the Exchange
Remote Connectivity Analyzer tool, available online from http://testexchangeconnectivity.com/.
This Microsoft tool provides a secure, reliable suite of tests to help
diagnose problems with not only Autodiscover but all of the web-based
Exchange remote client access protocols.
3. Advanced Autodiscover Concepts
If you're reading this far,
you've gotten through the basics of Autodiscover. There are some
advanced concepts we need to share with you: how site affinity works
(and how to manage it) and how to configure Autodiscover to work with
3.1. Site Affinity
To understand the point of site
affinity, consider an organization that has multiple locations—we'll
say in Seattle, Washington (code SEA); Toledo, Ohio (code TOL); and New
Orleans, Louisiana (code MSY). There are Exchange servers and users in
each of these locations. The links between these locations run over WAN
links from Seattle to Toledo and Toledo to New Orleans; it is neither
optimal nor desired to allow users in Seattle to use Client Access
servers in New Orleans (or vice versa). Using site affinity, we can use
the following commands to help ensure this does not happen:
Set-ClientAccessServer -Identity "sea-cas01"
Set-ClientAccessServer -Identity "sea-cas02"
Set-ClientAccessServer -Identity "tol-cas01"
Set-ClientAccessServer -Identity "tol-cas02"
Set-ClientAccessServer -Identity "msy-cas01"
Set-ClientAccessServer -Identity "msy-cas02"
When clients perform
Autodiscover, they will only match the records for those Client Access
servers that match the site they are currently in.
Clients in Seattle will only match the SEA-CAS01, SEA-CAS02, TOL-CAS01, and TOL-CAS02 SCP objects. Because there are multiple objects, they will perform their initial discovery to TOL-CAS01 (this was the last server configured), which will then return URLs for the servers in the Seattle site.
Likewise, clients in New Orleans will only match the MSY-CAS01, MSY-CAS02, TOL-CAS01, and TOL-CAS02 SCP objects. Because there are multiple objects, they will perform their initial discovery to MSY-CAS01, which will then return URLs for the servers in the New Orleans site.
Clients in Toledo will match
all six SCP objects. Because there are multiple objects, they will
perform their initial discovery to MSY-CAS01, which will then return URLs for the servers in the Toledo site.
If these are not the required
behaviors, you should take a close look at the Exchange 2007
Autodiscover white paper, which can be found on the Microsoft website at
http://technet.microsoft.com/en-us/library/bb332063.aspx. Although this paper is for Exchange 2007, the concepts transfer to Exchange 2010 without much damage.