What Everyone Should Know About Microsoft Exchange Autodiscover
Written by Rhoderick Milne, Microsoft Premier Field Engineer.
For an updated version, please see this link.
In the Microsoft Exchange Server 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
Autodiscover To The Rescue
Ouch, 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 and 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 your Autodiscover is broken then Exchange is broken in your environment and needs immediate remediation.
Take 10 minutes to carefully read through these links:
- Exchange 2010 -- Understanding the Autodiscover Service
- Exchange 2007 -- White Paper: Exchange 2007 Autodiscover Service
You’re back? Good reading – right? If you didn’t read it shame on you .
Autodiscover On The Internal Network
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 server setup routine. You can see the value in ADSIEDIT as the serviceBindingInformation attribute and in PowerShell using the Get-ClientAccessServer –AutoDiscoverServiceInternalUri parameter.
By default this will be the FQDN of the server. This should be changed to a Load Balanced URL as per your Exchange design to achieve high availability (HA).
To show this 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 then date sort these 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.
Autodiscover On The Internet
For external Outlook clients, such as those located in your neighbourhood Starbucks, these are not able to directly contact AD (at least I sure hope that you don’t have a DC exposing 389 TCP to the Internet) and thus will 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.
Prior to this update Outlook would perform these DNS queries by default:
- https://<smtpdomain>/Autodiscover/Autodiscover.xml
- https://autodiscover.<smtpdomain>/Autodiscover/Autodiscover.xml
- https://autodiscover.<smtpdomain>/Autodiscover/Autodiscover.xml
With this update installed the SRV query is added:
- https://<smtpdomain>/Autodiscover/Autodiscover.xml
- https://autodiscover.<smtpdomain>/Autodiscover/Autodiscover.xml
- https://autodiscover.<smtpdomain>/Autodiscover/Autodiscover.xml
- SRV record query for _autodiscover._tcp.<smtpdomain>
Example of using DNS to locate Autodiscover
An example of using DNS to locate the Autodiscover endpoint:
- 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 https://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 your 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 You cannot suppress the Autodiscover redirect warning in Outlook 2007.
(Note the change in Registry path for the recent updates)
BONUS Autodiscover Tips
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.
The registry key for Outlook 2007 is:
HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\12.0\Outlook\AutoDiscover
The registry key for Outlook 2010 is:
HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\14.0\Outlook\AutoDiscover
By changing the values below you alter the default behaviour of Autodiscover. The names of the registry keys are fairly explanatory, though scroll to the end of the post for a link to the documentation.
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
Value name: ExcludeSrvRecord
Value type: DWORD
Value data: 0 or 1
To expand on the Local XML option, when Autodiscover functionality is available on your e-mail server, Outlook 2007 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 2007 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.
Key: HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\AutoDiscover
Value Type: DWORD
Name: contoso.com
Data: \\server1\share\autodiscover.xml
or
Data: C:\autodiscover.xml
See https://technet.microsoft.com/en-us/library/cc837949(office.12).aspx for additional registry entries that you may wish to deploy with the Outlook client.
Cheers, Rhoderick