Solving Additional Issues With Exchange OAB Download

  • Article

Written by Rhoderick Milne, Microsoft Premier Field Engineer. Frank Plawetzki posted a great article on issues that can affect how clients retrieve their Offline Address Book (OAB).  This has also been the source of some recent work for myself, though with slightly different root causes.  The issues that I have encountered were due to:

  • Invalid SSL Certificate
  • OAB web.config file

Invalid Certificate Installation

OAB by default uses HTTP rather than HTTPS.  This is because the web OAB download mechanism uses BITS, and BITS does not support self signed certificates.  Thus to ensure a working initial configuration with the default self signed Exchange certificate, HTTP is used.  Once the correct certificate is installed, with all the URLs as per your CAS namespace design, then the URL can be changed to HTTPS.

This is important as sometimes certificate issues can block the HTTPS connection to CAS.  To bypass this, the client can connect to CAS by using HTTP thus eliminating SSL.  If the OAB download then works, then the issue is most likely with the certificate.  How do we get the client to connect with HTTP?  Either the OAB download location can be changed in EMS to HTTP with the command below or an AutoDiscover tweak can be used.

Set-OABVirtualDirectory –InternalURL “https://Exch-1.tailspintoys.com/OAB”

Though if this is not permissible due to change control etc. then it is possible to override the connection on an individual workstation.  Since AutoDiscover is responsible for handing the URLs to the client, all we have to do is to override AutoDisover results from the server by specifying a local AutoDiscover XML file as specified in the bonus tips of this blog entry.

It should also be noted, and as shown in Frank’s blog, Internet Explorer should typically be used as the browser when making test connections to Exchange.  This is because IE will use the same certificate infrastructure as Outlook, where other browsers maintain their own certificate stores.  That said, if you suspect that there is an issue with the IE certificate components then it would be a good test to use a different browser to see if the behaviour persists.

Invalid web.config File

Traditionally Exchange administrators have configured redirects on Outlook Web App so that users who do not add /Exchange or /OWA to the end of the URL are automatically  redirected to the correct URL (with the /Exchange or /OWA appended).  The same is also true for some organisations who want to automatically redirect users who do not enter the HTTPS:// prefix and use HTTP, again the URL will be automatically redirected.

This is an established practise with the Exchange community, and the process is documented on TechNet.  So what could possibly go wrong?  In short, not reading all the instructions, or working from a forum post that has incomplete instructions.  In the scenario that I will describe a web.config file is added to the OAB virtual directory and can cause issues.  By default no web.config file is present in the OAB directory as can be seen here:

Exchange 2010 OAB Default Content

When settings on the OAB virtual directory are changed to disable the redirection which is inherited from the root of the web site for example, a web.config is created to hold the settings.  This file does not have the correct ACL set and thus will cause issues for OAB download.

Exchange OAB web.config NTFS Permissions

An ACL to allow Authenticated Users to have Read & Execute permissions should be added.  Once the ACL is added the OAB  will be able to be downloaded.  This is documented on the TechNet article, but is not always implemented.  Please also review the note at the bottom of the TechNet article with regards to removing the redirection.

Cheers,

Rhoderick