Aaron Tiensivu's Blog

This bug: "You are prompted for your credentials three times and you receive an error message when you use the Outlook Anywhere feature to connect to an Exchange Server 2007 Service Pack 1–based server that is running Windows Server 2008", has been an extreme thorn in my side whenever installing an Exchange 2007 CAS server with Server 2008 as the host OS. Elan has a good writeup about it here. It is just unfortunate that it has taken this long for the issue/fix to be acknowledged and addressed.

There is also a known issue with the Outlook Address Book (OAB) not replicating properly in clustered Server 2008 environments, which is caused by 2 known bugs, and I'm still researching if this rollup fixes that issue. You can read more about the issue here and here, with a few workarounds until an official fix is released.

Download the rollup here, and read about the CAS/IPv6 issue here.

A big thanks goes out to Mark Derosia for portions of this information and a few of the links related to these issues.

Update: It looks like the published links in KB articles are incorrect and point to the old Exchange 2007 RTM Rollup 4. I am waiting for updated links to the real Exchange 2007 SP1 Rollup 4.

Update 2: All references to Exchange 2007 SP1 Rollup 4 has disappeared but a workaround has been identified in the meantime, according to this link on the MS Exchange site.

[snip from MS Exchange site]
The gist of the issue is that IIS7 uses kernel mode windows authentication by default. Turning this off will fix reprompting. I will post a detailed update once I dig through some more and talk to the IIS PD, but for now I wanted to provide this update so you can give it a shot and let me know if (no, "that") it works for you.
[/snip]

Here is a crash course on how to check your current settings with AppCmd that I have been using:

Run this command on your Client Access Server role servers:
%windir%\system32\inetsrv\appcmd.exe set config /section:system.webServer/security/authentication/windowsAuthentication /useKernelMode:false

To list the current WindowsAuthentication setting for IIS7, do:
%windir%\system32\inetsrv\appcmd.exe list config /section:system.webServer/security/authentication/windowsAuthentication

To enable WindowsAuthentication on IIS7 (in case it was turned off), do:
%windir%\system32\inetsrv\appcmd.exe set config /section:system.webServer/security/authentication/windowsAuthentication /enabled:true

As time goes on and I get more Office Communications Server, Exchange 2007 UM and Cisco CallManager integration projects under my belt, the more I learn about the quirky nature of various implementations of SIP and how they interpret RFC behavior.

This problem between Exchange UM and Cisco Call Manager (CUCM) happens when you have "chained" call forwards, which causes diversion headers to be "stacked" with the trail of phone number extensions traversed.

Exchange 2007 RTM will read the bottom diversion header, and Exchange 2007 SP1 will read the top diversion header. The RTM behavior is the correct behavior when interfacing with CUCM, and most other SIP implementations, for the original caller to be identified correctly. The last diversion header contains the original phone number, which is what we want Exchange to use.

On a good note, we can take advantage of a CUCM bug that exists from version 6.0.x to 6.1.1b that will reverse the diversion header order, which works around the Exchange UM SP1 issue.

Workaround: Allow direct transfer to voicemail on the CUCM configuration and this reverses the order in which the diversion headers are sent.

(Un)fortunately, CUCM versions after 6.1.1 contain the fix CSCsl15554, which breaks this temporary workaround. CUCM 6.2 is becoming the popular standard for new deployments, with CUCM 7.x on the horizon. Microsoft is working on fix for Exchange 2007 SP1 to restore the RTM behavior.

I didn't figure out this trick/workaround. The people who are posting in this thread on TechNet are the ones who figured it out!