17 July 2008

Exchange/Outlook Autodiscover Feature

I was browsing the TechNet library today, and noticed an article on troubleshooting Error 0x8004010F, when occurs when Outlook 2007 tried to download the OAB from an Exchange 2007 server. The article is OK, if you understand what it’s saying, but like many articles can be confusing.

When you run Outlook on a domain joined computer, Outlook can make use of the domain information to access the active directory and obtain Service Connection Point information - i.e. details of where Exchange is, and this information in turn can help Outlook to locate your correct Exchange server (and download the OAB).

In some cases, e.g. when the machine is not a domain member, this process does not work. To cater for this situation, Microsoft has provided another way to obtain the relevant data making use of DNS.

But first some background. Windows services can use the Service Publication feature to advertise themselves using AD objects, in particular service connection points (SCPs).  A client application, e.g. Outlook 2007, can use the SCP information to bind to a service, in this case to Exchange 2007’s Client Access Server and then discover details about the Outlok user. This feature is known as Exchange 2007 Autodiscover.

As per the Autodiscover white paper, Exchange 2007 registers a SCP in AD for each server running the CAS role. These SCPs contain the serviceBindingInformation attribute (holding the FQDN of the CAS server in the form of: “https://cascookham1.gktrain.net/autodiscover/autodiscover.xml) and the keywords attribute (containing the AD sites to which this server is associated. i.e. the AD site the which this CAS server resides).

Outlook uses this information to access the autodiscover web service. Outlook first contacts the AD to retrieve all the relevant SCP objects. Outlook first tries to find a CAS server in its site and if this is not successful, it tries to find any CAS server in the forest. The white paper describes the creation of in-site and out-of-site lists and how these are used to locate the CAS Server.

Once Outlook then uses the SCP records to contact the autodiscover service on the CAS, based on the contents of the the serviceBindingInformation attribute noted above. When Outlook queries the autodisover service, the service queries the AD to obtain connection settings and URLs for all Exchange Services. The service then returns this information to Outlook in an XML document. Outlook then uses the information to locate the appropriate configuration information and connection settings for Exchange.

When running Outlook on a non-domain joined machines, this basic process doesn’t work, since the computer is not able to access the AD. In such cases, Exchange provides a second method to help Outlook to locate the autodiscover service and obtain the relevant autodiscover information (i.e. to obtain the autodiscover.xml file).

If the normal SCP method fails, then Outlook determines the name of the SMTP mail domain (it’s on the right side of the user’s e-mail address). If my SMTP mail address is tfl@gktrain.net, then the relevant domain is gktrain.net. Outlook then constructs two URLs based on this domain and tries each of them. These URLs are

  • https://<smtp domain name>/autodiscover/autodiscover.xml (in this case, https://gktrain.net/autodiscover/autodiscover.xml)
  • https://autodiscover.<smtp domain name>/autodiscover/autodiscover.xml (in this case https://autodiscover.gktrain.net/autodiscover/autodiscover.xml).

So if you are using Exchange and Outlook and seeing this error – then setup the appropriate DNS records in your corporate DNS to facilitate DNS based autodiscovery. The white paper also looks at issues around SSL certificates, connecting to the autodiscover service form the Internet and how to deploy and manage this service in both enterprise and hosted environments.

2 comments:

Trevor said...

Hi there,

Just thought I would leave a note to say "Thank you so much" for this entry.

It contained the last piece of a complex puzzle that I was trying put together to explain why our Free/Busy time wasn't visible from non-domain based machines.

We set primary smtp addresses on accounts to our root domain. Our autodiscover records in DNS point to our Exchange domain (resource forest topology). As a result, autodiscover wasn't resolving properly when our Outlook clients queried DNS using the domain portion of the primary smtp address.

When we changed the primary smtp address back to that of the Exchange domain for our accounts and are using address re-writes on the Edge Server to accomplish what we had previously done with setting the primary stmp address (specifically, controlling the from address on email headers).

Your explanation on how Outlook determines the autodiscover URL was the key piece of information that I needed.

Thanks!

Trevor

Alex said...

MS Outlook and outlook files are very popular in my computer and not once was problems with them,but no none tool helped me,and in some time for me advised-can not open pst,and it helped me!,program is free as far as I know,moreover it can many nice probabilities-can open files with PST and OST extension and repair all files from that archives,program permits to process such files, even if they contain viruses or the file is too large, it is safe,compatible with all supported versions of Microsoft Outlook and Microsoft Windows,analyses your mailbox and attempts to identify the mails, that can be successfully retrieved,extract either separate files of *.eml, *.txt and *.vcf format or pack these files to a file of PST format, that can be opened with Microsoft Outlook or any other compatible email client.