This was an interesting issue. I had a customer who was integrating a smaller company they had recently acquired and we were in the process of getting the users from Company B onto Company A's mail system. Sounds like an easy enough task, right?
So, here's the scenario...
- Company A acquires Company B
- Company B has it's own Forest/Own Domain
- We need to get Company B's users onto Company A's Exchange servers ASAP
- Company B's client computers WILL REMAIN on Company B's domain (they are not yet ready to join the client computers to Company A's domain)
Using some of the techniques described here, we were able to get Outlook Autodiscover to correctly locate the mailboxes that had been created for these users in Company A's forest/domain. No trust was yet in place between the two domains, and while there was network connectivity between the two forests, it was a rather complex web of tunnels, firewalls, NAT's, etc. So, it was difficult to determine which paths and ports were open between servers in which forest.
Now comes the fun part :). The trust between the two forests was brought up and shortly thereafter we found that users from Forest B were having symptoms indicative of Autodiscover not working. In short, no free/busy, no ability to set out of office, and unable to autoconfigure a new Outlook profile. I found it odd that only users from Forest B were affected, and immediatly suspected the problem had something to do with the trust, but I had no proof.
IIS logs for this customer were quite large, so I began pulling one of those down while doing some testing from an Outlook client. I used the Test E-mail AutoConfiguration option from the below menu. To bring up this option, hold down the <ctrl> key while right-clicking the Outlook icon in the BOTTOM RIGHT of your screen. Click the "Test E-mail AutoConfiguration", as noted below:
Next, we uncheck the two "Guess" boxes, and I left the password option blank, like so:
Again, the client computers were connected to Forest B. Since the trust was now in place, they theoretically should be able to present their Forest B credentials while hitting Autodiscover in Forest A and get authenticated just fine. What happened instead was that the client received a 500 error, and the autodisover test errored out. A 500 error USUALLY indicates some type of server error, but again, this issue was affecting only clients in Forest B. Clients from Forest A could authenticate just fine.
A review of the IIS log clearly showed the 500 error, but it had an unusual substatus code with it. The error looked something like this:
500 0 2148074257
Turning on friendly http error messages yielded the same 500 error along with 0x80090311. This link will show you how to turn on friendly errors in IIS.
Using the err utility, similar to the one you can download from here, I translated this numerical error code into something more meaningful:
“No authority could be contacted for authentication”
Now we're getting somewhere!
If we check in IIS, we can see that the Autodiscover directory has the following authentication methods enabled:
The key in this particular case is "Windows Authentication". Since "Windows Authentication" is enabled, the clients from Forest B were attempting to pass their Windows credentials along to IIS on the CAS in Forest A. The CAS in Forest A knew that it "should" be able to authenticate these users, but for some reason it was unable to do so, and it threw the
500 0 2148074257, 0x80090311, “No authority could be contacted for authentication”
errors back at the client. At this point, Outlook simply continued with its autodiscover logic rather than trying Basic authentication.
What we wound up doing as a solution was to open communication between the subset of DC's that serviced the Exchange servers in Forest A, with DC's in Forest B. Once we did this, Integrated (NTLM in this case) authentication worked as expected and all was well.
RESOURCES:
- You can also use www.testexchangeconnectivity.com to do your testing.
- Log Parser Studio - the best way to parse unwieldly IIS logs!