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:
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.
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
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
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 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 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 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:
As an example:
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 :
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.
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.
If you would like to have Microsoft Premier Field Engineering (PFE) visit your company and assist with the topic(s) presented in this blog post, then please contact your Microsoft Premier Technical Account Manager (TAM) for more information on scheduling and our varied offerings!
If you are not currently benefiting from Microsoft Premier support and you’d like more information about Premier, please email the appropriate contact below, and tell them you how you got introduced!
For all other areas please use the US contact point.