If you would like to read the other parts in this article series please go to:
- Top 10 Reasons Why Group Policy Fails to Apply (Part 1)
- Top 10 Reasons Why Group Policy Fails to Apply (Part 2)
Introduction
In our first two installments of this topic we looked at 7 reasons why Group Policy might not be working properly in your environment. Looking back at those 7 reasons exposed some key factors about Group Policy. First, Group Policy relies on proper authentication through DNS to the domain controllers, using Kerberos for the authentication protocol, scope of management, and using the correct object type for each setting in a GPO. Then, we looked at GPO precedence (LSDOU) and security filtering. In this installment, we will look at no override, block inheritance, and WMI filters.
8. Enforced (No override) is Set on GPO
By default every GPO that is configured does not have any security filtering, Enforced (No override), block inheritance, etc. However, there might be a time that someone sets up one of these features. We looked at security filtering, but now we are looking at Enforced (No override). Enforced (No override) is a setting that is imposed on a GPO, along with all of the settings in the GPO, so that any GPO with higher precedence does not “win” if there is a conflicting setting.
It is important to understand that GPO inheritance works with LSDOU (Local, site, domain, OU). Once you set No override on a GPO, this concept of precedence is negated. Enforced (No override) sets the GPO in question to not be overridden by any other GPO (by default, of course).
A good example here is to set the Default Domain Policy for Enforced (No override), so that the Password Policy settings contained within it are not trumped by a GPO at the domain for domain users or at an OU for local SAM users in computers located in the OU. You can see this is set on the Default Domain Policy in Figure 1.
Figure 1: Enforced (No override) is set for the Default Domain Policy.
There are a few things to consider when setting Enforced (No override). First, the GPO will be set to the highest precedence from the location where the GPO is linked down through the AD structure. Second, if a higher precedence GPO (such as, at an OU level in our example) is also set to Enforced (No override), it will not have higher precedence than the GPO linked higher in the AD structure. This is so an OU admin cannot set a GPO to have higher precedence than a domain admin.
9. Block Inheritance is Set on Active Directory Node
Another feature, although not suggested to use regularly, is the ability to block the inheritance of the standard Group Policy processing down through Active Directory. As has been mentioned many times in this set of articles, the LSDOU precedence is adhered to for Group Policy application and conflict resolution.
The Block Inheritance feature is one that is set on either the domain node or an organizational unit. Even though sites can have a linked GPO, the only GPO that has weaker precedence than the site linked GPO is local and local GPOs can’t be blocked with this feature.
What the feature does is block all weaker precedence GPOs associated with the level in which the Block Inheritance setting is established. So, if the Block Inheritance is set at a second level OU, all GPOs set at the domain and the top level OU would be blocked, not affecting the users and computers located in the second level OU. Only the GPOs linked to the second level OU would have any effect. Of course, if there were more levels of OUs under the second level one, these GPOs would also be effective, just not those that have weaker precedence. You can see how this affects GPOs by looking at Figure 2 and 3. Figure 2 has no Block Inheritance set, whereas Figure 3 has the setting established at the second level OU.
Figure 2: Standard GPO precedence and inheritance at the second level OU.
Figure 3: Block Inheritance is set at the second level OU.
10. WMI filter is incorrect
WMI filters are a powerful way to control which objects (users or computers) receive the settings in a GPO. The WMI filter is a stand-alone file which is linked to one or more GPOs. When the Group Policy settings from each GPO is evaluated, the WMI filter will determine if the queries included in the WMI filter come back as positive or negative. If positive, meeting the criteria in the WMI filter, then the settings in the GPO that the WMI filter is linked to will be applied.
Of course, you can see where there might be many areas in this process that the WMI filter will make the GPO appear to fail. First, if the WMI filter file is altered or deleted, but the WMI filter link remains intact, the WMI filter will not be met, thus the settings in the GPO will not apply. Next, if the WMI filter has any syntactical errors, causing the query to fail, the settings in the GPO will also fail to apply. Finally, if the query is designed wrong, or the logic for the success of the WMI query is incorrect, the GPO settings will not apply.
Only use WMI filters where there are no other options, as WMI filters have many areas where they can negate all of the settings in the GPO from applying, plus WMI filters are very slow to evaluate and apply. Even in the Item-level Targeting (ILT) located in Group Policy Preferences, use WMI filters sparingly, as within the ILT they can have issues as well.
Summary
In this series of articles we looked at ten different ways that Group Policy might fail, or at least look as if it is failing. In reality, Group Policy itself rarely fails. What typically fails is the configuration of the GPO, links, Group Policy structure, etc. which are incorrect, causing the GPO and the settings to not apply to the desired targets. I always suggest that going back to the basics and fundamentals of Group Policy will help track down where the core issues are rooted. Also, I find that core, fundamental configurations cause the majority of problems with Group Policy. As a rule of thumb, make sure you use the OU structure to deploy Group Policy settings, such that all objects in the OU receive the settings. When you attempt to alter the default permissions, application, and precedence of Group Policy, this is where issues really start to pile up. It is suggested, only in very rare situations, that you use features such as security filtering, Block Inheritance, Enforcement, and WMI filters. Staying away from these options and features will help you keep your Group Policy environment simpler, stable, and easier to troubleshoot when real problems do occur.
If you would like to read the other parts in this article series please go to:
Unless I miss it, you completely neglected my pressing question. Are Domain Controllers computers that have “joined the domain” and therefore “Authenticated Users” or are they computers that established the domain, and therefore not “Authenticated users”. I Ask because changes to the Default domain controllers policy in our environment are not applying to the domain controllers, and I noticed “Enterprise Domain Controllers” on the policy does not have “Allow Apply Group Policy” checked off, but only “Read”. Group Policy Modeling shows the increased maximum password age should be applied, but those settings do not appear under the GPO results. Also the users expiration date is not getting extended. If the security shows that “Authenticated Users” is allowed to apply the group policy, does that cover Domain controllers, and if so, why is the “Enterprise Domain controllers” item present, with “Allow Apply..” sitting in there without a check mark?
I too am interested in Rob Wilderman’s below question.
“Unless I miss it, you completely neglected my pressing question. Are Domain Controllers computers that have “joined the domain” and therefore “Authenticated Users” or are they computers that established the domain, and therefore not “Authenticated users”. I Ask because changes to the Default domain controllers policy in our environment are not applying to the domain controllers, and I noticed “Enterprise Domain Controllers” on the policy does not have “Allow Apply Group Policy” checked off, but only “Read”. Group Policy Modeling shows the increased maximum password age should be applied, but those settings do not appear under the GPO results. Also the users expiration date is not getting extended. If the security shows that “Authenticated Users” is allowed to apply the group policy, does that cover Domain controllers, and if so, why is the “Enterprise Domain controllers” item present, with “Allow Apply..” sitting in there without a check mark?”