I was setting up an SSO (ADFS claims) solution on a small pilot farm (3 servers: 1 WFE, 1 APP/CA, 1 dedicated search/crawling).

The farm had already been initially configured to have 2 web applications:

Both configured to be in the Default zone.

The Trusted Identity Provider configuration went smoothly and tested fine. To complete the best practices set up, however, I wanted to provide a Windows Authenticated Web Application for crawling purposes and for best practices I wanted that WA to be in the Default zone.

I extended the web applications to sites that had Windows Authentication only enabled. I tested these and they worked as expected.

I then went in and changed the AAM mapping putting the old URLs in the intranet zone and put the new Windows authentication URLs in the Default zone (ensuring that the authentication providers matched up, of course).

Everything seemed fine for a couple of minutes, then I'd get 500 errors with no ULS log entry.

When we unextend the web applications and reset the AAMs, everything would work properly again.

Did I miss a step in configuring the AAMs?

  • did you bind the url in IIS site as well? or how your IIS bindings looks like?
    – Waqas Sarwar MVP
    Aug 20, 2018 at 14:53
  • I left them bound to the sites as created. I went back and swapped the bindings and everything seems to be working now.
    – Snowburnt
    Aug 20, 2018 at 16:47
  • Great, so issue resolved ?
    – Waqas Sarwar MVP
    Aug 20, 2018 at 16:53

1 Answer 1


We didn't change the Host header bindings on IIS since we figured the sites would create them and it wouldn't matter if they were on different IIS Sites.

Apparently they do matter.

After putting the bindings on the correct sites everything was fine.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.