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 ).
Before troubleshooting why Group Policy isn’t being applied as expected, make sure your AD infrastructure is working properly. GPOs in a domain depend on the correct functioning of domain controllers and replication between them. We recommend that you periodically check the health of your AD domain controllers using dcdiag and the replication state using PowerShell and the repadmin tool.
If a specific policy parameter is not applied to 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.
To apply user settings to computers, you need to enable the GPO loopback processing mode (more on this below).
Also, make sure that the object you are trying to apply your GPO to is in the right computer or user’s 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).
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).
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.
As we already mentioned, each GPO has two independent sections:
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:
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 for “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).
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:
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 GPOs 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.
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.
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:
Note that when using Loopback processing with Merge mode, the policy is actually executed twice. Consider this when using Logon scripts.
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.
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:
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.
The gpresult, rsop.msc , and Windows Event Viewer are used to troubleshoot and debug Group Policy on the 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:
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:
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 to process GPOs. Check that the service is started using PowerShell:
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:
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.
