Good afternoon Dear readers and guests of the IT blog Pyatilistnik.org, last time I showed you how I made early repayment of a Sberbank mortgage and shared my life experience. Today I want to teach you how to find and diagnose the reasons why your assigned Group Policy may not be applied to a computer or user or an entire organizational unit. We will look at all the stages through which interaction with a GPO occurs. Let's look at the utilities that a system administrator whose tasks include creating and assigning policies should own. I am sure that this post will be useful and interesting to you.
Why did Microsoft's Active Directory become so popular? One of the answers to this question will be the Group Policy functionality. All administrators, like most modern people, are very lazy creatures and love when everything is centrally managed and, if possible, automated. It is GPO objects that allow you to configure tens, hundreds and thousands of computers, from one place and in almost all directions, for example, adding printers, login scripts, WiFi profiles and much more.
There are very frequent situations where the system administrator created a new group policy, applied it to the object he needed, but it did not give any effect and he needs to understand why it was not applied, and this is where novice system administrators get into trouble, not understanding where and what to look for. Below we will analyze an action algorithm that will help you find the reason and restore the operation of applying Group Policy to the desired object.
What does Group Policy (GPO) apply to?
The first thing I want to address is to answer what Group Policy does. We all know very well that the Windows operating system is a set of services and registry keys. All the settings that you see and change in graphical mode essentially change registry keys. Understanding this, we can immediately conclude:
- that there is a registry for the computer object
- and there is a registry for the user object
These two entities are the final objects in the GPO policy. In Active Directory, user and computer do not just lie there, but are located in two types of folders:
- This container is essentially a simple folder, it is important that Group Policy Objects cannot be applied to it.
- The second type is organizational units (OUs) - these are special folders for combining AD objects according to principles. It is with the OU that Group Policy Objects are associated to apply them to computers and users. Externally, the container differs from the organizational utility in that the OU has an additional tab on the icon, this is shown in the screenshot.
Algorithm for troubleshooting GPO problems
Let's say I have a Group Policy that applies to the organizational unit " Client Computers ". The policy is called "UIPI Management". For some reason, the user complains that it did not apply to him.
From the information about the scope of Group Policy, the first thing you need to pay attention to is whether the user or computer object is located in the desired path. This is easy to do, in the “Group Policy Management” snap-in, find your policy and look at which OUs it applies to, this can be seen on the “Scope” tab , it is also called the scope of the policy. In my case, this is the path root.pyatilistnik.org/Client Computers.
Since Active Directory is a hierarchical structure, one OU can be part of a tree of others and itself include a large number of organizational units. Therefore, if you have nesting, then simply going to the desired OU you may not immediately find the desired object. In this case, use Active Directory search. For example, I have a workstation from which there are complaints about the use of a GPO object. In the search, select computers in the “ Find ” field and indicate w10-cl01 in the name, then click “Find”. You will get results in the search results. We click on the desired object and go to the “Object” tab, where we look at the “ Canonical name of the object ”, essentially this is its location path in Active Directory. We compare it with what we received from the scope of group policy and draw a conclusion whether the object is subject to action or not.
Next, make sure that you have simply enabled the association of the GPO with the desired organizational unit. To do this, in the GPO management snap-in, right-click on the desired policy and in the context menu, check that the “ Communication is enabled ” checkbox is checked, you can also check it on the “Area” tab in the “Communication enabled” column, the value should be “yes” .
The next thing you need to check is that the policy is not disabled for a specific object. To do this, go to the Details on the desired GPO. We are interested in the “GPO Status” line. By default, the value is “ Enabled ,” which means that the policy will try to apply the settings specified in it to both types of objects (User and Computer). But the value can be set:
- Computer configuration settings disabled
- User configuration settings disabled
- All settings disabled - will prohibit the application of the policy for any object
This was done to speed up the application of policy to objects. Agree that if you only have changes configured for the user in your GPO, then there is no point in checking the policy for the computer. Therefore, system administrators can disable this, but they may also make a mistake by disabling the wrong object
I wrote to you above that the OU structure is hierarchical, which means that policies linked from a higher organizational unit are applied to a lower one. But if the lower-level OU has inheritance from above disabled, then it will not be able to apply this policy. It is very easy to check, find the OU you need, right-click on it and make sure that the “Block inheritance” option is not selected.
By the way, it will have a characteristic icon with an exclamation mark. This mechanism was created specifically to isolate this OU from unnecessary GPO policies.
Checking policy rights
Group Policy objects also have their own ACL (access list), which means that you can fine-tune which objects this policy applies to. In the Group Policy Management editor, select your GPO. On the “Area” tab, find the “ Security Filters ” section, it displays to which objects the policy is applied. This security filter may include objects:
- User
- Computer
- Security group
By default, the security group “Authenticated Users” is registered here . By default, this group includes all domain users and domain computers
If you have another group or individual entries set up here, then make sure that the desired object is included in this ACL . I would like to note that even if the desired object is present in the list of the security filter, this does not mean that the policy is applied to it, and the point is that in 2014 Microsoft changed the principle of reading the policy, so that in your delegated filter security, there must be a “ Domain Computers ” or “ Authenticated ” group that must have rights to read the policy. The catch is that when you remove the Authenticated Users group from the Security Filter, it is also removed from the Delegation tab.
For Group Policy settings to be applied successfully for a user, it requires that each computer account has permission to read GPO data from the domain controller. Removing the Authenticated Users group may prevent Group Policy processing for the user. add a security group "Authenticated Users" or "Domain Computers" that has at least read-only permission (https://support.microsoft.com/en-us/kb/316622)
So go to the Delegation tab and check that any of the Authenticated or Domain Computers groups are present and that you have Read permissions. If there are no groups, then add any of them. To do this, click the “Advanced” button, then add and select “Authenticated”.
Make sure the “Reading” checkbox is checked.
Immediately make sure that there are no restrictions on the object you need, in my example, this is W10-CL03. If there is, remove it.
Pay attention to the “Enterprise Domain Controllers” group; this group determines whether this policy will be replicated to other controllers or not, so if the policy is not in the SYSVOL folder on other controllers, then check the rights of this group.
Another Group Policy filtering mechanism can be WMI filters. If they are and your property does not meet its requirements, then you will not be able to apply the policy. You can see this in the appropriate section. In my example, there is a WMI filter for laptops, which will prevent the policy from being applied to desktop computers. For more information about creating WMI filters and the mechanism for checking WMI filters, read the links. Below I will show how to see on the target computer that it did not match due to GPO filtering via WMI.
Method number 1. Disabling User Account Control in Windows 10 of any edition
As I already said, this method did not help in my situation, but this does not mean that it never works at all, because the same cases may differ slightly from each other. One way or another, the first thing I recommend is to disable User Account Control, since this is the simplest thing you can do and you don’t have to go into the thicket of Windows
