In this post I will cover typical reasons why a Group Policy object (GPO) may not be applied to an organizational unit (OU), specific computer or domain user. I think this post will be useful both to newbies and IT-pros to understand the GPO operation and architecture. First, I’ll tell about possible problems of applying GPO related to the policy settings on the domain level instead of troubleshooting GPO on the clients. Almost all settings described in this post are configured using the Group Policy Management Console (GPMC.msc).
Managing GPO Scope
If a policy setting 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 your domain for object. The OU that contains your object is specified in the Object tab in the ADUC (dsa.msc) console.
It means that the target object must be located in the OU the policy is linked to (or in a nested AD container).
Security Filtering in GPO
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 PCs within its scope.
If you want to change the Security Filtering in order to apply the policy only to the members of the specific security group (or certain users/computers), remove the “Authenticated Users” from the Security Filtering list and make sure that the target object (a user or a computer) has been added to the AD group you need. Also make sure 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).
GPO WMI Filtering
You can use special WMI filters in the GPO. Thus, you can apply 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 certain IP subnet, and even laptops only, etc.
When using Group Policy WMI filtering, make sure that your WMI query is correct. It should select only the systems you need and your target computers are not excluded. You can test your WMI filter on the computers 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.
GPO Status
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 group members can change this GPO settings and whether the policy is applied to them. You can grant privileges to manage GPO from this console or using the Active Directory Delegation Wizard in ADUC. If there is an access permission “Enterprise Domain Controllers”, this policy can be replicated between Active Directory domain controllers (please note it if you have any policy replication issues between DCs). Please also note that the permissions in the Delegation tab must match the NTFS permissions assigned to the policy directory in the SYSVOL folder.
Block Inheritance and Enforcement in Group Policy Link
Inheritance is one of the main concepts of GPO. 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 have the blue exclamation mark icon in the console.
If a policy is not applied on a client, check if it belongs to 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 Scope and Order of Precedence Processing (LSDOU)
To remember the order, in which group policies are applied in the domain, remember the LSDOU abbreviation. The GPO are applied on clients in the following order.:
- Local computer policies (Local) configured in gpedit.msc (if they are set 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 policy setting from the GPO closest to the object in the AD hierarchy wins).
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 the 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.
Link Enabled Setting for GPO
Any GPO object linked to an AD organizational unit can have 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 link any time.
How to Enable GPO Loopback Processing Mode?
If you enable Loopback Processing mode, you can apply the settings from User Configuration section to a computer object. You can enable the Loopback Processing mode in the following GPO editor section: Computer Configuration -> Administrative Templates -> System -> Group Policy -> Configure user Group Policy Loopback Processing mode. For example, if you enable the policy loopback processing, set some parameters from the User Configuration section and link the policy to an OU with computer objects, these police settings will be applied to logged users.
This policy loopback processing mode has two possible values:
- Merge – first, GPO based on user location are applied to a user, and then the GPO linked to a computer are applied. In case of user and computer OU policy conflicts, the computer policy will have higher priority. In this mode, the policy will runs twice, note it when using logon scripts.
- Replace – only policies assigned to the OU containing the computer a user logged on to will be applied to the user.
Client-Side GPO Troubleshooting
You can diagnose the client-side GPO application using gpresult, rsop.msc or Windows Event Log. In the Event Viewer you can filter the events by the GroupPolicy (Microsoft-Windows-GroupPolicy) source. Do the same in Application and Services Logs -> Microsoft -> Windows -> Group Policy -> Operational.
To sum it up, I would recommend to keep your GPO structure as simple as possible and not to create unnecessary policies. Use a transparent policy naming scheme: the name should clearly tell what the GPO is for.
