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.

GPUpdate

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.:

GPUpdate /Force /Target:Computer

GPResult

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:
GPResult /R /Scope:Computer

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:

CN=DC-01,OU=Domain Controllers,DC=gigacorp,DC=local
Last time Group Policy was applied: 8/10/2020 at 8:48:31 PM
Group Policy was applied from: DC-01.gigacorp.local
Group Policy slow link threshold: 500 kbps
Domain Name: GIGACORP
Domain Type: Windows 2008 or later

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.

Applied Group Policy Objects

-----------------------------
Default Domain Controllers Policy
Default Domain Policy
Computer Certificate Autoenroll

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.

The following GPOs were not applied because they were filtered out
-------------------------------------------------------------------
802.1x LAN Authentication
Filtering: Denied (Security)

Local Group Policy

Filtering: Not Applied (Empty)

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.

The computer is a part of the following security groups

-------------------------------------------------------
BUILTIN\Administrators
 Everyone
BUILTIN\Pre-Windows 2000 Compatible Access
BUILTIN\Users
Certificate Service DCOM Access
Windows Authorization Access Group
NT AUTHORITY\NETWORK
NT AUTHORITY\Authenticated Users
This Organization
DC-01$
Domain Controllers
NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS
Authentication authority asserted identity
Cert Publishers
Denied RODC Password Replication Group
System Mandatory Level

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:
Summary
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.