Top 10 Reasons Why Group Policy Fails to Apply (Part 1)

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 2)
• Top 10 Reasons Why Group Policy Fails to Apply (Part 3)

Introduction

Group Policy can be difficult to design, implement, and troubleshoot unless you are fully aware of the foundational concepts that drive Group Policy with Active Directory. There are many moving parts with Group Policy, not to mention the reliance that Group Policy has on Active Directory functioning properly. When making changes within a Group Policy Object (GPO) in hopes for a desired outcome, only to have Group Policy not working correctly can be very frustrating. Over the years I have developed a methodology for determining what could be causing Group Policy to fail to apply changes to computer and user accounts for which I am trying to control. I hope the following tips and guidelines can help you troubleshoot Group Policy.

1. DNS IP Address is Not Configured 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.

2. Group Policy Object (GPO) is Not Linked

Within the Group Policy Management Console (GPMC) you can create and link a GPO. The creation of a GPO is only one-half of the overall steps that need to occur in order for the settings in the GPO to take effect. The GPO must then be linked to the domain node, an OU, or a site. Once the GPO is linked to one of these AD nodes, it can then fully apply to the objects under that scope (referred to as scope of management). You can verify if the GPO is linked to the correct AD node by viewing the GPO and looking at the Links pane, shown in Figure 1.

Figure 1: The lists of links are shown for each GPO on the Links pane.

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.

Figure 2: Each GPO has two distinct sections: Computer Configuration and User Configuration.

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.

Summary

Group Policy can become frustrating and in some instances a nightmare. Knowing the basics of Group Policy and where to look when the GPO settings don’t apply will help you troubleshoot. Since Group Policy can be somewhat complicated and does rely on many other moving parts, you will need to look beyond the obvious settings in order to troubleshoot why Group Policy is not applying in your case. In this Part I article we took a look at some of the most common, yet not that obvious reasons why Group Policy might not be applying in your situation. Things to remember from this article include the fact that Group Policy relies on Kerberos and Authenticating correctly through DNS. Also, objects must be under scope of management in order to receive the GPO settings. In our next installment, we will look at the other 5 common reasons why Group Policy might not be applying correctly in your environment.

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 2)
• Top 10 Reasons Why Group Policy Fails to Apply (Part 3)