Office Communicator "Outlook Integration Error" problems when using ISA 2006 and Exchange Kerberos Constrained Delegation

Now that's a wordy title. I've been meaning to write this up since about March in more detail with some fancy diagrams, but I've finally given in and decided to just get the information published and update it later. One of the nicest features of ISA 2006 is the ability to use Kerberos Constrained Delegation (KCD) in reverse proxy scenarios. This can used to publish applications like Exchange or SharePoint externally and allows passing NTLM credentials over an SSL channel to ISA which authenticates to Exchange or SharePoint via Kerberos on behalf of the user, making for a seamless experience regardless of location. Read: No freaking login prompts outside the firewall, even in Outlook Anywhere with ISA performing pre-authentication of users. Jason Jones has an outstanding article already written outlining how to set up KCD with Exchange 2007 and ISA 2006 that I recommend following if you're interested. The point of this article is not to explain how to configure KCD, but to highlight two issues you'll find when deploying this with Microsoft Office Communicator. If you've deployed KCD for Outlook Anywhere and have users with Communicator outside the firewall they'll probably see the dreaded "Outlook Integration Error" or "Communicator could not retrieve calendar or Out of Office information from Exchange Web services" warnings.

There are actually two issues here that we need to resolve. The first is that Communicator itself actually uses some slightly different RPC over HTTPs logic than Outlook which causes the KCD authentication through MOC to flat out fail. In R1 of OCS 2007 I found the clients were prompted for credentials 3 times for the Outlook integration and then the integration would fail even with correct credentials. With the R2 client you'll no longer see the authentication prompts, but the Outlook Integration error would eventually show up. The problem is in how ISA 2006 handles POST requests than do not have a POST body, which is apparently the difference between Outlook and MOC's logic. There is a hotfix available for this which requires running a .vbs script to make the change to ISA. You can find that hotfix and script here: http://support.microsoft.com/default.aspx?scid=kb;EN-US;942638. You actually need to apply the ISA 2006 Supportability Update package before you can install this hotfix and that package is here: http://support.microsoft.com/kb/939455/.

The second issue you'll find is that when ISA offers Communicator the Negotiate and NTLM authenticate headers Communicator actually tries to negotiate and fails. This can be remediated by changing ISA to offer only NTLM headers to clients. There is another hotfix and .vbs script to fix this issue which you can find here: http://support.microsoft.com/kb/927265/en-us. One warning I should point out is this is a system-wide setting and will disable Kerberos for outbound-proxy scenarios. I'm not a big fan of ISA for anything other than a reverse proxy so this had no issues on my environment, but be careful to evaluate your existing rules if you use ISA for anything else.

You can test out the second hotfix without making any changes to the ISA server by going in to IE's advanced settings on a client and unchecking the box "Enable Integrated Windows Authentication." (Thanks to Scott Oseychik for this tip). Contrary to the outstanding verbiage, this only disables Kerberos authentication in IE and will force IE to only try to authenticate via NTLM.

Once you have all of your hotfixes installed you should be able to login to MOC only and receive no more Outlook integration errors. Perfectly seamless authentication anywhere you are. Jason Jones pointed out the two hotfixes for me originally, so a huge thanks is in order to him.

Replication Host Names

In Exchange 2007 Service Pack 1, a new feature was introduced that allowed additional redundant networks to be added to a CCR environment for the purposes of log shipping and database seeding. With specific networks dedicated to log shipping and database seeding, the remaining network is dedicated to its task of servicing client communications. Such a configuration avoids situations where the network that is servicing client communications also has to process a large number of transaction logs.

Replication Host Names are an Exchange 2007 SP1 feature that I don't think is used very often or that well known. This is a great article on setting it up from both a Windows 2003 and 2008 perspective.

Via Neil Hobson.

OAB Never Downloads for Outlook 2007 Clients with Exchange 2007 on Server 2008

Update: This post gets a lot of traffic, but I want to be clear the first step here is no longer required. Simply perform the solution at the end of the post.

This one killed me today. Exchange 2007 SP1, with Rollup Update 6 on Server 2008. Everything working perfectly with one exception – the offline address book (OAB) never downloads from the file distribution point for Outlook 2007 clients. Works fine via public folders, but not web-based. No error, no timeout, no progress indicator, no login prompt, Outlook just looks like it’s endlessly trying to download the OAB. I double-checked all the URLs, flipped around SSL settings, but still couldn’t figure out why it wouldn’t download. I would have been happy to see an error so I had something to search on. There were actually 2 problems here that made the situation a real pain in the ass.

First – the same bug that affects Outlook Anywhere on Server 2008 apparently does a number on the OAB too. The solution is to turn off kernel-mode authentication in IIS. Run this command to fix that issue and you’re halfway there. I ran across some blog that mentioned Rollup Update 7 may include this change by default.


C:\Windows\system32\inetsrv\appcmd.exe set config /section:system.webServer/security/authentication/windowsAuthentication /useKernelMode:false

Second – I had enabled a redirect at the Default Web Site root to dump clients to the /owa folder gracefully using the Microsoft methodology at Technet. If you read the procedure you’ll notice setting the redirect at the root sets the same redirect on every single virtual directory. So, you need to go in to each virtual directory and undo the change you made for the root. This works fine, or appears to until your Outlook 2007 client tries to download the OAB and hangs forever.

I brightly plugged the URL to the OAB.XML file into IE and was greeted with a 500 – Internal Server Error message without an authentication prompt. That didn’t seem right. After some searching I realized the reason why Outlook hangs forever is that it tries to hit this URL, gets denied, uses some back-off logic, and tries again. I believe the back-off gets longer and longer each time it fails.

What happens is that when you disable that redirect for the OAB virtual directory IIS 7 generates a web.config file in the C:\Program Files\Microsoft\Exchange Server\ClientAccess\OAB folder. This seems logical, as it overrides the redirect at the root level, and is necessary. Unlike every other web.config that is generated in the other folders like Autodiscover and OWA, Authenticated Users do not have read access to the file. This is why Outlook and IE can’t even access the /OAB virtual directory.

The fix is pretty easy. Open the web.config in the OAB folder, and give Authenticated Users both the read and read and execute permissions. Run a iisreset /noforce on the CAS server to bounce IIS. Just for good measure, on the client side I wiped out the Outlook profile, and the contents of the %USERPROFILE%\Local Settings\Application Data\Microsoft\Outlook folder. Once I recreated the profile the OAB downloaded just fine. All in a day’s fun…