Share via

Windows Server 2008, IIS 7.0, Exchange 2007 and the Offline Address Book

  • Article

I've been working through an interesting situation with one of my customers during the past couple of weeks.  For some reason, everytime Outlook 2007 clients attempted to download the offline address book (OAB), they would error out.  We found a lead at https://lugies15.blogspot.com/2008/09/offline-address-book-connecting-to.html and noticed that the permission change recommended here fixed the problem.  But we couldn't figure out why setting an open read permission to everyone on the c:\program files\microsoft\exchange\client access\oab folder would fix an issue of OAB failing to download.  They already had permission on the child folder and xml files through authenticated users.

Some basic troubleshooting steps involve testing the Outlook autoconfiguration to extract the URL that Outlook is using to pull the OAB from.  The URL for OAB was found to be https://server.domain.org/oab/guid-like-number/oab.xml.  When I tried to open it with Internet Explorer, I noticed that I was getting an access denied error, but not on the OAB.XML file, but rather the web.config file in the parent (/oab) virtual directory.

We traced this back to a configuration change we made a week earlier.  We wanted a redirect off the root folder to the /owa folder.  This was configured in the IIS 7.0 GUI, which results in the following configuration file.

<?xml version="1.0" encoding="UTF-8"?>

<configuration>

    <system.webServer>

        <httpRedirect enabled="true" destination="https://server.domain.org/owa" exactDestination="true" childOnly="true" httpResponseStatus="Permanent" />

    </system.webServer>

</configuration>

However, IIS 7.0 did not seem to respect "redirect this folder only" setting.  In fact, nearly all the subfolders, including /OWA and /OAB were redirecting, which effectively wiped out the OWA functionality.  This was fixed by disabling redirects in each of the affected child folders (note that some folders might be redirected by design and shouldn't be reversed - depending on your configuration and requirements).  That placed a web.config file in each of the child folders which looked like this:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <httpRedirect enabled="false" />
    </system.webServer>
</configuration>

This config file was the file that our Oulook/IE client failed to read.  When we set permissions on this file such that Authenticated Users had read permission, the problem was resolved.  This explained why the configuration adjustment recommended at Lugie's blog made sense.