Become a master of the GPO! Understand appliance order, security filtering, troubleshooting and every other aspect of Group Policy Objects.
This article will give you a complete understanding of GPO’s aka Microsoft Group Policy Objects.
Go directly to the topic of your interest by clicking an item in the below list. Alternatively read to the end to make sure you have a firm grip of the GPO configuration in your infrastructure.
The article covers the following topics in a structured order:
What is a GPO?
A GPO, or Group Policy Object, is an object you set up to configure your clients or servers. The benefit of using a GPO is that you can configure a large number of clients or servers centrally from one or more policies. Also, the GPO settings get re-applied every 60 – 120 minutes ensuring a consistent environment.
A GPO is structured in two main parts: Computer settings and User settings.
Computer settings contain settings that are OS specific, like the size of the event logs, user rights assignment or network settings.
User settings contain settings that are specific to user accounts, like layout of the desktop, start menu and application settings.
There are literally thousands and thousands of settings that can be configured and the GPO framework can easily be expanded to accommodate new settings.
The following picture show you the computer and user settings of a typical GPO in the Group Policy Editor:
Computer settings are applied during system boot.
User settings are applied during logon.
Most (but not all) settings get re-applied every 60 – 120 minutes.
Where Are GPO’s Stored?
GPO’s are stored partly in your Active Directory database and partly in the replicated Sysvol folder shared by domain controllers. This is just something you should know in case of troubleshooting.
In your daily management you’ll not be accessing the Active Directory objects nor the Sysvol folders directly, perhaps with the exception of logon scripts which are normally placed manually in the Sysvol folder together with the GPO files.
In case of advanced troubleshooting of GPO consistency, the AD objects can be found in Domain\System\Policies:
And the GPO files and folders can be found in \\[Domain]\Sysvol\[Domain]\Policies:
You’ll notice that GPO’s are identified by a GUID. The GUID’s of the four GPO’s in my simple test setup can be seen in both AD and the Sysvol share in the above screenshots.
How To Configure a GPO
To create, edit and delete GPO’s you’ll typically be using the Group Policy Management Console (GPMC). GPMC is available by default on domain controllers but it can also be installed on servers using the Install-WindowsFeature command. On clients you need to install RSAT to manage GPO’s via the GPMC tool.
When you open up the GPMC tool you’ll be able to see the OU structure of your domain which makes good sense: In order to apply a group policy you must link it with an OU. Once the GPO is linked it will start applying to the users and/or clients in the linked OU and any sub OU’s (see the next section for more details on this).
To create a new GPO right click the OU where you want to link it and select “Create a GPO in this domain, and Link it here…”:
This will create a new GPO object which you can then open up and configure with the desired settings:
Notice that this action will create two things: The GPO itself and the GPO link which ensures the GPO is applied to users and/or computers in the OU (and sub-OU’s). It makes a big difference if you delete the GPO link or the GPO itself so make sure you understand the difference!
A GPO can be linked to multiple OU’s and editing the GPO will affect all GPO links!
A GPO can also be linked to a site object. This feature is not used very often but may be useful when you want to configure devices according to their network location.
At the bottom section of the GPMC tool you’ll find an overview of all the GPO’s in the domain. This is the place to look for a specific GPO if you don’t really know where it’s linked:
GPO Appliance Order
GPO appliance can be very confusing at first since a lot of configurations contribute to the final result of your GPO appliance order. We often see seasoned admins make mistakes in this area.
First of all:
Computer objects in AD receive computer settings (only) from GPO’s which are linked to the computer’s OU or parent OU’s.
User objects in AD receive user settings (only) from GPO’s which are linked to the user’s OU or parent OU’s.
Exceptions to this rule exist! Please read the entire section carefully!
A GPO can have it’s computer settings or user settings disabled. Use this to speed up GPO processing on clients by disabling the computer settings of GPO’s that only hold user settings, vice versa. Disabling both computer and user settings will effectively disable the GPO.
Since multiple GPO’s can have conflicting settings and since even computer and user settings can sometimes configure the same setting, an important question arises:
What are the effective settings applied in the case of multiple, conflicting GPO’s?
First of all, you should avoid configuring conflicting settings in your GPO’s. But nevertheless these are the “basic” rules of GPO appliance:
- GPO’s set with a lower link order (e.g. 1) on the same OU will override GPO’s set with a higher link order (eg. 3) on the same OU
- GPO’s set at a lower level OU will override GPO’s set at a higher level OU
This basically means, the lower in your OU hierarchy you configure the GPO’s the more dominant they are (as they get applied last, thereby overwriting previously applied settings).
In the below example, the GPO with the highest link order will win over any conflicting settings in lower link order GPO’s:
Note! The order of the GPO’s below the domain object in the left-hand side are simply ordered alphabetically! You must look at the Link Order in the right-hand side.
In the below example, the GPO linked to the lower level OU (“Desktop Configuration”) will win over any conflicting settings in GPO’s linked on a higher level (closer to the domain object):
In addition to this, in the case of conflicting user and computer settings you should understand the following:
- GPO computer settings get applied during system boot
- GPO user settings get applied at user logon
Therefore, user settings will override any conflicting computer settings (as they get applied last).
To complicate things even further, the GPO appliance can be modified with the following:
- Link disabled
- No override
- Block inheritance
- Loopback processing
- WMI filtering
- Security filtering
Link disabled is when you disable the GPO link. The GPO is linked to the OU, but the link is disabled. In that case nothing get’s applied from the GPO. This is primarily used during testing.
No override means that settings in the GPO can’t be overridden by lower level GPO settings. This is normally used to keep lower level administrators from overriding enterprise settings.
Block inheritance is a feature of OU’s (not GPO’s) and ensures that GPO’s set at higher level OU’s are not applied to the computer or user objects in the OU (or sub-OU’s). Notice that no override takes precedence over block inheritance.
Loopback processing means that user settings from GPO’s affecting a computer gets applied to the computer object (normally only computer settings affect computers). Loopback processing comes in two flavors: Replace and Merge:
- With Replace the user settings from the GPO’s affecting the user object are skipped entirely. This is useful in e.g. a terminal server environment where you don’t want random user GPO’s to mess up your terminal server.
- With Merge the user settings from the GPO’s affecting the user are processed on top of the user settings from the GPO’s affecting the computer.
WMI filtering allows you to filter your targets with a WMI filter. A WMI filter can query anything in WMI e.g. operating system version, bios version, disk size, hardware type, etc. WMI filters are defined in the WMI Filters section in GPMC and once defined they can be added to your group policy in the scope tab of the policy.
Finally, GPO appliance can be modified by security filtering which is covered in the next section.
GPO Security Filtering and Delegation
Group Policy Objects are securable objects just like files and folders, Active Directory objects, registry keys, etc. The security settings of a GPO affects how it’s applied to users and computers.
To receive the settings from a GPO a computer or user must have Read and Apply rights on the GPO. If they don’t have both Read and Apply rights the GPO will not be applied.
This might not be something you notice initially as Authenticated Users are assigned Read and Apply by default. As both domain users and domain computers belong to this group the GPO is applied indiscriminately to all of them.
But sometimes you may want to restrict the GPO appliance to a single user or computer, e.g. during testing of a new GPO.
This is achieved either by removing the Apply permission from Authenticated Users or removing Authenticated Users entirely from the GPO’s ACL:
… And then assigning Read and Apply manually to the user or computer you use for testing:
This method is referred to as security filtering. It’s mainly used for testing and when you have a sub-optimal correspondence between your OU design and GPO appliance needs. Check the next section for more information regarding this.
Another reason to change your GPO ACL is delegation. This does not relate to GPO appliance but is a matter of GPO management.
In larger organizations it often make sense to delegate the administration of GPO’s to local teams. This can be done by assigning Write permissions to the GPO:
This will allow you to provision blank GPO’s and then delegate the configuration of the GPO to local teams. If needed you can also assign the right to modify the GPO ACL to allow them to set up security filtering for testing purposes.
GPO and OU Design
GPO assignment is closely linked with your OU design since GPO’s are linked to OU’s. But sometimes your OU structure may have a poor match with your GPO assignment needs. It may be tempting to modify your OU structure a bit in order to better accommodate your GPO design. Don’t fall for this!
The OU structure should be designed based on your needs to delegate administrative access to Active Directory objects – NOT your GPO assignment needs!
Let’s say you have a geographically based OU design to allow country admins to have some autonomy when managing local users and computers. E.g. you have country OU’s with sub-OU’s named by departments.
But now you have a GPO with enterprise settings that you want to assign to all marketing users in the organization. You have a few options now:
- The good: Use security filtering (as described in the previous section) to target all Marketing users and link it on top level
- The bad: Link the GPO with the marketing OU in all countries Marketing OU’s (that’s a lot of linking!)
- The ugly: Create a single OU with all marketing users
Obviously the last solution does not match the security needs for delegation of AD objects so it should not even be considered. The need for delegation of AD objects should be your prime concern when designing our OU structure.
Pro-tip! Use Dynamic Groups to easily organize users and computers based on OU placement and/or AD object attributes. Then perform security filtering on relevant GPO’s using the dynamic groups. This will allow you to manage your GPO’s simply by setting correct properties on your AD objects. Use our free tool (yes, completely free) to manage your AD like a true pro!
Troubleshooting GPO Appliance
Obviously, with all the complexity associated with GPO processing, eventually you’ll encounter a situation where computers don’t seem to reflect your GPO settings. There are different methods and tools to troubleshoot this.
You can trigger GPO processing on your system using the GPUpdate command. Use the /Force parameter to ensure full processing and limit the scope with the /Target parameter, e.g.:
On clients the number one tool for troubleshooting GPO appliance is the GPResult command. It takes various parameters of which the most commonly used are /R and /Scope.
As an example, the following command will show you GPO appliance information related (only) to computer settings:
Replace Computer with User to only get GPO info for user settings. Leave out the /Scope parameter entirely for full information.
The output from the above command has various sections of information. Each section provides valuable information for troubleshooting your GPO processing.
Let’s have a look at the different sections and what information it provides:
Main information in this section:
- Which OU your computer account is placed in (at the time of GPO appliance)
- What time the GPO’s were applied
- The DC from which your computer received the GPO settings
This information is particularly useful if your computer account was recently moved from one OU to another and the new settings are not applying.
The information here is a list of GPO’s that were applied to your system. Obviously very important to understand if you’re receiving settings from the GPO’s you expect.
Here you see a list of GPO’s that were not applied due to security filtering. This lets you confirm if the security filtering you have setup is actually working.
And finally, a list of the security groups of which your computer is a member. This information can help you troubleshoot situations where security filtering is not working.
Double check if your computer is actually a member of the group you’re using in your security filter. If the group is not there, investigate if any recent change in group membership has replicated to the DC from which you received the GPO.
Resultant Set of Policies
Another very powerful tool to troubleshoot GPO appliance is the Resultant Set of Policies (RSoP) tool. RSoP allows you to collect the GPO processing information from a remote system and is part of the GPMC tool:
Right click Group Policy Results and select Group Policy Results Wizard. Then click Next and select the remote system you want to analyze:
Select the user for which you want to collect GPO information – or select no user if you’re only investigating computer settings:
The RSoP tool will give you all the information we saw from the GPResult tool in the Summary tab. Things get even more interesting when you click the Details tab. Here you find a list of all settings applied from the GPO’s. Expand any section to view details about what was applied and which GPO the setting came from:
I hope this article helped you remove some confusion about GPO processing.
With security filtering you can easily test any new GPO’s without affecting live users and systems.
Complete your GPO security filtering with the use of Dynamic Groups. Our free tool will allow you to automate your setup based on user and computer attributes.
Using GPResult on the client or RSoP server side you can quickly troubleshoot GPO errors and become the hero of the day 😉
Group Policies can also be managed with the GroupPolicy module for PowerShell. Using PowerShell you can perform tasks that are not feasible doing manually.
As an example on how to manage GPO’s with PowerShell have a look at this article. It shows you how to quickly analyze every single GPO in your domain for security filtering and custom delegation, using only PowerShell and Excel.