Changing Default Zone AAM creates 500 error

Question

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:

• https://companyintranet.company.com
• https://mysites.company.com

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?

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.