« Group Policy Objects 101 | Main | Fixing the ".local" Problem in Mac OS X 10.3 »
December 25, 2004
Group Policy Objects 201
There is one really important aspect of modifying Group Policy that probably needs to go in the GPO 101 post, but it's important enough that I'll post about it here.
Never, EVER modify the Default policy objects. There's a reason they're called Default, and they should stay that way.
If you need to make policy changes in a production system, are you going to "test" your policy changes fo the entire network? No, you're going to set up a test area, make the policy changes, verify that everything works as expected, and then put those changes into production. You won't achieve this by modifying the Default policy objects. What you will do is create a new GPO, link it to a test OU, link your use or computer object to that OU, and then test like crazy to make sure your policy changes aren't going to screw up anything. Once the policies are working like you want, why go and edit another policy object to add those changes? You've got a perfectly good GPO that does what you want. Just link it into the domain where you want it to apply. That's a LOT easier than going in and modifying another policy, and it will be easier to manage in the long run, too.
How so? Let's take an example from SBS-land. There are certain situations where disabling SMB signing on the SBS server is necessary. See http://simultaneouspancakes.com/Lessons/archives/2004/12/how_to_disable.shtml for detailed steps on how and why. In that document, I've detailed steps on how to create a new GPO called "Disable SMB Signing" and apply it to the domain. Now, let's suppose that when I create and apply that policy, it fixes one issue, Macs connecting to SMB shares for example, but causes problems with other workstations. If I suspect that the problem comes from SMB signing being disabled, I can go into my GP console, unlink the "Disable SMB Signing" GPO, reapply policy, and see if the problem is resolved. Much easier to locate and troubleshoot problems this way.
In fact, when you look at th GP console for SBS, you'll notice that the SBS setup has created a number of GPOs and they are named to describe the functions they perform. Even though most of the policies modified in those GPOs apply to the entire domain, changes were not made to the Default policies.
So the next time you find yourself wanting to make changes to the Default policies in your Active Directory, whether you're running SBS or not, don't edit the Defaults. Create a new GPO, link it in where necessary, and only apply the new policies AFTER you have thoroughly tested them to see what problems may result.
Posted by Q at December 25, 2004 07:47 AM