Windows Server 2012 R2 introduces a number deep changes to the way that AD FS works, which means that as practitioners, we need to look for solutions to problems in new, unexpected places. For instance, in the old world, if AD FS was completely unresponsive, the first place I would look after AD FS itself would be IIS. In AD FS 2012 R2, IIS doesn’t play a role. Requests are still served by the HTTP.SYS kernel driver but we interact with it using NETSH HTTP, which connects to the driver via the User Mode HTTP Server API. IIS and other familiar components would also interact with this API previously, but they provided a friendlier layer of abstraction between an administrator and the API. Interacting with HTTP.SYS using NETSH HTTP brings a learning curve with it, particularly when it comes to understanding what is and is not controlled here. Also, there is no GUI and the security that HTTP.SYS enforces is stricter than the abstracted layer that IIS has historically opened up. This web server architecture change and other new differences add to the difficulty of tracking down problems when things don’t work as expected, as detailed in this post.