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.
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.
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.
Ready to start your next project with us? That’s great! Give us a call or send us an email and we will get back to you as soon as possible!