Although group policies are an extremely powerful security mechanism, it can be a bit tricky to deploy them in an effective manner. That’s because the effective group policy is made up of multiple and sometimes contradictory group policy elements that are applied to the user object and / or to the computer that the user is working from. It is therefore critically important that you manage your group policy objects in a way that will allow you to keep them well organized so that you can always figure out which policy elements apply in a given situation.
Further complicating things is the fact that group policy objects can be combined with other group policy objects from the local computer or from a number of different locations within the Active Directory. If you want to make things really interesting though, you can even throw in some loopback or non inheritance settings to make things really confusing.
My point in telling you all of this is to illustrate that without the proper planning, your group policy structure can easily become huge and overly complicated. It is therefore critically important that you manage your group policy objects in a way that will allow you to keep them well organized so that you can always figure out which policy elements apply in a given situation. In this article, I will share with you some best practices that you can use to keep your group policy objects well organized.
Disable Unused Group Policy Elements
One of the first things that you should do to de-clutter your group policy is to disable any unused group policy elements. There are a couple of different ways that you can do this. I recommend starting out by looking at group policy objects as a whole to see if they are really necessary. In larger organizations, it is not uncommon to need group policy objects at every level of the Active Directory, but smaller organizations can often get away with having all of their group policy settings take place at a single level within the Active Directory.
The level within the Active Directory where it makes the most sense to enforce your group policy settings depends heavily on the way that the individual organization is set up. The procedure for disabling a group policy object is almost identical regardless of which level you are doing it at. For example, suppose that you wanted to disable a site level group policy object. To do so, you would open the Active Directory Sites and Services console. Next, you would right click on the site that the policy is currently linked to and select the Properties command from the resulting shortcut menu. When you do, you will see the site’s properties sheet. If you then select the properties sheet’s Group Policy tab you will see a list of all of the group policy objects that are bound to that site, as shown in Figure A.
Figure A: The Group Policy tab displays which group policy objects are bound to the site that you have selected
OK, for this example, I said that we were going to disable the site level group policy object that’s shown in Figure A. If you look at the figure, you will notice that there is a Delete button that you could use to get rid of the policy completely. However, I recommend disabling a policy initially rather than deleting it. The reason is because, if you were to delete a group policy object and then found out that something didn’t work quite right afterwards, then it might be tricky to figure out which setting caused the problem and to fix the problem. However, if you simply disable the group policy object rather than deleting it, you can always re-enable the policy should something go wrong. Of course if everything appears to work correctly after you disable the policy, you could always delete the policy once it has been disabled for a week or so.
You might notice in Figure A that there is no disable button. If you want to disable a group policy, then you will have to select the policy that you want to disable and then click the Options button. When you do, you will see the Options dialog box that’s shown in Figure B. Now all you have to do is to select the Disabled check box and click OK.
Figure B: Select the Disabled check box and click OK
So far I have shown you how to disable an entire group policy object, but what you might not realize is that you can also disable part of a group policy object. Let’s pretend that our site level group policy shown in Figure A contains some important settings at the user level, but that it doesn’t have any computer level settings configured. That being the case, we can (and should) disable the computer settings within the policy.
Technically speaking if none of the computer level settings in the policy are configured, then it isn’t hurting anything if we leave the computer level portion of the policy enabled. However, it will increase efficiency if you go ahead and disable the computer level portion of the policy. Think about what happens when a user logs on to a domain. Windows combines all of the group policy objects that apply to the user and to the computer that the user is working from and uses these group policy objects to create the effective policy. The more group policy objects that are in effect, the longer the login process will take. If however, you disable unused portions of your group policy objects, you can speed up the login process for your users and reduce the workload on your domain controllers.
So let’s pretend that we want to disable the computer level portion of the group policy object that’s shown in Figure A. To do so, we would simply click the Properties button to access the properties sheet that’s shown in Figure C. As you can see in the figure, the properties sheet contains two check boxes that you can use to disable either the user or the computer portion of the policy. Therefore, you would select the Disable Computer Configuration Settings check box and click OK.
Figure C: Select the Disable Computer Configuration Settings check box and click OK
Override Settings
Now that I have talked about how to disable whole or partial policies, I want to discuss another best practice for group policy configuration. You might have noticed in Figure B that there was a check box labeled No Override. This is one option that I recommend using very sparingly.
As I have explained already, group policies are applied in a hierarchical fashion beginning at the local computer level then working up to the domain, site, and organizational unit levels. If a setting within a higher level policy contradicts a setting made in a lower level policy, then the higher level policy takes precedence. For example, suppose that a local computer level policy set the minimum password length to six characters and a domain level policy set the minimum password length to eight characters. Assuming that both policies were in effect, the required password length would be eight characters because the domain level policy is considered to be a higher level policy than the local policy.
What the No Override option does is prevents a higher level policy from changing anything that is set in the policy with the no override option set. The higher level policy can enforce new settings, but it can’t change existing settings. For example, let’s pretend that there are two policies in effect. A local computer policy sets a minimum password length of six characters and has the no override option set. A domain level policy sets the minimum password length to eight characters and sets the maximum password age to 30 days. The effective policy would mandate a six character password that expires every 30 days. The six character password remains in effect because the no override option is in effect. The 30 day expiration period is in effect because the lower level policy didn’t specify an expiration period, so the higher level policy isn’t overriding the lower level policy by setting an expiration period, it is merely adding to the policy.
Another group policy feature that you should use sparingly is the Block Inheritance feature. The basic idea here is that if you want to insure that a policy does not pick up settings from a lower level policy, then you can enable Block Inheritance.
In most cases, I would recommend never using the No Override or Block Inheritance features. They do have their place though. Although I have personally never tried it, I have heard other administrators talk about using No Override and Block Inheritance to help prevent group policies from interfering with the system policies used by older Windows operating systems.
Conclusion
These are just a few of the things that you can do to help make sure that your group policies stay organized and run as efficiently as possible. If there is enough interest, I might possibly write a follow up article discussing some more best practices.
