Group Policy Object’s or GPO’s are a great way to control what can or cannot happen on a computer. They are really designed for an active directory environment. Although, there are local policies you can use if you are on a workgroup. They must be set on each machine though. For our purposes here we will only be talking about Group Policy in an active directory environment.

Group policy is a bunch of Group Policy Objects that’s can be applied to users or computers to control various settings.  So, I think of these like a warehouse full of shelves with boxes on them.

Group policy is like a shelf with boxes, and the GPO’s are like boxes that contain a collection of policy settings. We do not have to apply all the GPO’s, but they are available in the Group Policy Management console.  We can take the ones we want and link them to OU’s and then they can apply to anything in that OU or if we have inheritance set to any sub OU’s.

GPO’s have 2 types of setting you can apply; they will be either computer or user settings. The settings available are based on templates installed on the Domain Controller. So, if you have an older server, you may not see some of the newer GPO settings. You can install the templates to make those settings available. You also update your server to a newer operating system. (Microsoft always likes that idea!) I know it sounds extreme, but it is a good idea to keep your domain controllers up to date.

Computer-related policies

specify system behavior, application settings, security settings, assigned applications, and computer startup and shutdown scripts.

User-related policies

specify system behavior, application settings, security settings, assigned and published applications, user logon and logoff scripts, and folder redirection.

NOTE: Computer-related settings override user-related settings.

Getting started with GPO’s

To get started the first thing you want to do is create a GPO. I like doing this by right clicking on the Group Policy Objects in the management console

Just select new and give it a name. When I name the GPO’s I always use computer or user – Function. This helps me to keep them organized and to easily identify what they do. This is especially true if you have a large IT team or use a managed service provider to support your servers and environment.

Here we can see that this GPO will apply settings to the computer to configure the firewall.

Once you have the GPO created you can just right click on it and edit. Then set any settings you would like. Right now, I am not going into how to set the policy settings as that is a whole other pizza pie.

After we go through and create the GPO and add the settings, we can look at how to apply the GPO. This is done through a process called linking. You will want to link your GPO to OU’s. You can do this by dragging and dropping the GPO on that OU, right clicking on the OU and link an existing GPO.  

Linking will apply that GPO to the OU and sub OU. You can of course link a GPO to multiple OU’s.

Note: Just for clarity, you can link a GPO to any “container” in active directory. Such as a site, domain, or organizational unit.  

GPO’s and where they live

GPO’s are stored per domain, but you can also link a site, domain, or organizational unit to a GPO in another trusted domain. This is generally a bad idea as it can cause performance issues.

In active directory the GPO’s are identified by a GUID, since they are part of the active directory, they will be replicated to other domain controllers in the environment. This is done using the active directory replication and file replication services.

The policy settings for a GPO are stored in 2 locations, a container and a template.

1. Group Policy container (GPC) is an Active Directory container that contains GPO properties, such as version information, GPO status, and other component settings.
2. Group Policy template (GPT) is a file system folder that includes policy data specified by .adm files, security settings, script files, and information about applications that are available for installation.

The template is what you would normally see in the sysvol folder on your domain controller. While you could store these somewhere else, why would you? Doing that would break the replication and so many people have gone into the creation of that file replication service. It would just be rude not to use it.

Policy settings from a GPO are applied only when the GPC and GPT are synchronized. So, if you rename or move the template it will break your GPO.

How they are applied

Group Policy is inherited and cumulative, and it affects all computers and users in an Active Directory container. So, when you link a GPO to the domain or OU everything under it will get the GPO. You can use security filtering to limit who is getting it, such as by using a security group.

GPOs are processed in the following order:

1. The local GPO is applied.
2. GPOs linked to sites are applied.
3. GPOs linked to domains are applied.
4. GPOs linked to organizational units are applied. For nested organizational units, GPOs linked to parent organizational units are applied before GPOs linked to child organizational units are applied.

Note: The order in which GPOs are processed is significant because when policy is applied, it overwrites policy that was applied earlier.

 By convention, computer-related policy settings override user-related policy settings.

This becomes important to remember, since you will be linking GPO’s at both the domain and OU’s. If you are having issues with a GPO not applying or having the intended effect, you will want to refer to this. You could have a GPO apply and then be overwritten by a lower level GPO. There are ways to prevent this from happening.

Prevent GPO from being overridden

If you have a GPO that you want to have applied and not have anything else change those settings, you can use the no override option. If you specify this option, policy settings in GPOs that are in lower-level Active Directory containers cannot override the policy.

For example, if you define a GPO at the domain level, and you specify the No Override option, the policies that the GPO contains apply to all organizational units in that domain. Lower-level organizational units will not override the policy applied at the domain level.

It is often useful to have a test OU where can you link GPO’s to apply to test machines. For this you would not want to have anything else applying to it. To achieve this you can block the inheritance on that OU. This will stop higher level GPO’s from applying to anything in this OU.

NOTE: Be aware that the No Override option always takes precedence over the Block inheritance option.

I hope this has helped to go over the basics of Group Policy, it can an incredibly useful tool. It can also cause a huge headache if you are not familiar with what happens behind the scenes.