In this GPO troubleshooting guide, I’ll try to tell you about the typical reasons why a certain Group Policy Object (GPO) might not apply to an organizational unit (OU) or a specific domain computer/user. I think this article will be useful for both novice and experienced AD Group Policy administrators to understand how Group Policies work and GPO architecture. The article describes potential problems with applying GPOs related to the policy settings at the domain level, as well as troubleshooting GPOs on Windows clients. Almost all settings described in the article are configured using the Group Policy Management Console (GPMC.msc).
- Managing GPO Scope
- How to Use Group Policy Security Filtering to Apply GPOs to Selected Groups?
- Group Policy GPO WMI Filtering
- Disable User or Computer Settings in Group Policy Object
- Group Policy Delegation
- Block Inheritance and Enforcement in Group Policy Link
- GPO Scopes and Policy Processing Order (LSDOU)
- Managing Enabled GPO Links
- Group Policy Loopback Processing Mode Explained
- Use the Group Policy Modelling Wizard
- Enable Group Policy Preferences Debug Logging
- Troubleshooting Applied GPOs in Windows Clients
Managing GPO Scope
If a specific policy parameter is not applied on a client, check your GPO scope. If you configure the setting in the Computer Configuration section, your Group Policy must be linked to an OU with computer objects. The same is true if you set your parameters in the User configuration section.
Also, make sure that the object you are trying to apply your GPO to is in the right computers or users AD container (OU). You can search by domain using the ADUC (dsa.msc) console. The OU in which the object is located is specified on the Object tab.
It means that the target object must be located in the OU the policy is linked to (or in a nested AD container).
How to Use Group Policy Security Filtering to Apply GPOs to Selected Groups?
Check the Security Filtering settings in your policy. By default, all new GPO objects in the domain have the permissions for the Authenticated Users group enabled. This group includes all users and computers in the domain. It means the policy will be applied to all users and computers within its scope.
In some cases, you want a specific GPO to apply only to members of a specific domain security group (or specific users/computers). To do this, you need to remove the Authenticated Users group from the security filter and add the target group or accounts to the filter.
If you have assigned a security filter to a group, make sure the object you want is a member of that AD group.
Also, check that the group you have added to the Security Filtering has Read and Apply group policy permissions with the Allow option checked in the GPO -> Delegation -> Advanced tab.
If you are using non-standard GPO security filters, check that there is no explicit prohibition on the use of GPO for target groups (Deny).
Group Policy GPO WMI Filtering
You can use special WMI filters in the GPO. This allows applying a policy to your computers based on some WMI query. For example, you can create a GPO WMI filter to apply a policy only to computers with the specific Windows version, to computers in the specific IP subnet, to laptops only, etc.
When using Group Policy WMI filtering, make sure that your WMI query is correct. It should select only the devices you need and your target computers are not excluded. You can test your WMI filter on any computer using PowerShell:
gwmi?-Query ‘select * from Win32_OperatingSystem where Version like "10.%" and ProductType="1"‘
If the query returns any data, then the WMI filter will be applied to this computer.
Disable User or Computer Settings in Group Policy Object
As we already mentioned, each GPO has two independent sections:
- Computer Configuration – settings applied to the computer;
- User Configuration – user settings.
If your GPO configures only user settings or only computer settings, you can disable the unused policy section. This will reduce GPO traffic and allow you to reduce GPO processing time on clients.
Check the GPO status in the Details tab of the policy properties in GPMC.msc. Note the value in the GPO Status drop-down list.
As you can see, 4 options are available:
- All settings disabled – all policy settings are disabled (GPO won’t apply);
- Computer configuration settings disabled – the settings only from the computer configuration of your GPO are not applied;
- User configuration settings disabled – the settings from the user configuration section are not applied;
- Enabled – all GPO settings are applied to the target AD objects (the default value).
Group Policy Delegation
The permissions configured for a policy are shown in the Delegation tab of the GPO. Here you can see which groups can change GPO settings and whether the policy is applied to them. You can grant privileges to manage GPO from this console or use the Active Directory Delegation Wizard in ADUC. If there is access permission “Enterprise Domain Controllers”, this policy can be replicated between Active Directory domain controllers (please note it if you have any GPOs replication issues between DCs). The permissions in the Delegation tab match the NTFS permissions assigned to the policy directory in the SYSVOL folder.
Inheritance is one of the main concepts of Group Policy. By default, high-level policies are applied to all nested objects in the domain hierarchy. However, an administrator can block the application of all inherited policies to the specific OU. To do it, right-click the OU in the GPMC and select Block inheritance.
The organizational units with the enabled blocked inheritance option are marked with a blue exclamation mark in the console.
If a Group Policy is not applied to a client, check if it is in the OU with the blocked inheritance option.
Please note that the domain policies with the Enforced property enabled are applied even to the OUs with the blocked inheritance setting (you can see the inherited policies applied to the container in the Group Policy Inheritance tab).
GPO Scopes and Policy Processing Order (LSDOU)
To remember the order, in which group policies are applied in the domain, remember the LSDOU abbreviation. The GPOs are applied on clients in the following order:
- Local computer policies (Local) configured in the Local GPO editor gpedit.msc console (if they are configured incorrectly, you can reset them);
- Site-level GPO (Site);
- Domain-level GPO (Domain).
- GPOs from the organizational unit level (Organizational Unit).
The latter policies have the highest priority. It means that if you enable some Windows setting on the domain level, it may be disabled by another policy on the OU level (the closest policy to the object in the AD hierarchy will win).
When using the Forced option, the policy that is standing higher in the domain hierarchy wins (for example, if the Default Domain Policy has the Forced option enabled, it will have a higher priority than any other GPO).
An administrator can also change the policy processing order using the GPMC console. To do it, select an OU and go to the Linked Group Policy Objects tab. There is a list of GPO applied to this OU with the priority shown. The policies are processed in reverse order (from bottom to top). It means that a policy with Link Order 1 will be applied last. You can change the GPO priority using arrows in the left column and move a policy up or down in the list.
Managing Enabled GPO Links
Any GPO object linked to an AD organizational unit can have the Link Enabled option turned on or off. If the link is disabled, its icon becomes gray. When the link is disabled, the policy is not applied to the clients, but the link to the GPO object is not removed from the domain hierarchy. You can enable the GPO link at any time.
Group Policy Loopback Processing Mode Explained
For example, if you apply a policy that has settings configured in the User Configuration section to an OU with computers, these settings won’t be applied to the user without using a loopback. Loopback Processing mode is enabled in Computer Configuration -> Administrative Templates -> System -> Group Policy -> Configure user Group Policy Loopback Processing mode.
This loopback processing policy has two possible modes:
- Merge – GPOs based on the user’s location are applied to the computer, and then GPOs linked to the computer are applied. If there are conflicts between the user OU and the computer OU policies, the Computer Configuration level policies will take precedence.Note that when using Loopback processing with Merge mode, the policy is actually executed twice. Consider this when using Logon scripts.
- Replace – only policies assigned to the OU containing the computer on which the user is logged on will be applied to the user.
Use the Group Policy Modelling Wizard
You can use the GPO Modeling feature in the Domain Policy Management Console (gpmc.msc). GPO modeling allows the administrator to get the resulting policies that will be applied to a specific Active Directory object.
Go to the Group Policy Modeling section and run the Group Policy Modeling Wizard.
Select the OU or specific user/computer for which you want to get the resulting policy report.
Then follow the questions of the GPO Modeling Wizard. As a result, you will receive a report (check the Details tab), which shows which policies are applied to the AD object and which are not. If a policy is applied or rejected due to a GPO filter, this will be visible in the report.
Enable Group Policy Preferences Debug Logging
In modern versions of Active Directory, there is an additional extension of Group Policy – Group Policy Preferences (GPP). GPP allows you to apply additional settings using the GP client-side extensions. For example, through GPP, you can:
- Deploy printers via GPO;
- Add users to local administrator group on a domain computer;
- Map network drives;
- Deploy registry settings;
- Copy folders and files to users’ computers;
- Etc.
To troubleshoot the Group Policy Preferences, you can use a special logging mode – Group Policy Preferences Tracing.
You can enable this mode through the parameter in the Computer Configuration -> Policies -> Administrative Templates -> System -> Group Policy -> Logging and Tracing section. There are separate logging options for different GPP parameters.
For example, I want to check how a registry parameter with proxy settings is applied via a GPO. To do this, I enable the Configure Registry preference logging and tracing option. Here you can configure the logging and debugging parameters and the log size.
After applying the policy to the client, open the C:\ProgramData\GroupPolicy\Preference\Trace\Computer.log file to get the detailed status of the GPP.
Disable this GPO option after you finish debugging GPP.
Also, keep in mind that GPP has additional Item Level Targeting options to filter when a policy is applied.
Troubleshooting Applied GPOs in Windows Clients
The gpresult, rsop.msc, and Windows Event Viewer are used to troubleshoot and debug Group Policy on a client-side. The first two tools provide the resulting set of policies that were applied on the Windows device.
To get a simple report on the GPOs applied on the computer, run the command:
gpresult /r
The command will return a list of Applied Group Policy Objects and GPOs that did not apply. The list of filtered GPOs may contain the following items:
- Not Applied (Empty) – the policy is assigned but contains no settings;
- Denied (WMI Filter) – the policy was not applied, because the WMI filter does not match this computer;
- Denied (Security) — Group Policy ACL doesn’t have permissions to apply the GPO to this object;
- Disabled (GPO) – Computer or User Configurations section disabled in GPO settings.
To get an HTML report with the resulting GPO, use the command:
gpresult /h c:\reports\gpreport.html /f
The gpresult RSoP HTMP report contains GPO errors, the processing time of certain policies and CSEs, and other useful info. This helps you understand why some GPOs processing too long. This report shows which policy settings were applied and by which specific GPOs.
The Group Policy Client (gpsvc) service must be running on Windows in order to process GPOs. Check that the service is started using PowerShell:
Get-Service gpsvc
You also need to remember how Group Policy is updated in Windows. By default, GPOs are refreshed in the background every 90 minutes + a random time offset of 0–30 minutes. However, an administrator can change this interval by using the “Set Group Policy Refresh Interval for Computers” option under Computer Configuration -> Administrative Templates -> System -> Group Policy in the GPO.
You can use Event Viewer to find GPO processing events. Filter the System log by GroupPolicy source (Microsoft-Windows-GroupPolicy). Also, take a close look at the events in the Application and Services Logs -> Microsoft -> Windows -> Group Policy -> Operational.
A few additional tips when debugging GPOs:
- When analyzing the domain password policies, keep in mind that only one domain password policy can be configured using GPMC (usually in the Default Domain Policy). Use the Fine-Grained Password Policies if you need to use separate password and account lockout policies for specific users or groups;
- I also recommend using the Microsoft AGPM (Advanced Group Policy Management) tool, which allows you to maintain versioning for GPOs and the rules for their approval;
- Use the Group Policy Central Store for ADMX templates. In this case, you won’t need to manually deploy the Group Policy admx files on all computers.
In conclusion, I will recommend keeping your GPO structure as simple as possible and not creating unnecessary policies. Use a transparent policy naming scheme. The name of the GPO should clearly indicate what it is for.
5 comments
this article is incorrect/misleading, it doesn’t talk about the 2016 change to security filtering https://support.microsoft.com/en-us/help/3163622/ms16-072-security-update-for-group-policy-june-14-2016
censoring the image is such nonsense and a needless distraction
some people who comment (see above ) are d1cks
Good works
You can enable the GPO debug logging in the registry. Create a DWORD parameter with the name GPSvcDebugLevel and the value 00030002 in the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Diagnostics:
REG ADD “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Diagnostics” /v GPSvcDebugLevel /t REG_DWORD /d 0x00030002 /f
After the restart, Group Policy Client service will record the extended debug information to the file gpsvc.log (WINDIR%\debug\usermode\gpsvc.log)
To disable debug logging, change the value of GPSvcDebugLevel to 0.