Not to beat a dead horse, but if you are working with SharePoint and don’t know what the title of this post relates to, you need to educate yourself. If you have not run into an issue yet, just wait, you will.

• The usual scenario is “out of the blue” you can no longer browse your SharePoint site from the server desktop, though you can browse it fine from other machines on the network. You receive an access denied page.
• Your search crawls of SharePoint content fail with Access Denied.
• You begin to experience Access Denied errors in your custom code when you migrate the code from a single server (in my case a development server) to a multi server farm. The code runs perfectly in development and the permission in Dev are IDENTICAL to Production, the only difference is that production is a multi-server farm.

Of course I stated that this happens “out of the blue”, the reality is it happens after applying any Service Pack that implements the loopback check security feature in IIS. Once the update is applied and the server rebooted a long standing security hole is plugged and the result is any or all of the above. While the issue has been around for quite some time, I still run into folks who have not encountered it and are surprised that they are hit by it.

People Who Rock

Todd Klindt blogged about this quite a while ago along with the link to the related KB 896681 with two options to solve the problem. I suppose that would have been the end of it. The problem was that the “easy way” of solving the problem (disableloopbackcheck) is not the RIGHT way to solve the problem (BackConnectionHostNames). Spence Harbar wrote a detailed post on the reasons for the security feature and the correct way to resolve the issues. He also indicates that you can control the setting with Group Policy. Great! Now I know HOW and WHY. The problem as I have watched many times during installations is that edit the registry by hand is fraught with disaster, particularly when the Administrator has unusually long fingers or a short attention span. As you create new web applications you have to remember to keep all the web servers’ registry entries up to date. This requires communication and management between Network administrators and SharePoint administrators. Enter Gary LaPoint to close the loop for good. Gary (of STSADM admin fame) wrote an STSADM command that uses a timer job to keep the registry up-to-date based on your server configuration.

Sweet!