Getty Images
How IT can use the gpresult command to check GPOs
When Windows issues arise, desktop administrators can use the gpresult utility to see what Group Policy settings are in place and which ones should be applied.
It's important to know what Group Policy settings apply to a user's workstation when troubleshooting Windows issues.
Group Policy is Microsoft's Active Directory-based configuration manager. It's a simple and effective desktop administrator tool with thousands of available settings. Using Group Policy settings, IT administrators can perform tasks such as the following:
- Manage the User Account Control (UAC) feature.
- Block access to the Microsoft Store.
- Configure screen lockout times.
- Permit or deny removable media.
- Limit access to the Control Panel.
- Provide login warning banners.
- Define firewall settings.
- Deploy and manage software.
While Group Policy is a helpful tool, it can still present challenges. To determine why a Group Policy setting is -- or is not -- in place on a user's workstation, IT can use the gpresult utility.
What is gpresult?
The gpresult command displays all the Group Policy settings currently applied to the system. This lets IT confirm whether they're the correct settings and, if they're not, troubleshoot the configurations.
Group Policy settings reside in the system volume (SYSVOL) directories of each domain controller. IT administrators edit the settings using the Group Policy Management Console (GPMC), where they are organized into logical collections called Group Policy Objects (GPOs).
GPOs are linked to the domain if they should apply to all systems; sites if they should apply to specific physical locations; and organizational units (OUs) if they should apply to departments or other business units (Figure 1).
When users and computers authenticate, the domain controller sends the linked GPOs to the client system. The client system should then apply the configurations. When it doesn't, IT must begin troubleshooting.
IT should understand each available setting option when troubleshooting. GPO settings usually have the following options:
- Not configured. The configuration is not set. If an earlier-applied GPO sets this configuration, this GPO will not conflict with it.
- Enabled. The configuration is set, enabling the setting. If an earlier-applied GPO disables the setting, this GPO conflicts and will win.
- Disabled. The configuration is set, disabling the setting. If an earlier-applied GPO enables the setting, this GPO conflicts and will win.
The GPMC shows what GPOs should apply to the workstation, while the gpresult tool shows what GPOs actually apply to the system. The two tools do not always align.
Admins should use gpresult when they go directly to a user's workstation to troubleshoot why GPO settings differ from the expected configuration. The problem is usually pretty simple: A setting should be there and isn't, or it is there and shouldn't be. Either way, IT must establish which GPO defines the configuration.
Like other command-line commands, gpresult has parameters to modify its behavior, including the following:
| Parameter | Description |
/u |
Runs the command with the logged-in user's credentials. |
/p |
Defines a password for the user when using the /u parameter. |
/s |
Runs the command targeting a specific computer. |
/scope {user or computer} |
Displays the policies applied to either the user identity or the computer identity. When trying to see both, skip the /scope option. |
/h {filename} |
Outputs the results to an HTML file. |
/x {filename} |
Outputs the results to an XML file. |
/r |
Summarizes the gpresult output. |
/v |
Displays verbose output. |
/z |
Displays detailed information about the Group Policy on the system. |
/? |
Displays help with these and other parameters. |
Open the PowerShell console or the cmd.exe interface to use the command. The process for doing so varies by Windows version, but a simple search or right-clicking on Start should make it available. IT must also include an output parameter with the gpresult command.
Understanding how Group Policy precedence affects gpresult
In many cases, Group Policy problems occur due to not waiting long enough for GPOs to refresh on client systems. Another common cause is misunderstanding the order in which GPOs are applied and which settings win -- or override the others -- if there are conflicts.
Understanding precedence enables IT to interpret and use the gpresult output. The term precedence describes the order in which GPOs are applied to workstations during the login process. This hierarchy is very deliberate on Microsoft's part. The key fact is that the last GPO applied to the system wins any conflicts.
- Site. GPOs linked to the Active Directory Site are applied first.
- Domain. GPOs linked to the Active Directory Domain are applied next, overriding any conflicting Site settings.
- Parent OU. OU-linked GPOs apply next, and these override any conflicting Site or Domain settings.
- Child OU. GPOs linked to OUs nested inside other OUs are applied next. These override any conflicting settings at the Site, Domain or Parent OU levels.
OU settings, which are often set by administrators managing desktop systems, override domain settings, which are defined by domain administrators. This is because the different types of GPOs serve different purposes:
- Site GPOs should be limited to location-specific settings and usually the least-used links.
- Domain GPOs should set organization-wide, general configurations.
- OU GPOs should set department-specific, focused configurations, enabling department-level customization of settings such as software deployment, printer configurations or desktop management.
Domain administrators can enforce GPOs to override settings made at the OU level, but they should only do this when absolutely necessary.
If two or more GPOs contain conflicting settings and are linked at the same level, administrators must define a precedence order for them.
No matter what, the last GPO applied wins. Therefore, when desktop support teams troubleshoot unexpected settings, one of the most important things to figure out is which GPO was applied last. This will show which policy applied the setting, giving IT the chance to edit the policy or rearrange the precedence order to achieve the desired result.
When should desktop administrators use gpresult?
The critical use for gpresult is to discover which GPOs have been applied to the system. This lets desktop troubleshooters determine which GPO defined the setting in question. From there, admins can adjust the GPOs, changing their precedence levels or the order to apply them in.
To understand more specific scenarios in which gpresult can be useful in troubleshooting or reporting, consider the following examples.
Example 1: Features are enabled that shouldn't be
A GPO linked at the domain level enables specific UAC settings, but a GPO linked to an OU disables the features. The user is confused about their experience with the UAC.
The gpresult command lets IT determine which policies are applied to the user's system. Armed with that knowledge, admins can check the settings in the applied GPOs, looking for conflicts. It's also possible to display just the user or computer scope (Figure 2). IT should then type the following code to display settings in the computer scope.
gpresult /scope computer /r
In this case, three GPOs have been applied in the computer scope: Firewall Settings -- Dev Dept, UAC Settings -- Dev Dept and Default Domain Policy. It appears the next step is to check the UAC Settings GPO.
Example 2: Required settings don't appear
A remote location has stringent security requirements. The location is an Active Directory site, and a GPO is linked to it that manages UAC configurations. A GPO is linked to a computer's OU to define UAC settings. A system at the location does not appear to have the expected settings.
When troubleshooting this security misconfiguration, the gpresult command displays the OU-linked GPO, indicating this GPO is the source of the problem. IT can see the exact settings by adding the verbose switch. To do so, type gpresult /scope computer /v. A subset of the output shows the three UAC settings (Figure 3).
Example 3: Security audits
Security auditors have asked an admin to demonstrate exactly what security settings exist on a given workstation. Using gpresult /h audit.html, the admin can generate a detailed report in HTML or XML format that shows which settings are in place and which GPOs deliver those settings (Figure 4).
To learn more about specific settings, browse to the Applied GPO level. IT can do the same for Denied GPOs, which helps when troubleshooting permissions or filtering issues.
Suppose an admin just linked the GPO that manages UAC settings to an OU, but when they visit a workstation contained in the OU, there's no indication that the GPO is applied. The Group Policy client on the workstation only checks for new settings periodically. If the new GPO is not yet applied, the admin should consider using the gpupdate command to cause the system to check for new policies.
Using Resultant Set of Policy as an alternative to gpresult
It's also possible to gather much of this information using a GUI tool called Resultant Set of Policy (RSoP). Type rsop.msc in the Search bar to access the utility.
The utility launches and audits the system to determine the applied GPOs. The inventory takes less than a minute. Once the audit is complete, the RSoP output looks similar to the editing interface in the GPMC. From there, IT can browse through the settings (Figure 5).
The biggest practical issue with RSoP is knowing what to look for and where to find it. There are thousands of Group Policy settings, and it can be difficult to recall exactly which node houses a given configuration. After digging down to a particular setting, the console will display the Source GPO (Figure 6).
Damon Garn owns Cogspinner Coaction and provides freelance IT writing and editing services. He has written multiple CompTIA study guides, including the Linux+, Cloud Essentials+ and Server+ guides, and contributes extensively to TechTarget Editorial and CompTIA Blogs.
