Windows Group Policy Objects: Best Practice & Common Use Cases

A group policy object (GPO) is a component in a Windows environment that stores and applies system settings to user or computer accounts. Group policy objects can be linked to different areas of Active Directory, ranging from an entire domain to specific organizational units or even individual devices.

GPOs allow administrators to define global settings for Windows networks or apply specific policies to certain users and computers. Group policy plays an essential role in the central administration of computers and accounts in Active Directory, allowing organizations to set and enforce security guidelines.

Group policy objects are created and managed through the Group Policy Management Console (GPMC), a snap-in for the Windows Server Manager and Remote Server Administration Tools (RSAT). The GPMC combines all tools needed to manage group policy in one place. However, it is still possible to manage GPOs through PowerShell cmdlets such as New-GPO and Set-GPRegistryValue.

To create a new group policy object, you need to follow three basic steps:

Unlike the local Active Directory, there are no group policy objects in Azure AD. Instead, policies and device settings are managed through Microsoft Intune and the Endpoint Manager console. For organizations that use both Active Directory and Azure AD and are looking to migrate group policy settings, Microsoft offers GPO Analytics, a tool that can import GPOs to Intune automatically.

Currently, Intune does not support all settings available through local group policy objects. However, given Microsoft’s cloud first philosophy, managing settings through Mobile Device Management (MDM) and ADMX templates is the more future-proof option. For now, mixing GPOs and Intune settings can lead to some challenges. To avoid conflicts, you can use ControlPolicyConflict to determine which setting should take priority.

Group policy objects allow sysadmins to manage a variety of settings for users and computers in Active Directory. Aside from basic settings such as password policies, which are usually set through the domain-wide default GPO, there is a wide range of potential use cases for GPOs. Here are a few examples of common group policy settings.

To stop your staff from messing with Windows settings, you can restrict access to the Settings app (Control Panel) by either blocking it entirely or hiding specific elements. You can find this policy under User Configuration > Administrative Templates > Control Panel > Settings Page Visibility.

The Windows command prompt cmd.exe is a powerful tool and can cause a lot of damage in the wrong hands. Since your average employee doesn’t use cmd, many organizations choose to disable the command prompt for non-IT users. The setting is located at User Configuration > Administrative Templates > System > Prevent access to the command prompt.

Like the command prompt, PowerShell is a powerful and potentially dangerous tool that normal users don’t need access to. You can stop them from using PowerShell through the policy User Configuration > Administrative Templates > System > Don’t run specificed Windows applications. Open the setting and add the following executables to the list of blocked applications: powershell.exe, powershell_is.exe and pwsh.exe.

External storage devices such as flash drives, USB sticks or external hard drives create multiple security risks for organizations: First, your employees may accidentally bring malware into your network when they plug in personal devices. Second, external storage is often used to conduct employee data theft. You can block the use of storage media through the policy Computer Configuration > Administrative Templates > System > Removable Storage Access.

To stop others from accessing sensitive information when a staff member leaves their desk, many organizations enforce clean desk policies that include an automatic inactivity time-out for PCs. You can change this setting through Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Interactive logon: Machine inactivity limit.

Tracking system events through audit logs provides administrators with valuable data for troubleshooting and detecting security incidents. Audit logs can be enabled under Computer Configuration > Windows Settings > Security Settings > Local Policy > Audit Policy, as well as Advanced Audit Policy Configuration. Which events should be logged is a different question. In order to benefit from event tracking, your team needs to review audit logs regularly. Consequently, you should only track relevant data.

System events you should consider auditing include:

Since objects in Active Directory can be affected by multiple GPOs at once, it is important to understand how and in what order AD processes group policy objects. When Windows applies a GPO, it overwrites settings applied by previous objects. This means that whichever GPO is processed last has the highest priority.

The order in which Active Directory applies group policy is known as the LSDOU rule. This acronym stands for:

In other words: local GPOs are applied first, followed by site-specific policies, then domain-wide policies, then GPOs linked to organizational units. Remember that the last object to be processed overwrites previously applied settings, meaning GPOs linked to OUs take priority over domain-wide GPOs, which trump site GPOs, which overrule local GPOs. Of course, this rule only applies to settings that are actively covered by a group policy object. If a GPO contains no registry values for a specific topic, any prior settings remain active.

When it comes to organizational units, there are two more rules to consider: 1) If multiple GPOs are linked to the same OU, you can determine their order through the Group Policy Management Console. 2) In nested OUs, GPOs linked to child OUs take priority over parent OUs. This allows you to modify policies on deeper levels of your OU structure while using inheritance to apply general settings.

A well-designed OU structure makes applying and managing group policy a lot easier. It helps you implement any future changes and ensure that GPOs are only applied to the objects you want them to. As a general approach, you should use root-level OUs for global settings and then make modifications in nested OUs as needed. Unfortunately, there is no universal rule for which and how many organizational units you should create. Many organizations structure their OUs after different departments, locations and device types, but that is just one possible approach.

In each Active Directory deployment, there is a domain-wide GPO called Default Domain Policy. However, you should not use this object for anything other than a few basic settings such as account, password, lockout and Kerberos policy. The reason for this is that linking group policy to organizational units gives you more granular control over where it is applied and creating your own group policy objects (with limited scope and clear names) makes it easier to troubleshoot issues.

Instead of cramming every possible setting into a single object, you should create multiple GPOs to cover different topics. This way, you can give each GPO a clear name and keep track of where different settings are managed. This makes it easier to modify policy down the line and ensure that rules are applied correctly. However, don’t fall into the trap of creating a separate object for each individual rule. Instead, group similar settings together, i.e. network policy, browser policy, software policy etc.

It is possible to include computer and user settings in the same GPO, but again, splitting these policies into separate objects makes maintenance and problem solving a lot easier. By right-clicking on an object, you can disable user or computer settings under GPO Status. This allows Windows to process the object more quickly, since it knows not to check the inactive settings.

A clear and consistent naming convention is key for efficient maintenance and troubleshooting. Just by looking at a GPO’s name, you should be able to tell where it is applied, which settings it addresses and whether it contains user or computer policy. For example, you could follow a naming scheme such as “UserConfig_SoftwareSettings_ITDepartment” or “ComputerConfig_NetworkSettings_PCs”. The important part is that the every admin follows the same approach.

By creating two organizational units that contain all user accounts and all computer accounts, you can link GPOs to this root-level OU in order to apply global settings intended for every user and device in your organization. This way, you can rely on policy inheritance to ensure that the settings propagate to child OUs instead of having to create separate links for each organizational unit.

In nested OU structures, GPOs linked to child OUs are applied after parent OUs, meaning they can be used to extend or modify group policy for different parts of the AD. You can use this approach to manage exceptions or special cases, for example by moving PCs that you want to exclude from a specific policy into a child OU where a new GPO overwrites the relevant setting.

Aside from child OUs, there are a few other ways to exclude specific accounts from a group policy settings. For example, you can use the Delegation tab in the Group Policy Management Console to change the Apply Group Policy setting to Deny for an AD group.

There’s a problem, however: The fact that you blocked a GPO from applying to a specific group is not highlighted anywhere. Which means that admins would have to individually check every single GPO to see which groups or users have been excluded. Compared to a clear OU structure, this approach can get confusing fast, which is why you should avoid denying group policy, as well as blocking policy inheritance.

WMI filters can be used to ensure that GPOs are only applied to devices with specific hardware or system properties. For example, you could limit a GPO to specific versions of Windows or only devices with an internal battery such as laptops or tablets. However, keep in mind that each additional WMI filter makes processing group policy a little more complicated and time-consuming. When organizations use a lot of filters, it can slow down the Windows login process considerably. Therefore, it’s best to use WMI filters sparingly.

The easiest way to stop a GPO from being applied in a specific OU is to delete its link. Modifying or removing the GPO itself can have unintended side-effects if the object was linked in other areas of the AD or you want to re-enable those settings at a later date. Even if you’re no longer using a GPO, it can be helpful to keep it around for future reference.

The command gpresult tells you which group policy objects are being applied to an account, as well as which domain and which organizational units it is part of. This allows you to test whether your OU structure is working as intended and check for any potential issues or conflicts with policy inheritance.

Changes to group policy can lead to unintended outcomes or side-effects. To identify problems and correct mistakes, proper change management is essential: This involves documenting any modifications to group policy with details of the adjustment as well as the date it occurred. Documentation is especially important in organizations where multiple admins have to manage group policy together.

Maintaining GPO backups allows you to restore system settings to a prior, functioning state whenever an issue with group policy occurs. You can use a PowerShell script based on the Backup-GPO cmdlet to automate the creation of backups. By default, Windows puts each backup in its own folder with a randomly generated 32 bit name, so you may want to create parent folders with a more helpful label.

You now know the best practices for managing group policy, as well as how to create and link GPOs. For your GPOs to be applied correctly, however, you still need to make sure that users and devices in your network are added to the right organizational units. And that their membership is updated whenever their status changes, such as when an employee switches to a new department.

If that sounds like a lot of work, don’t worry: There’s an easy way to make sure your users are always assigned to the right groups, organizational units and IT resources. Our identity and access management solution tenfold lets you to manage users and access rights automatically across local Windows services, the Microsoft Cloud and a variety of third-party services. tenfold‘s user lifecycle management automatically creates new accounts, adds them to the correct AD groups and organizational units and adjusts their membership whenever necessary.

Automating your account and permission management through tenfold not only saves a lot of time, but also ensures that all settings are applied accurately, while following all relevant Active Directory best practices. These include:

Central permission reporting, a user-friendly self-service platform and automated access reviews: tenfold offers you a powerful IAM solution that is quick to set up and easy to operate. Thanks to our standardized plugins, a full-scale implementation of tenfold only takes a few weeks. By contrast, conventional IAM systems typically take months or years to install. Curious? Learn more by signing up for a free trial!