Since starting with the Group Policy basics way back when, and learning along the way, I’ve picked up a few nuances recently in my in-depth work with Group Policy. These little quirks can seem a little counter-intuitive at first but upon understanding them, you can use the knowledge to your advantage. Unlike some previous articles that focused on a specific particular, today’s post will serve as a catch-all for some of the notes I’ve made over the past few months.
Particulars
You can see the order group policies are applied by selecting the Group Policy Inheritance tab when you click on an OU in the Group Policy Management Console. Precedence is numbered backwards. A low number is applied after a higher number, meaning it supersedes where a setting conflicts. Thus, enforced policies will be the lowest numbers.
An enforced GPO trumps an OU with Block Inheritance enabled.
Group Policies using loopback processing will not be able to apply to a user that is in an OU with inheritance blocked (unless the Group Policy is enforced, of course).
Restricted groups are additive. Whereas most policies in a GPO are replaced by the same setting being applied in a more specific GPO, using Restricted Groups compounds through the tree.
Using a Central Store for ADMX templates on SYSVOL is great for distributed, delegated management. However, it can slow down opening Administrative Templates in Group Policy Object Editor.
Starter GPOs are great tools to have and greatly speed up the process of creating like Group Policies.
Best Practice
It is considered best practice to…
- Create separate group policy objects for both User and Computer settings to ease troubleshooting
- Disable Computer or User configuration that is not in use in a GPO.
- Add Comments to the GPO’s properties to identify reasoning or any relevant information.
- Use Security Filtering to scope the Group Policy to specific computers or users. Using the deny Security properties is not encouraged because it is not shown anywhere except the Delegation tab.