Print | posted on Friday, February 12, 2010 8:10 PM
Quite some time ago I posted coverage of the DisableLoopbackCheck registry key and how it impacts SharePoint. It’s amazing just how often this comes up on the Interwebz. Scarily the common advice given is to turn this feature off. And that’s bad advice. In my original post I detailed why. In a nutshell: OK in test/dev, NOT OK in Production. Yesterday my buddy Bob Fox posted a follow up, DisableLoopBackCheck? Let’s do it the right way. His post details how to configure a list of names which won’t be checked.
This is all good, but what if you have more than one box? Fiddling with the registry is no fun on a single server, never mind ten! Another buddy Gary Lapointe put together a nifty STSADM command to do this. This is also pretty cool, but as an STSADM extension its tied to the SharePoint infrastructure, and it also suffers another problem – it requires local machine administrator rights to work. What we’re really after is an automatic way to seamlessly apply the configuration.
So how would we go about doing this “properly” and in an automated fashion? After all it’s just a couple registry keys. There are a multitude of approaches (VBS, .REG, Powershell etc) but they are all actions that must be performed on each server or if not have to then be tied to an implementation.
Say we have a Farm of machines and we want to configure them all. Well it’s very very simple. We use Group Policy. I’m frequently amazed how few SharePoint administrators understand Group Policy. I often hear the response, “but we’re not using Group Policy to manage our SharePoint Servers”. I’ve got news for you, you are. A SharePoint Farm requires a Domain. Therefore your servers are managed by Group Policy! Probably not very well with the default settings mind.
So the answer is Group Policy, great! But how do we do it? Well what we really want is a custom Administrative Template, which provides us with a GUI for managing the settings centrally and applying them automatically (without requiring local admin rights on the SharePoint machines). Something like this would be just the ticket:
The trouble is we can’t do this. The BackConnectionHostNames value is Multi-String. And the ADM infrastructure doesn’t support Multi-String! You can’t hack it so it uses a regular String either. That leaves us with deploying a .REG file at start-up via Group Policy. That's a crap option because it’s a start-up script and those are evil, plus managing Multi-String values in a text file isn’t fun.
The good news is with Windows 2008 domains we can set Registry Values using Preferences, Windows Settings, but the UI is pretty awful and it’s not really the right approach.
What we really want are a couple of lines of PowerShell to configure the policy. And yes, that’s all we need! One PowerShell Script and a text file of the names you wish to exclude! That’s it!
But first we need an Organizational Unit on which to apply the Group Policy. You should be doing this already, but you can see below I have an OU called SPFarm1, that contains the two machines in that Farm:
Hopefully the picture is becoming clear now why Group Policy is so compelling. I can have multiple farms each within a different OU with different lists of hosts to ignore (along with a whole host of other configuration you may need). Sound like a good idea for your HyperV rig running dozens of test farms? I thought so!
Then we need a Group Policy on that OU. To create this we load up Group Policy Management. Expand the domain until the OU is displayed. Right click the OU and choose Create a GPO in this domain, and Link it here.
Give it a sensible name and click OK. Now we have a group policy to which we can apply configuration.
Great, now we have a Group Policy defined. If we wanted to we could edit the policy here and expand out the Computer Configuration –> Preferences -> Windows Settings -> Registry Node. But it’s not very nice and we have to drill down into the keys we are interested in and so on. This UI simply doesn’t scale that well.
Thanks to the new PowerShell cmdlets in Windows Server 2008 we can do all that in a single operation. First we need a text file with out host names, one per line. For example:
www.sharepoint.com
intranet.sharepoint.com
Save this file as c:\names.txt, then you run the following PowerShell to register the Group Policy cmdlets:
Import-module grouppolicy
This command sets disables Strict Name Checking so you can use a list of names:
Set-GPRegistryValue
-Name "SPFarm1"
-Key "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
services\LanmanServer\Parameters"
-ValueName "DisableStrictNameChecking"
-value 1
-type dword
This command adds the addresses to ignore using the text file we created above:
Set-GPRegistryValue
-Name "SPFarm1"
-Key "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
Control\Lsa\MSV1_0"
-ValueName "BackConnectionHostNames"
-value (Get-Content("c:\\names.txt"))
-type multistring
Want the whole thing as a .ps1 script you can run? just collapse them together. Of course the first PowerShell Command is only necessary the once. The second one will update your list of names. As you change your names, just change names.txt and rerun the second command. Then your SharePoint boxes are updated by Group Policy, or you can run gpupdate.exe if you are impatient.
Note: You need to restart the machines on which policy is applied once you have applied DisableStrictNameChecking for the first time.
Simple. Easy. And no disabling of a pretty reasonable security feature. That’s platform hygiene, you know it makes sense!