OAB issues after simplifying the OWA 2010 URL?

Back since Exchange Server 5.0 which was the first version to include a webmail service (at the time known as Exchange Web Connect before renamed to Outlook Web Access, and now with Exchange 2010 renamed to Outlook Web App), customers typically required the webmail URL to be simplified. That is changed in such a way that users could simply enter “mail.domain.com” instead of https://mail.domain.com/exchange” or “https://mail.domain.com/owa”.

Back when we installed Exchange Server on top of Windows Server NT/2000/2003 this was often accomplished using an ASP or HTM webpage with some redirection code in it.

Then came Windows Server 2008/2008 R2 and a new IIS feature called “HTTP Redirect”. As you can see in the figure below this feature makes it possible to redirect incoming requests to a web site or a virtual directory underneath it. For details on how to redirect “mail.domain.com” to “https://mail.domain.com/owa” see this previous blog post of mine.

So why this post? Well, because I hit a nasty issue where the “HTTP Redirect” feature was the unforgiving sinner. After having performed the steps required for simplifying the OWA 2010 URL, internal Outlook MAPI clients as well as Outlook Anywhere clients had trouble downloading the offline address book (OAB). I didn’t get any sync error or anything in Outlook, the progress bar just stopped halfway through!

In this specific scenario Exchange was published using ISA 2006. Then why the re-direct configured in IIS and not on the ISA array you grumble? Because I had Exchange 2007 and 2010 co-existence configured and needed SSO experience for OWA hitting the Exchange 2010 CAS server. As some of you probably know you cannot pre-authenticate at the ISA layer and still experience SSO, when redirection occurs between Exchange 2007 and 2010 CAS servers in the same AD site

So I quickly blamed ISA but I was wrong. Very very wrong. As those of you who have read my blog post on how to simplify the OWA 2010 URL knows, when you enable “HTTP redirect” on the default web site, all virtual directories underneath it inherits this setting. So you need to uncheck the setting on all vdirs afterwards. When “HTTP redirect” is enabled for a vdir, IIS configures/creates a web.config file for each vdir and “Authenticated users” are given read/execute permissions on this file. But unlike the web.config file for the other vdirs (Autodiscover, ECP, EWS, OWA and so on), the web.config file associated with the OAB vdir is configured so that “System” and “local administrators” are given  full control but “Authenticated users” for some reason doesn’t get read/execute permissions assigned when it comes to this specific file.

Guess what the solution was? Yes correct I added “Authenticated users” with read/execute permissions as shown in figure 2:

…and voilá, clients could once again download the OAB file.

Cheers,