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.

 

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 Smile

 

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-ClientAccessServerAutoDiscoverServiceInternalUri  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

Exchange Autodiscover URL and Site Scope

 

 

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:

Connecting to the Autodiscover service from the intranet

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:

Connecting to the Autodiscover service from the Internet

 

A new feature is available that enables Outlook 2007 to use DNS Service Location (SRV) records to locate the Exchange Autodiscover service

 http://support.microsoft.com/?kbid=940881 

Prior to this update Outlook would perform these DNS queries by default:

  • https://<smtpdomain>/Autodiscover/Autodiscover.xml
  • https://autodiscover.<smtpdomain>/Autodiscover/Autodiscover.xml
  • http://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
  • http://autodiscover.<smtpdomain>/Autodiscover/Autodiscover.xml
  • SRV record query for _autodiscover._tcp.<smtpdomain>

 

As an example:

  1. Autodiscover posts to https://contoso.com/Autodiscover/Autodiscover.xml. This fails.
  2. Autodiscover performs the following redirect check:

    GET http://autodiscover.contoso.com/Autodiscover/Autodiscover.xml

    This fails.

  3. Autodiscover uses DNS SRV lookup for _autodiscover._tcp.contoso.com, and then "mail.contoso.com" is returned.
  4. Outlook asks permission from the user to continue with Autodiscover to post to https://mail.contoso.com/autodiscover/autodiscover.xml.
  5. 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 :

You cannot suppress the Autodiscover redirect warning in Outlook 2007

http://support.microsoft.com/kb/956528 

(Note the change in Registry path for the recent updates)

 

 

BONUS CHAT Smile

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.

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 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.

 

Cheers,

Rhoderick