Group Policy Best PracticesRob DunnSystems Administrator IIPractice Velocity

Group Policy Best Practices

The OU structure – make it easy on yourself. Review of GPO refresh cycles – when does stuff happen? Functional GPOs vs. Monolithic – single serving or all you can eat? Filtering – Don’t filter the useful stuff out of your useful GPO! Document your GPOs – if you get hit by that bus…

The OU Structure – make it meaningful Arrange your OUs (Organizational Units) in a way that allows you to

propagate settings to your users & computers quickly and efficiently If you have multiple admins, you can organize your OUs in a way

which allows delegated access for your admins without compromising security for other areas of your domain

If you are managing your computers based on physical location, you may need to consider connectivity & AD site layout (Sites and Services) when strategizing GPO deployment

Group Policy Refresh

Group Policy Refresh: When does the magic happen?

Initial Policy Processing At boot (computer policy settings) At logon (user policy settings)

Background Policy Processing Every 90 minutes +30 minute differential (by default) for clients (~5 minutes for

DCs) Network Location Awareness for VPN-connected endpoints (Windows Vista+)

Security Policy Processing Every 16 hours, regardless of whether the policy settings have changed on the DC

Three types of Group Policy refresh modes

Monolithic vs. Functional GPOs

Monolithic vs. Functional GPOs

In many cases, a few GPOs are created which contain a number of unrelated settings which apply to both computer & user objects.

Usually found in shallow OU structures (those that are only a couple OUs deep)

These are often are linked at the domain level in the AD structure (sometimes Site level) to apply to all objects indiscriminately.

Typically exhibit better operational performance than functional GPOs, but not by much.

More difficult to troubleshoot (instead of disabling the link for the GPO, you need to dig for the setting to disable)

Monolithic GPOs

Monolithic vs. Functional GPOs

These will typically have a smaller amount of settings contained within them and will follow a theme (security, desktop experience, user preferences, etc.)

Better suited for deeper nested OU structures where there is a clear separation of security & functionality for computer/user objects.

Easier to disable in cases of emergency without impacting other GPOs

Examples: WSUS Settings GPO for LaptopsComputer Lock & Screensaver Policy

Functional GPOs

Tip: Try not to use ‘Block Inheritance’ and ‘Enforce’Enforcing a GPO link at a less granular (higher in the OU structure) level in AD will override competing settings deeper in the OU tree. Use this for domain-wide settings, such as password or security policies.

Blocking GPOs at an OU will break policy inheritance from parent OUs. This can often result in having to duplicate GPO links in your AD structure. This can be difficult to troubleshoot as running diagnostic tools at the client won’t show you what GPOs were blocked.

Filtering

Filtering: Should you do it?

Filtering is the ability to set criteria that must return ‘true’ in order for the computer or user object to process the configured GPO.

This could be a member of a security group, a specific user name, or a more advanced query determining a system-level parameter from the WMI provider.

What the heck is filtering and why you should care

Filtering: Should you do it?

By default, ‘Authenticated Users’ are configured to read & apply new GPOs via basic Security Filtering (i.e. no one is denied ‘read’ or ‘apply’ permissions). ‘Authenticated Users’ consist of Computer and User objects.

You can adjust this on the ‘Scope’ tab in your Group Policy Management Console and add or remove additional security groups (and remove Authenticated Users). Note: the computer or user object needs to reside somewhere below the OU level in order for them to apply the GPO per the security group configuration.

Having a well organized OU structure where users and computers are separated due to differing security needs will help you to not rely heavily upon Security Filtering.

Security Filtering

Filtering: Should you do it?

WMI filters allow you to execute WQL (Windows Query Language) which can return information about the user or computer object. If the information returned is ‘True,’ then the GPO can process.

WMI filters are costly, performance-wise, compared to simple security filters, so use them sparingly.

Example: SELECT ProductType from Win32_OperatingSystem WHERE (ProductType="1")

If the computer evaluating the policy is a workstation, the GPO will process. If it is a server, it will not process the GPO.

WMI Filtering

Setting up a WMI Filter

Filtering: My opinionWhile extremely effective, security filtering can offer an additional layer of complexity which can make overall troubleshooting difficult if you experience unexpected results.

I tend to stay away from Security/WMI filtering as much as possible, unless there’s no other way to accomplish my objectives. If you cannot get around having a shallow OU structure but still need functional GPOs, filtering may be your only/best way to accomplish this.

If you do need to enable filtering, it is best to enable it LAST before performing your final testing with the GPO.

This is typically the #1 reason why new GPO admins will have difficulties deploying GPOs.

Bonus tip: Apply only what you needThe Details tab has a ‘GPO Status’ dropdown. This allows you to disable or enable sections of your GPO.

For example, if you your GPO is acting on Computer settings only, you can select ‘User configuration settings disabled’ to turn off this section of your GPO. This will increase overall GPO processing performance (but not by a lot).

The GPMC Layout - Details Tab

Take notes

Document in case of fire

GPOs have an under-utilized feature: The comment field. Edit your GPO, then right-click the root branch (at the top left) -> Properties

Questions?