What are some of the things that Group Policy object will allow you to do select all that apply?

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 many 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 specific to user accounts, like the desktop layout, start menu, and application settings.

There are thousands and thousands of settings that can be configured, and the GPO framework can easily be expanded to accommodate new settings.

The following picture shows 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 except for logon scripts which usually are 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 GPOs are identified by a GUID. For example, the GUID’s of the four GPOs 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 use 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: 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-OUs (see the next section for more details).

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 OUs, 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 helpful 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 know where it’s linked:

GPO Appliance Order

GPO appliance can be very confusing at first since many 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 its 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. 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 GPOs set with a higher link order (e.g., 3) on the same OU
• GPO’s set at a lower level OU will override GPO’s set at a higher level OU

This means the lower in your OU hierarchy you configure the GPOs, 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 GPOs below the domain object on the left-hand side are ordered alphabetically! Therefore, you must look at the Link Order on 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 GPOs 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 lower-level GPO settings can’t override settings in the GPO. This setting is usually 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-OUs). Notice that no override takes precedence over block inheritance.

Loopback processing means that user settings from GPOs affecting a computer are applied to the 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 setting is helpful 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 GPOs 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, the 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 like files and folders, Active Directory objects, registry keys, etc. The security settings of a GPO affect 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. However, 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. Again, this does not relate to GPO appliance but is a matter of GPO management.

In larger organizations, it often makes 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 OUs. 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 to accommodate your GPO design better. 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 OUs 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 to the 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

The final solution does not match the security needs for delegation of AD objects, so it should not even be considered. Instead, 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. Finally, 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. But, again, 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 complete 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 complete 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

The primary information in this section:

• Which OU your computer account is placed in (at the time of GPO appliance)
• What time the GPOs were applied
• The DC from which your computer received the GPO settings

This information is handy 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 set up is 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 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 potent 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:

Documenting GPO Settings

If you have dozens or even hundreds of GPOs, it can be challenging to get an overview of existing settings.

Luckily, the PowerShell command-lets are very powerful. With a bit of programming, you can extract any settings you like across all your GPOs.

Take a look at the following examples:

• Find GPOs with drive mapping
• Find GPOs with software installation
• Find GPOs with folder redirection
• Create your own GPO analysis scripts

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 😉

You can also manage Group Policies with the GroupPolicy module for PowerShell. Using PowerShell, you can perform tasks that are not feasible to do manually.

As an example of how to manage GPO’s with PowerShell, have a look at this article. It shows you how to quickly analyze every GPO in your domain for security filtering and custom delegation, using only PowerShell and Excel.

What are at least 4 things you can do with Group Policy?

What can be done with Group Policy?

Which of the following techniques can be used to apply GPO settings to a specific group of users in an OU?

What are the two components items to which the policy can effect to a group policy object GPO )?