Compartir a través de

Server says NO! - IIS Error 500 0 2148074257 across a forest trust results in Autodiscover Failures

  • Artículo

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:

 

Thanks to Steve Wesa and Kary Wall for their assistance with this issue!

Comments

  • Anonymous
    January 01, 2003
    Thank you - Very clear and helpful!

  • Anonymous
    June 05, 2013
    Great write up Kris. I like the way you list out your thought processes in the troubleshooting. Very helpful.

  • Anonymous
    October 25, 2014
    We are having the exact same problem. I was excited to read your article. Right up until the point where you gave ABSOLUTELY NO DETAILS on how you accomplished the fix. " open communication between the subset of DC's" is way to ambiguous to be useful to anyone.

    • Anonymous
      July 04, 2017
      Hi James,Unfortunately I wasn't privy to exactly what was done to accomplish the resolution. Additionally, specifics of a fix would be different depending on what type of hardware you have in your environment, your network setup, etc. The article was meant to demonstrate symptoms you could experience in a similar situation.

  • Anonymous
    April 30, 2015
    your blogs helped me alot.

    Thank you.