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:
For a refresher on such joys of .PRF files etc. take a peek at:
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:
You’re back? Good reading – right? If you didn’t read it shame on you .
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.
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:
With this update installed the SRV query is added:
An example of using DNS to locate the Autodiscover endpoint:
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)
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:
The registry key for Outlook 2010 is:
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
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.
Value Type: DWORD
See http://technet.microsoft.com/en-us/library/cc837949(office.12).aspx for additional registry entries that you may wish to deploy with the Outlook client.