- Group Policy Not Being Applied? 10 Things to Check
- Playing with Processing: Group Policy Guide for Link Manipulation
- CSE Processing Order – Know LSDOU? Learn this too!
- Top 5 Reasons Group Policy Software Installation Is Not Working
- Group Policy Preferences Not Applying? Here’s Your CheckList!
- Group Policy Not Being Applied? 10 Things to Check (Page 2)
- Troubleshooting Slow Startup or Login Times Caused by Group Policy
Group Policy is a solid tool and is very stable. Microsoft has made constant improvements to it since Windows 2000. It allows for the configuration and deployment of pretty much anything in your Active Directory environment. From deploying software to setting the default printer, it works. But when Group Policy is not being applied, we can fix it!
Microsoft has provided great guidelines and tools in order to troubleshoot. Let’s look at the top ten issues that can stop Group Policy from being applied. Be sure to check out the other articles in this series for more in-depth Group Policy troubleshooting.
Group Policy Not Being Applied? Start with the Scope
The most common issue with Group Policy is a setting not being applied. The first place to check is the Scope Tab on the Group Policy Object (GPO). If you are configuring a computer side setting, make sure the GPO is linked to the Organization Unit (OU) that contains the computer. If the GPO configures a user side setting, it needs to be linked to the OU containing the correct user.
There are certain cases where you can do some crazy linking. We will cover that in a bit. Remember, GPOs cannot be linked to an OU that just contains security groups. You can use this PowerShell script to optimize your GPO links and ensure that they are properly linked.
Next, check the security filtering. By default, a GPO is filtered to authenticated users. Make sure that the computers or users needing the policy are in a group that is specified here. Remember that domain users includes all users, domain computers includes all computer, and authenticated users includes all users and computers.
In the picture below, you can see a GPO that is scoped to authenticated users. Beginning in July of 2016, Microsoft fixed a security issue related to Group Policy processing. If you are applying a GPO to a user/security group of users, ensure that domain computers or authenticated users have the ability to read the GPO. See this guide for more information.
Some GPOs make use of WMI filters. These filters can dynamically apply GPOs based on a host of factors. You want a GPO to apply if a device is attached, use WMI. However, that WMI filter has to evaluate to True for the object processing the GPO. This means that if you have a WMI checking a user only setting, you can’t scope your GPO only to computers.
This GPO is linked to an OU named Domain Sites, applies to Authenticated Users, and doesn’t have a WMI Filter linked to it.
You can use the WMI validator to check the status of a WMI filter. If you are unsure if a WMI filter is causing an issue, check out our guide to WMI filters and Group Policy.
Time to Dive into Delegation
In order for a GPO to apply, the object (a user or a computer) will need two GPO permissions. It must have Read and Apply Group Policy. By default, an object added to the scope tab receives both of these permissions. That is why every object can apply a GPO is authenticated users is under security filtering.
However, you can configure advance deny permission on the delegation tab. These deny permissions would take precedence over any allow permissions. This feature is very useful when you want to exclude a GPO from a handful of objects but can get confusing if employed often.