So Susan posted her thoughts on how to approach managing Group Policy in SMB environments. In the post, she asked for comments and thoughts, and since I can be a bit wordy and might want to include some content that would be difficult to add in the comment space, it seemed to me like a post on the topic was in order.
First, a bit of background. I do a LOT with Group Policy. I've written the Group Policy chapters (among others) in the SBS 2003 and 2008 Unleashed books. I've given numerous user group and conference presentations on Group Policy. I'm certainly no Jeremy Moskowitz, who is pretty well recognized as one of the foremost experts in Group Policy, but I've been around the block with GP and seen how powerful it is, and how dangerous it can be. And to set the record straight, I'm pretty much in line with Jeremy's approach to GP.
My first rule of Group Policy management is simple: NEVER edit the policies named Default Domain Policy or Default Domain Controller Policy. Period. End of discussion. In an Active Directory environment, these are the core policies developed by Microsoft to get a solid, stable AD environment, and mucking around with them can cause issues. Why? Well, because there's no "undo" in Group Policy editing for starters. If you make a change to one of these objects and it has unintended consequences, like inadvertently locking EVERY object out of the domain, there's no "undo" button you can click to make things go back to the way they were before. Sure there are ways to "go back" but that involves working with backup software (assuming you can get to the backup software to run it, could be difficult to do if you're locked out of the domain), volume shadow copy (see previous point), or manually editing the gpt.ini files directly (I've done this once, and if I never have to do that again, it will be too soon). Then there's the issue that if you do go back and end up having to do a restore of a domain prior to a point where you made changes to the default policies, those changes are lost and not easily recoverable (outside of documentation, a point I will address a bit later).
My second rule of Group Policy management is also simple: test your Group Policy changes on a small subset of the domain before releasing it into production. You can't do that when editing the Default policies. Those policies apply to EVERYONE and EVERYTHING in the domain.
To address Susan's first point: "I personally will make a new separate policy when it makes sense to do so." Well, that's a *really* loaded statement. Susan is looking at the topic specifically from the viewpoint of SBS and its environment which is pre-configured with a number of Group Policy Objects that don't exist outside the SBS product arena. In non-SBS land, there are only two Group Policy Objects - the Default Domain Policy and the Default Domain Controller Policy. If you follow the reasoning of my first rule above, you're not touching either of those objects, in which case it ALWAYS makes sense to make a new separate policy.
OK, that's a bit nit-picky, but it goes back to perspective. Susan's post only calls out Group Policy in SMB, not Group Policy on SBS. But knowing Susan and knowing the environment she works in, her post was specifically referring to SBS environments, not the greater SMB environment. Because in the SMB environment, we have tools like Microsoft Windows Server 2008 Foundation Server (henceforth referred to as "Foundation server") and the new "Aurora" product which, when looking at their Active Directory Group Policy space, only have the two Default policies (repeat point about never, EVER editing the Default policies).
I think that horse has sufficiently been beaten. Now let me address Susan's post from her perspective - managing and editing policies on an SBS network. And where I take the other side of the coin from her approach, Well, in one specific case.
In the last line of her post, Susan infers that she adheres to an SMB "rule" that "you'd want to have new policies for anything that you add" to the network. So in that regard, Susan and I are of the same mindset. Given my two rules above, never editing the Default policy objects and test Group Policy changes on a small subset of the domain, we're immediately in the realm of any changes to the Group Policy environment should be in a separate, stand-alone rule. When testing. But what do you do when you're done testing?
It depends.
If you are setting up a policy that only applies to a certain set of users/workstations/etc., you're going to have a separate policy for that scenario. In other words, you're not going to create a policy and put it at the root of the domain and yet somehow set it up so it filters only to certain objects for certain contents of the GPO. Doesn't work that way. In fact, the SBS development team has, in my opinion, done an outstanding job of keeping the number of Group Policy Objects to a minimum, meaning that they've combined similar modifications or changes to a specific subset of the network into a self-contained, clearly-named GPO. And it's that approach that I follow when working with Group Policy in all of my networks, SBS-based or not. But I also treat the SBS-generated Group Policy Objects as nearly untouchable as the Default Domain Policy and Default Domain Controller Policy (which I believe should never, EVER be edited, by the way).
Why? A few reasons. One - if I modify an SBS-generated GPO, and then re-run whatever wizard actually created or updated that GPO, my changes are lost. Two - if the SBS team releases an Update Rollup that touches Group Policy, those changes could be lost. Three (and this is the one I consider the most important) - if I have to call Microsoft for support on an issue, the technician who takes the call is going to look at the Group Policy environment and assume that it has not been modified from the defaults. And that could be a nearly-fatal assumption depending on the basis for the support call. A corollary to this is if another support organization takes over support of the network - they're going to assume that the Windows SBS Client Policy (as an example) has the same content as every other SBS 2008 implementation.
So, again, Susan and I are of the same mindset in general. Don't muck around with the SBS policies. So does that mean that you should create a new GPO for every policy change you want to make on the network? No, not in my book (figuratively speaking). My third rule of Group Policy management is: combine similar policy elements into a single GPO. A corollary to that is: combine elements that apply to the same subset of objects into a single GPO. For example, I've had a frequently-accessed post about Disabling SMB Signing in SBS 2003 that provides steps to create a stand-alone GPO for the specific purpose of allowing non-Windows workstations to access SMB shares on an SBS 2003 server (or any domain controller with file shares for that matter). This is a standard object we create on our managed systems in multi-platform environments. Or environments where MFC devices want to be able to scan to a file share on a domain controller. But I digress. That object contains one and only one adjustment to the domain environment and is clearly named as to what it is. Why? Because if someone comes along to provide additional support to the network, or if that customer has to invoke the "bus contingency" (that is, should my entire organization get taken out by a bus or other calamity), someone going in and looking at Group Policy can see immediately that something different has been done and get a good idea what it is without having to open the policy itself.
If I were to have other domain-level modifications done to a network where we've modified Group Policy, I might take the approach of including those other changes in the same GPO, then changing the name from "SMB Signing Disabled" to "Domain Policy Modifications" or something equally clear that it's not one of the default policies. Why? Because it is possible to bog down a workstation during the boot or logon process if there are too many policies to process. How many is too many? That depends on the speed of the server (as the policy files have to be read off the server disk at some point), the speed of the network (so the workstation can pull the policy objects from the server), and the speed of the workstation ('nuff said), but it can happen. A typical SBS network already has a number of GPOs created, but honestly, in a typical SBS deployment, adding another 4-6 policy objects isn't going to significantly impact the performance of the server or the workstations. So, if I were adding two changes to the domain, disabling SMB signing and some other domain-level task, I would still probably create those as two separate policies and not combine them, again primarily for clarity sake. Even as well as we document the networks we support, who knows if that information is going to find its way into the right hands if we suddenly become unable to provide support for the network.
Susan says that the one exception she will make to the rule of not editing the SBS-generated GPOs is when she wants to make changes to the Windows Firewall settings on all workstations. She says if she thinks a firewall exception should have been a default (i.e., if she thinks the SBS development team failed to include a critical element in the firewall), she will put it into the default (and correct) firewall GPO. In Susan's environment where she is providing internal support for her own network and she fully controls the entire environment and is not likely to ever turn support over to an external support organization, that's within her right. I disagree with her philosophically on that point, but in her environment, it might make the most business sense. But in my opinion, for IT support organizations, even adding a firewall rule that you think should have been included with the product by default should really go into a separate GPO, if for no other reason that when someone other than you looks at the box the can see relatively quickly what has been done to GP. Is it a high risk that adding an exception to the firewall rule is going to take down the network? No, it's actually a fairly low-risk endeavor from a network impact point of view. But so is putting those changes into a separate OU.
Susan says that she's concerned about workstations processing more than one GPO that has firewall rule elements in it. There's no need for concern from a performance standpoint. The amount of time it takes to process multiple firewall rules in a single GPO isn't significantly faster than processing multiple firewall rules in multiple GPOs. She also says that she thinks it puts the workstation at greater risk by her not creating a rule set properly. Susan, dear, if you're not going to build a rule set properly, it doesn't matter if it's in a stand-alone GPO or in the SBS-generated GPO. If you're going to screw up a rule set, you're going to screw up a rule set. And honestly, I think that there's a greater risk of impacting ALL the firewall rules for the domain if you somehow really screw up adding a rule set to the existing GPO than if you create a standalone rule.
Which brings me to my final point about creating GPOs as separate objects and not rolling them in with the default objects. Let's say that you did create a bad firewall rule and it actually negatively impacted workstations on the network. It's far easier to disable the GPO that has the custom firewall rule to "fix" the problem than to go back in and edit the GPO to remove the offending element. And if you screwed up the rule when you put it in, what's to keep you from screwing it up when you try to edit or remove it from the existing GPO?
Here's how I approach GPO management in a nutshell (yes, perhaps it is about damn time, but I wanted to get the background out there):
1. I always create a new GPO and tie it to a specific set of workstations or users for testing, either through OU assignment or security restrictions.
2. After I've tested the GPO and confirmed that it works, I'll either remove the restrictions or OU assignment so that it can be applied to the full set of objects it should be applied to.
3. If, after testing, it makes sense for the GPO element to be included as part of another custom GPO that has already been tested and implemented, I'll edit that existing object, knowing full well that I can quickly disable that custom object if problems arise.
So this treatise on GPO isn't going to change Susan's mind on how she approaches doing firewall-related GPO operations for her organization. I maintain that it's better to create a separate GPO for firewall adjustments on an SBS network (not one for each firewall change, mind you, unless you have specific firewall rules for specific workstations) than to edit the SBS firewall objects. It doesn't create performance problems on the network or workstation, it falls in with the rest of the approach of doing separate GPOs for custom settings, and it's easy to turn off the rule if something does go wrong in the deployment of the object.