SharePoint, Host Headers and Loopback Checking

Doing a SharePoint deployment for a test and staging server on the clients machine, since this is a T & S server it’s a single-server farm deployment on a Windows Server 2003 SP2 box with all the latest updates. The SharePoint installation media is a slipstreamed MOSS with SP2.

I’ve created DNS (CNAME) aliases for the main intranet, SSP and My sites web applications which all point to the SharePoint server, and I’ll be using host headers on port 80 for the respective Web Applications.

It all goes well, I’ve created the main intranet Web Application and root site collection site directory. I go to update the Master Site Directory settings in Central Administration and it barfs at the URL I’ve put in. I try and browse to it from the SharePoint machine and I get the Authentication nag prompt, eventually IE shows me the HTTP 401.1 page. The URL I’m using is the host header URL of the main intranet web application.

This is curious, I try the root site collection URL from another machine and it works fine. The clue here is that the only machine I can’t browse to the root site collection from, is the local machine itself. So a couple of Google hours later I found the answer which is explained in knowledge base article 896861.

To quote the article;

When you use the fully qualified domain name (FQDN) or a custom host header to browse a local Web site that is hosted on a computer that is running Microsoft Internet Information Services (IIS) 5.1 or IIS 6, you may receive an error message that resembles the following:

HTTP 401.1 – Unauthorized: Logon Failed

This is a by design feature which occurs on Windows Server 2003 Service Pack 1 (SP1) which includes a loopback check which causes authentication to fail when the custom host header used does not match the local computer name.

Although the knowledge base article states that it affects IIS6 when used with Windows Server 2003 SP1, I’m using IIS6 with Windows Server 2003 SP2.

The fix involves making 1 of 2 small changes in the registry, I opted for disabling the loopback check entirely.

In addition to the fix in the article I also added the following registry entry (thanks to this post here):