Autodiscover is a critical service to understand, because it automatically configures email profiles for Microsoft Outlook email clients, mobile devices like smartphones, tablets, and so on. It also provides the client URLs for features such as free/busy, Unified Messaging, the Out of Office assistant, shared and site mailboxes, and the OAB. Because Autodiscover information is refreshed when the email client is started and at regular intervals (every 60 minutes), it allows the administrator to move mailboxes without having to manually reconfigure every email client. The interval at which the client is expected to refresh its configuration can be changed with the Set-OutlookProvider cmdlet by setting the TTL parameter to the number of hours for the interval. Some clients, such as Windows Mobile devices, use Autodiscover for initial profile creation, but do not refresh the configuration once the profile has been created. Also, the email clients find the URL for Autodiscover differently based on whether the client has internal access or external access. The Autodiscover service is not used by Outlook versions prior to Outlook 2007.

Internal Autodiscover Process

Internal email clients are clients that are domain joined and that can successfully query an Active Directory server for Autodiscover information. The following figure shows the process for how internal email clients use Autodiscover.

As you can see, the internal Autodiscover process includes the following steps:

  1. Clients search Active Directory for a Service Connection Point (SCP) object in the local domain.
  2. Active Directory returns all SCPs, and the client figures out which is the closest one and best to connect to.
  3. If querying the SCP was unsuccessful, the Autodiscover client attempts to use DNS to locate Autodiscover (Autodiscover A-record or SRV-record).
  4. The Client Access server returns the available service URLs to the client.
  5. An SCP object is created in Active Directory during the Exchange installation of the Client Access Server role with an AutodiscoverServiceInternalURI value equal to that of the fully qualified domain name (FQDN) of the server itself. You can view this value by entering the following command in the Exchange Management Shell: Get-ClientAccessServer | fl AutodiscoverServiceInternalURI, AutodiscoverServiceInternalUri:

Configuring AutodiscoverSiteScope

The AutodiscoverSiteScope property defines the Active Directory site or sites for which the Client Access server provides services. The property is set to the Active Directory site where the Client Access server was located during installation. The property is never updated automatically, even if the host is moved to a different Active Directory site.

You must change this property if your Active Directory configuration changes or the Client Access servers are moved to another Active Directory site.

Another key concept to understand is that the client attempts to connect to the closest Client Access server; however, the URLs and the configuration that the server returns to the client are for a Client Access server in the Active Directory site closest to the mailbox. Starting with the release of Exchange 2010 SP2 RU1, there is one exception to this behavior, and it’s for the Offline Address Book (OAB) URL.

Very few organizations have configurations where a Client Access server will need to service over 800 Active Directory sites; however, the upper limit of the number of entries in the AutodiscoverSiteScopeproperty is 800 entries. If you attempt to configure more than the limit using the Set-ClientAccessServer cmdlet, you will receive an ADMIN_LIMIT_EXCEEDED error. One way to work around this limit is to deploy more than one Client Access server in the Active Directory site and split up the AutodiscoverSiteScope entries between the Client Access servers. For example, assign 400 Active Directory sites to the AutodiscoverSiteScope property for one Client Access server and 400 to the other Client Access server. To ensure this works, you will also change theAutodiscoverServiceInternalURI parameter to reference a load-balanced name that includes all Client Access servers within the Active Directory site.

Note: If you have a large number of sites that do not have Exchange servers, check out Brad Hugh’s blog for a script that automates site assignment:

The SCP property AutodiscoverSiteScope for the Client Access server in the Denver site are set toDenver. Likewise, the AutodiscoverSiteScope property for the Client Access servers in the Miami site are set to Miami. The client computers in Denver will use Autodiscover from the Client Access servers in the Denver site, and the client computers in Miami will use the Client Access servers in Miami for Autodiscover. Client computers in Portland will use a Client Access server in either Denver or Miami because none of the Client Access servers are configured with Portland in the AutodiscoverSiteScope. This causes client computers in Portland to use Client Access servers in a site that is not optimal. To correct this issue, just set the AutodiscoverSiteScope on the Client Access servers in Denver to cover both Denver and Portland. Afterward, clients in those sites will use only the Client Access servers in Denver for Autodiscover. The picture shows the settings of AutodiscoverSiteScope in every Active Directory site where Client Access servers are located.

You can see three Active Directory sites, with Client Access servers and Mailbox servers located in the Denver and Miami sites. Users using Outlook 2013 clients are located in all the sites. Remember that the configuration information the Client Access server returns is for the server closest to the user’s mailbox, regardless of the location of the client computer. All subsequent Autodiscover requests still go to the Client Access server closest to the client computer—not the Client Access server closest to the mailbox. To achieve this configuration, you add the Active Directory site names by running a command such as the following:

Set-ClientAccessServer –Identity DenverCAS –AutodiscoverSiteScope “Denver”, “Portland”

External Autodiscover Process

If the client is external or non-domain joined, there is a different process for Autodiscover, as shown in the following figure:

The process goes like this:

The client attempts to search Active Directory for a SCP and fails, because the client computer is not a domain member.

The client attempts to connect to the Autodiscover service using a well-known URL made with the user’s primary SMTP address (just the domain parts after the @). These well-known URLs include the following:

  • If the previous attempt was unsuccessful, Outlook checks for a local XML file. If PreferLocalXML is set in the registry, the XML file settings override any other settings.
  • If no XML file is found, Outlook looks for an SRV record using the mailbox email address. (This applies only to Outlook 2007 clients with Service Pack 1 or later.)
  • Once Outlook finds the settings, it connects to the specified Client Access server, processes the request, and returns the best available service URLs for the user.

Deploying a Static Autodiscover XML File

As mentioned in the previous section, you can configure Autodiscover by deploying an XML-based file to the Outlook client computers. This might be required when an acquired company starts using the parent company’s domain, resulting in two Exchange organizations in two Active Directory forests that use the same SMTP domain. In this situation, all the Outlook clients connect to the same Exchange organization. Use an XML file to configure the Outlook clients to connect to the correct Exchange organization. If you want the Autodiscover clients to use the XML file, you need to add the registry entry PreferLocalXML as DWORD value name with the value data 1 to force the static XML to be preferred over any other method. The following shows the configuration for Office 2013, for Office 2010 replace 15.0 by 14.0, for Office 2007 replace it by 12.0:

  • HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Outlook\Autodiscover\

Then you need to customize the path to the local XML file:

  • HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Outlook\Autodiscover\
    [Domain Name]

The value term of the key must be the full path to the XML file and the type must be a string. For example, the full path to the following XML file for the organization is:

C:\Program Files\Microsoft\Office15\OutlookAutodiscover\

Of course, you need a way to deploy this XML file to all your client computers. A sample XML file and the schema for it is explained in the TechNet article: “Plan to automatically configure user accounts in Outlook 2010” found at

You might also use products such as System Center Configuration Manager or Active Directory Group Policies to push it out.

Note: A static Autodiscover XML file should be set only for two forests using the same SMTP name. After you perform the migration, we recommend that you delete the XML file and use Autodiscover.

DNS SRV Record

An option was introduced in an Outlook 2007 hotfix (and is included in Service Pack 1 and later) to find the Autodiscover service by querying for a DNS SRV record. This change in Outlook 2007 is extremely useful for Exchange organizations that have a large number of SMTP domains or that frequently change SMTP domains. For this example, we will use Litware as one of these vanity domains. One opportunity is to purchase a Subject Alternative Name (SAN) certificate with each SMTP domain name and point all the DNS records to one address; however, this can become expensive and it’s a configuration that’s difficult to maintain.

To reduce the complexity of requesting certificates, a DNS service record for “Autodiscover” is created for the domain on the Litware internal DNS servers and is set as the service host for Autodiscover. The end user will be prompted and must accept the request to allow the redirected site to configure the client, as shown in the screenshot:

This request can be disabled if you use Outlook for Windows by creating a registry key on the Outlook 2013 client:

  • HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Outlook\Autodiscover\RedirectServers

If you want to disable it for Outlook 2010, replace 15 .0 with 14.0 in the registry key or 12.0 for Outlook 2007. Add a new String Value with the name of the HTTPS server to which Autodiscover can be redirected without prompting for confirmation from the user. For Fabrikam, the first String Value (REG_SZ) name would be

With either method, the connection to the Client Access server is secured using SSL and certificates. For a secure connection to succeed, the certificate must be valid, meaning it must be trusted by the client computer, have a name that matches the URL the client connects to, and must not be expired. For Outlook 2007 domain-joined clients, Outlook will ignore the requirement for trusting the root certificate, allowing the out-of-box self-signed certificate to work. Regardless, it is recommended under all circumstances to replace the self-signed certificate with a valid commercial or internal public key infrastructure (PKI)-generated certificate. For further information to plan to automatically configure user accounts in Outlook 2010, visit the following TechNet link:

Note: Outlook 2010 and Outlook 2013 reverse this behavior and will display a warning to the user if there is a self-signed certificate—even for domain-joined clients. This reinforces the best practice to replace the self-signed certificates with trusted certificates.

If the default Autodiscover behavior is not satisfactory, you can customize the order—or even exclude specific steps—of the Autodiscover process. To change the settings, you must add one or more of the registry values listed in the table to the following key if you are using Outlook 2013 – remember, if you are using a different Outlook version, just exchange the version number:


PreferLocalXML: Forces Outlook to prefer the XML file to all other information it receives

ExcludeHttpRedirect: Excludes lookups for a redirect from HTTP against the SMTP domain


ExcludeHttpsAutodiscoverDomain: Excludes lookups for Autodiscover [SMTP domain].com/Autodiscover/Autodiscover.xml


ExcludeHttpsRootDomain: [SMTP Domain]/Autodiscover/Autodiscover.xml


ExcludeScpLookup: Excludes the Active Directory query for the SCP object

ExcludeSrvRecord: Excludes the DNS SRV record check


Autodiscover Summary

Autodiscover provides the necessary links to the clients for the services listed in the following enumeration:

OutlookAnywhere: RPC-over-HTTPS / MAPI-over-HTTPS Outlook connection endpoint

Exchange Web Services: Handles out-of-office messages, Availability Service, MailTips, third-party applications, among other things

Exchange ActiveSync: Responsible for the automatic configuration of mobile devices

Offline Address Book: Necessary to connect the client to the correct OAB in the Exchange organization

Unified Messaging: Used to collect information about Unified Messaging, voice mail, and so on.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s