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:
- Clients search Active Directory for a Service Connection Point (SCP) object in the local domain.
- Active Directory returns all SCPs, and the client figures out which is the closest one and best to connect to.
- If querying the SCP was unsuccessful, the Autodiscover client attempts to use DNS to locate Autodiscover (Autodiscover A-record or SRV-record).
- The Client Access server returns the available service URLs to the client.
- 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: https://denver-ex01.fabrikam.com/Autodiscover/Autodiscover.xml.
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.
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:
- https://<domain-smtp-address>/Autodiscover/Autodiscover.xml, which tries the following URL
- https://Autodiscover.<smtp-address-domain>/Autodiscover/Autodiscover.xml
- 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\
PreferLocalXML
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 fabrikam.com organization is:
C:\Program Files\Microsoft\Office15\OutlookAutodiscover\fabrikam.com.XML
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
http://technet.microsoft.com/en-us/library/cc511507.aspx.
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 Autodiscover.<domain name>.com 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 Litware.com domain on the Litware internal DNS servers and Autodiscover.fabrikam.com 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 fabrikam.com.
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:
http://technet.microsoft.com/en-us/library/cc511507.aspx.
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:
- HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Outlook\Autodiscover
| DWord Name | Description |
| 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
Example:http://Autodiscover.Contoso.com/Autodiscover/Autodiscover.xml
|
| ExcludeHttpsAutodiscoverDomain |
Excludes lookups for Autodiscover.[SMTP domain].com/
Autodiscover/Autodiscover.xml
Example:https://Autodiscover.Contoso.com/Autodiscover/Autodiscover.xml
|
| ExcludeHttpsRootDomain |
[SMTP Domain]/Autodiscover/Autodiscover.xml
Example: https://Contoso.com/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 table:
| Service | Description |
| 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
|
No comments:
Post a Comment