In yet another example of how picky IIS/ARR can be here is a perfect example that took a bit of figuring out. As a baseline, there was absolutely nothing special about the configuration of IIS/ARR (other than I didn’t hit the install button myself) but everything else is laid out as I’ve done before in my IIS/ARR Guide.
- Windows 2012 R2
- IIS ARR 3.0
- Fully patched server
Externally, meet, dialin and discovery services all seemed to work fine. The problem came with authenticated traffic and more specifically when the Lync Client would request a web ticket, the process would fail. So a quick trip into fiddler showed this error:
And when I clicked on the request to get more details it was as generic as you could get:
401 – Unauthorized: Access is denied due to invalid credentials.
So I decided to verify internal services were working and there were no issues present there. And I even went to my IIS/ARR server and was able to reach the website directly through IE. So I knew a problem had to be happening within the IIS/ARR instance itself. So I decided to build a new server side-by-side and see if I could reproduce the issue. The only thing different from my guide to here was the fact I didn’t do the install. After my install, I swung over the DNS records via host file and everything worked great. So it was time to find the difference between the two.
After digging from screen to screen I found this:
And there was my problem! Somehow Windows Authentication (and basic auth but less of an issue) had found it’s way onto my IIS/ARR Server. This was not on the server I manually built. I can only assume that the Web Platform Installer is putting all of these authentication methods on the server by default.
So lesson learned. Make sure that Windows Authentication is disabled (and feel free to disable basic auth as well) on your IIS/ARR box otherwise instead of passing your credentials through it’s going to try to authenticate on it’s own.