EDIT 8/22/2008: Corrected a typo in a "DisabledComponents" registry key name.
It's been a while since I've been thinking of writing a blog post about various aspects of Outlook Anywhere that people...
Updated Jul 01, 2019
Version 2.0
Blog Post
I currently have a case open with MS on similar issues reported here. Everything was working fine for a month (Exchange SP1 on Win2008, with necessary hosts tweak) then one day users started getting prompted for credentials right-and-left.
MS is completely stumped, but I have narrowed it down to this specific trigger which is 100% reproducible: *IF* I have OA configured to use NTLM authentication (which was working fine for a month after initial installation) *AND* an Outlook 2007 client attempts to connect to Exchange via OA, *then* NTLM authentication in IIS *instantly* breaks for the OAB (causing random extra login prompts for all Outlook users), and if I leave things go eventually other services like autodiscover also lose their NTLM authentication and start throwing 401s. Restarting IIS instantly fixes the problem until another client attempts to use OA.
Now, the really bizarre part is that this occurs EVEN IF OA IS DISABLED. If OA is disabled *but* it "was" configured to use NTLM authentication, a client even *attempting* to use OA will cause the breakage I mention above. It seems that the handshake the client does to even TRY an OA connection, when NTLM is the configured authentication method, is what breaks things here.
My fix? I simply configured OA to use Basic authentication. Been running rock solid that way for two weeks now. Users get ONE prompt for credentials when they use OA (which is fine by me) and after that they are fine on OA. Internal users connect via TCP, don't get any login prompts, and haven't seen an extra login prompt in weeks.
Now if I could only figure out why OA takes SO LONG to time out trying TCP and falling back to HTTP!! I mean, it should be able to determine Exchange isn't there (via normal RPC over TCP) within a second or so and fall back to HTTP, right? On my system (regardless of the authentication method OA is configured to use) it takes upward of a minute to connect to Exchange :-(
Yeah, I know I could use "on fast networks connect using HTTP first, then connect using TCP/IP", but that defeats the purpose... I only want HTTP used when users aren't on the LAN.
MS is completely stumped, but I have narrowed it down to this specific trigger which is 100% reproducible: *IF* I have OA configured to use NTLM authentication (which was working fine for a month after initial installation) *AND* an Outlook 2007 client attempts to connect to Exchange via OA, *then* NTLM authentication in IIS *instantly* breaks for the OAB (causing random extra login prompts for all Outlook users), and if I leave things go eventually other services like autodiscover also lose their NTLM authentication and start throwing 401s. Restarting IIS instantly fixes the problem until another client attempts to use OA.
Now, the really bizarre part is that this occurs EVEN IF OA IS DISABLED. If OA is disabled *but* it "was" configured to use NTLM authentication, a client even *attempting* to use OA will cause the breakage I mention above. It seems that the handshake the client does to even TRY an OA connection, when NTLM is the configured authentication method, is what breaks things here.
My fix? I simply configured OA to use Basic authentication. Been running rock solid that way for two weeks now. Users get ONE prompt for credentials when they use OA (which is fine by me) and after that they are fine on OA. Internal users connect via TCP, don't get any login prompts, and haven't seen an extra login prompt in weeks.
Now if I could only figure out why OA takes SO LONG to time out trying TCP and falling back to HTTP!! I mean, it should be able to determine Exchange isn't there (via normal RPC over TCP) within a second or so and fall back to HTTP, right? On my system (regardless of the authentication method OA is configured to use) it takes upward of a minute to connect to Exchange :-(
Yeah, I know I could use "on fast networks connect using HTTP first, then connect using TCP/IP", but that defeats the purpose... I only want HTTP used when users aren't on the LAN.