In the Exchange 2003 world and below, those administrators looking to automate and control the behaviour of MAPI profiles on user’s desktops quickly became familiar with tools like:
-
ORK (Office Resource Kit)
-
.PRF Files
-
.OPS files (from the Office Profile wizard)
-
PROFGEN
-
PRFPATCH
-
ExProfRe
For a refresher on such joys of .PRF files etc. take a peek at:
Whitepaper: Configuring Outlook Profiles by Using a PRF File
Automate Outlook Profile Creation Using PRFPATCH
The Exchange Profile Update tool
Owch, those were some painful days! Thankfully with Exchange 2007/2010 and Outlook 2007/2010 we are able to move on from such tasks. Exchange 2007 introduced the Autodiscover web service which is used by Outlook 2007 and above to automatically configure the required Outlook settings. This not only includes the initial connection to Exchange but also if the administrator then makes changes to URLs then Outlook will detect and apply such changes. This is a great boon to administrators and will reduce user & configuration issues.
Sounds good does it not?
It is; but I typically see this as one of the most misunderstood and misaligned services in Exchange. As far as I am concerned if Autodiscover is broken, then Exchange is broken in your environment and needs immediate remediation.
Update 17-3-2015 Updated post with headings and added some additional detail
Update 16-4-2014 Added note indicating that Autodiscover settings may be in multiple locations in the registry
Autodiscover References
Take 10 minutes to carefully read through these links:
Exchange 2007 -- White Paper: Exchange 2007 Autodiscover Service
Exchange 2010 -- Understanding the Autodiscover Service
White Paper: Understanding the Exchange 2010 Autodiscover Service
You’re back? Good reading – right? If you didn’t read it shame on you 
Autodiscover Misconceptions
The key issue that I encounter when working on Exchange engagements is the perception that Outlook ONLY uses DNS for Autodiscover. If your workstation is domain joined and you are connected to the internal network you should NOT be using DNS to determine which server you will contact for Autodiscover, this is a very common falsehood. In actual fact you should be leveraging a Service Connection Point (SCP) in AD. The SCP is published into AD when a CAS server is installed. This is done automatically by the Exchange setup routine. You can see the value in ADSIEDIT as the serviceBindingInformation attribute and in PowerShell using the Get-ClientAccessServer –AutoDiscoverServiceInternalUri parameter. For example in my lab, the serviceBindingInformation attribute is found under the server object here:
CN=EXCH-1,CN=Autodiscover,CN=Protocols,CN=EXCH-1,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=Tailspintoys,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=tailspintoys,DC=com
While we are here, you will also see the keywords attribute. This is the underlying attribute that holds the information set buy Set-ClientAccessServer –AutoDiscoverSiteScope. The two attributes can be seen here:
Get-ClientAccessServer | Select AutodiscoverServiceinternalUri, AutoDiscoverSiteScope | FT –Autosize
By default this URL will be the FQDN of the server. This should be changed to a Load Balanced URL as per your Exchange design to achieve HA.
To show the domain joined lookup process in a diagram:
Outlook will build either (but not both) a list of CAS servers in-site or out of site. The AutodiscoverSiteScope value is used to determine site membership. It will the sort them and connect to the 1st one in the list. This means that you will typically connect to the CAS that was installed first. If Outlook fails to contact any CAS server based off its SCP look-up then it will fall back to DNS.
For external Outlook clients in Starbucks, they are not able to directly contact AD (I sure hope that you don’t have a DC exposing 389 TCP to the Internet…..) and thus will have to use DNS to locate the Autodiscover endpoint. This is illustrated here:
A new feature is available that enables Outlook 2007 to use DNS Service Location (SRV) records to locate the Exchange Autodiscover service. This was first made available with hotfix 940881 and is now built in to all supported Outlook versions. There is no need to install this update manually nowadays.
Prior to this update Outlook would perform these DNS queries by default:
-
https://<smtpdomain>/Autodiscover/Autodiscover.xml
-
https://autodiscover.<smtpdomain>/Autodiscover/Autodiscover.xml
-
Local XML
With this update installed the SRV query is added:
-
https://<smtpdomain>/Autodiscover/Autodiscover.xml
-
https://autodiscover.<smtpdomain>/Autodiscover/Autodiscover.xml
-
http://autodiscover.<smtpdomain>/Autodiscover/Autodiscover.xml
-
SRV record query for _autodiscover._tcp.<smtpdomain>
-
Local XML
As an example:
-
-
Autodiscover posts to https://contoso.com/Autodiscover/Autodiscover.xml. This fails.
-
Autodiscover posts to https://autodiscover.contoso.com/Autodiscover/Autodiscover.xml. This fails.
-
Autodiscover performs the following redirect check:
GET http://autodiscover.contoso.com/Autodiscover/Autodiscover.xml This fails.
-
Autodiscover uses DNS SRV lookup for _autodiscover._tcp.contoso.com, and then "mail.contoso.com" is returned.
-
-
Outlook asks permission from the user to continue with Autodiscover to post to: https://mail.contoso.com/autodiscover/autodiscover.xml.
-
Autodiscover's POST request is successfully posted to https://mail.contoso.com/autodiscover/autodiscover.xml.
Note: If you Internet facing DNS provider does not support SRV records then you cannot use this feature.
You may not want your users to see the redirect warning as mentioned in step 5 above. if so then please review KB 956528 You cannot suppress the Autodiscover redirect warning in Outlook 2007.
(Note the change in Registry path for the recent updates)
Checking The Autodiscover SRV Record
Please see this post on the Nslookup syntax to check for the Autodiscover SRV record.
Updated 17-3-2015 Added this link and section
Additional Autodiscover Configuration Items
There are other really interesting things you can do with the registry to tune and alter the default behaviour of Autodiscover on the Outlook client machine. One item worth noting is these registry settings can be located in multiple places. Note the highlighted differences below:
HKEY_CURRENT_USER\Software\Microsoft\Office\<VERSION>\Outlook\AutoDiscover
HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\<VERSION>\Outlook\AutoDiscover
This behaviour is noted in KB 2480582, KB 2783881 and KB 2212902. As noted in KB 2612922, the GPO settings controlling Outlook Autodiscover are located in the policies location in the registry.
HKEY_CURRENT_USER\Software\Policies\Microsoft\Office1x.0\Outlook\AutoDiscover
The registry that we need to look at varies according to the version of Outlook.
Outlook 2007:
HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\12.0\Outlook\AutoDiscover
Outlook 2010:
HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\14.0\Outlook\AutoDiscover
Outlook 2013:
HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\15.0\Outlook\AutoDiscover
If you ware working on a test machine, you might want to use the registry editor favourites tool to allow you to quickly return to these locations.
By changing the values below you alter the default behaviour of Autodiscover. The following are the entities we can control, and the values are then discussed afterwards in additional detail.
- PreferLocalXML
- ExcludeHttpRedirect
- ExcludeHttpsAutoDiscoverDomain
- ExcludeHttpsRootDomain
- ExcludeScpLookup
- ExcludeSrvRecord
- ExcludeLastKnownGoodURL (Initially only applied to Outlook 2013/2016. Backported to 2010, see note below)
Value name: PreferLocalXML
Value type: DWORD
Value data: 0 or 1
Value name: ZeroConfigExchange
Value type: DWORD
Value data: 0 or 1
DisableAutoStartup
Value type: DWORD
Value data: 0 or 1
Value name: ExcludeHttpRedirect
Value type: DWORD
Value data: 0 or 1
Value name: ExcludeHttpsAutodiscoverDomain
Value type: DWORD
Value data: 0 or 1
Value name: ExcludeHttpsRootDomain
Value type: DWORD
Value data: 0 or 1
Value name: ExcludeScpLookup
Value type: DWORD
Value data: 0 or 1
ExcludeLastKnownGoodURL
Value type: DWORD
Value data: 0 or 1
(Note that this was added in Outlook 2013. Did not exist prior).
(This was backported to Office 2010 as discussed in KB 2212902 ).
Value name: ExcludeSrvRecord
Value type: DWORD
Value data: 0 or 1
Some old documentation states that the ExcludeSrvLookup value is used by Outlook in this scenario. Unfortunately, this documentation is incorrect as the ExcludeSrvLookup value does not exist in Outlook code. Only the ExcludeSrvRecord registry value is used by Outlook to control the SRV record lookup for Autodiscover. Therefore, if you find a value called ExcludeSrvLookup under the Autodiscover subkey, you can safely change its value to 0.
Autodiscover Local XML File
To expand on the Local XML option, when Autodiscover functionality is available on your e-mail server, Outlook initiates the Autodiscover process to obtain server connectivity settings. Once a server that supports Autodiscover is located, the server returns XML data that provides the information needed for Office Outlook 2007 to automatically configure your e-mail account.
The Local XML registry value allows you to specify a local path to an .xml file that Outlook can additionally use to configure its e-mail account. The name of the registry value is the host name of the e-mail address that is provided to Outlook. In the following example, the specified path to the .xml file would be used for any e-mail addresses ending in contoso.com. The path in the first case is to a file named Autodiscover.xml located on a server named server1. A local option is then shown. Note that the example is for Outlook 2010.
Key: HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\AutoDiscover
Value Type: STRING
Name: contoso.com
Data: \\server1shareautodiscover.xml
or
Data: C:\AutoD\AutoDiscover.xml
See TechNet for additional registry entries that you may wish to deploy with the Outlook client.
Cheers,
Rhoderick
