Which of these are common reasons a group policy doesnt take effect correctly

In order for Group Policy to work fully, the computer that is being managed must correctly authenticate to Active Directory. The proper method to authenticate to Active Directory is through DNS. When the client receives the IP address settings from DHCP (or is hard coded with IP settings), the client goes to DNS to get a list of domain controllers for the domain. It is also through DNS that the client obtains the Kerberos information for the domain, primarily the KDC (the Kerberos Distribution Center). If the computer being managed does not go through DNS to get the domain controller information, it will not use Kerberos to authenticate and nearly all Active Directory service functions fail, including the application of Group Policy.

3. GPO Setting is For the Wrong Object Type

When you are editing a GPO there are two distinct sections for which you can edit: Computer Configuration and User Configuration (shown in Figure 2). These are very clear and separated within the Group Policy Management Editor so you can keep the settings clear in the GUI. The settings that fall under the Computer Configuration only effect computer objects under the scope of management and the settings under the User Configuration only effect user objects under the scope of management. For example, if you make a setting to the Start Menu (located under the User Configuration), but only have computer objects under scope of management of the GPO, the setting will never be seen by any user that logs on. The user objects must be located under the scope of management of the GPO to take effect.

4. GPO Setting is Not Set For Correct Value (Enabled or Disabled)

The settings in a GPO are broken down into different sections. There are Policies and Preferences at the top level, followed by even more distinct sections under each of these. It is the Administrative Templates section that I am referring to for this troubleshooting tip. Each Administrative Template setting has three main options: Not Configured, Enabled, and Disabled. (There can also be sub-settings, but these are only valid when the GPO is configured for Enabled). All of the Administrative Template settings relate to a Registry value. In order for the setting to control your target correctly, it must be set properly. These can be confusing, as sometimes setting a value to Enabled will as a result remove a setting on the target. In the same light, setting a value to Disabled might add a setting to the target. In order to ensure you have the setting configured properly, make sure you read the title of the setting and the description of the setting on the Explain tab or Help pane. Double negative settings are very confusing, but the description of the setting usually guides you through to what the setting should be. I also encourage rigorous testing of each setting to ensure that the outcome you desire is achieved.

A final note on this topic is that Not Configured is not a configuration at all. Remember, the setting you are looking at in the editor is just a view of what the setting is set to within the GPO. Not Configured is not a way to take the setting away on the target, instead it is a way to negate the GPO from affecting that Registry value on the target in any way (at least within the GPO in question). The option Not Configured will not place any value in the GPO, so at application time there is nothing to apply for that Registry value.

5. User or Computer Object is Not in Correct Organizational Unit (OU)

We mentioned the idea of scope of management above, which is key to the application of Group Policy and the settings contained within the GPO. To ensure this concept is clear, let’s look at an example. Imagine you have two top-level OUs: Finance and HR. You have two user accounts: Joe and Sally. Both user accounts are located in the Finance OU currently, which is shown in Figure 3.

Figure 3: Joe and Sally are located in the Finance OU.

A GPO is created and a Start Menu setting is configured, which is shown in Figure 4. All Start Menu settings are located under the User Configuration node in the GPO editor, so only user accounts will receive these settings. The GPO is linked to the HR OU.

Figure 4: A Start Menu setting is configured in a GPO, which is linked to the HR OU.

Both Joe and Sally logon to their computer, but the Start Menu setting in the GPO does not take effect, which should make sense. Joe’s user account is moved to the HR OU. Joe then logs off and back on resulting in the Start Menu setting to take effect. Sally, due to the fact she is in the Finance OU and out of scope of management for this GPO, still does not receive the Start Menu setting.

6. GPO Setting Is Being Controlled by GPO with Higher Precedence

Group Policy is complicated and can be exacerbated by adding a multitude of GPOs at different levels within AD. I am not saying it is not common to have GPOs at different levels in AD, just stating the fact that it can be complicated. There is a precedence of GPOs within AD, including the local GPO. Considering there can be a GPO linked to the site, the domain, and organizational units in AD, the precedence is summarized by LSDOU. Local GPO has the weakest precedence, site linked GPOs are next, domain linked GPOs are next, with OU linked GPOs having the highest precedence.

So, assume there is a GPO linked to the domain which sets the Run command off of the Start Menu to disabled, where another GPO linked to the OU level setting the same Run command to Enabled…. The GPO linked to the OU will “win” and the user in the OU where the GPO is linked will have the Run command policy set to Enabled. (The setting I am referring to is “Remove the Run command…” so the Run option off of the Start Menu will be removed.

This precedence must be evaluated for every GPO setting, as there can only be one setting take place when all GPOs and the settings are evaluated. The RSOP.msc (Resultant Set of Policies) command on the target computer will indicate which setting “won” and from which GPO it came from, which can be seen in Figure 1.

7. Security Filtering is Not Configured Correctly on GPO

As a Group Policy MVP I find that certain aspects of GPOs are more complicated than others. One of the most complicated aspects of GPOs is the concept of security filtering. Security filtering is really nothing more than the access control list (ACL) on the GPO. However, it seems more complicated due to the evolution of the setting interface, the complexity of what is listed and what a GPO can apply to, as well as the minimum requirements for the ACL to receive the settings.

First, the interface for this setting in the GPMC masks what the minimum ACL settings need to be. You can see the interface for security filtering in Figure 2. You can see it states that only the users, computers, and groups in the list can receive the GPO settings.

Figure 2: Security Filtering interface and configuration for a GPO using the GPMC.

When you add a user, computer, or group to this you are in essence adding that object to the ACL for the GPO and granting the object Read and Apply Group Policy permissions, which can be seen in Figure 3.

In order to get to the graphic shown in Figure 3, you will need to be within the GPMC, ensuring the GPO that you want to see the details for is selected. Instead of selecting the Scope tab, which is what you see in Figure 3, select the Delegation tab. The Delegation tab lists the capabilities of object defined by GPMC. You should see the Authenticated Users group on a default GPO. Now that you see the Authenticated Users group on the Delegation tab, select the Advanced button in the lower right corner. This will display the Security Settings for the GPO. Ensure you select the Authenticated Users group, which will display the same result you see in Figure 3.

Second, notice what the detail security filtering is for a GPO. That is right, it is Authenticated Users. I often get feedback from administrators that Authenticated Users ONLY includes user accounts. That is not correct. Authenticated Users includes every authenticated object to Active Directory, which would include all domain users, groups (defined and part of AD), and computers that have been joined to the domain.

Third, although the security filtering pane says that it applies to users, computers, and groups that are listed, that is not entirely true. Remember from our first article that GPOs can only apply to users and computers. When a group is listed, it is simply grouping users and/or groups instead of listing them individually. The user and/or computer must still be under scope of management in order to get the setting defined in the GPO. This means that the user and/or computer must be in the group listed on the security filtering list, plus be in the OU (if the GPO is linked to the OU), in order to get the setting defined in the GPO.

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.

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.

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.

When there are conflicting GPOS What is the order in which they are evaluated and applied?

What are 3 ways to authenticate to an LDAP server?

What can we use to determine what policies will be applied for a given machine quizlet?

What are common ways to authenticate LDAP directory queries?