Posey's Tips & Tricks

Best Practices for Group Policy Management, Part 2: Complexity

Let's walk through what to do and what you should avoid when group policy structures get a bit complicated.

• By Brien Posey
• 03/31/2023

In the first part of this series, I discussed some various ways that you could document your group policies. Now I want to turn my attention to some strategies for creating group policy structures that are more complex. Keep in mind that none of these strategies will be suitable for every organization. My goal in writing about these techniques is to give you something to consider. It is ultimately up to you to adopt the practices that seem to be the best fit for your organization's own unique requirements.

Create Small Granular Policies
If your organization uses a complex group policy structure, then one strategy that may prove helpful is to create a series of small, granular policies. For example, an organization might create a group policy containing its Microsoft Office policy settings, another policy for browser settings and yet another policy for AppLocker settings.

This technique has its good and bad points. One of the main good points is that when used properly, this technique can reduce the administrative workload. Suppose for a moment that you have separate group policies for each department and you need to make a change to everyone's browser settings. If the browser settings are contained within the departmental policies, then you will have to make the required change in each individual policy. That would be time consuming and it carries a relatively high potential for making a mistake somewhere along the way since you would have to edit so many different policies. If, on the other hand, you have a dedicated browser settings policy, then you can change the required setting in one place instead of many.

There are a few disadvantages to using this technique. For one thing, it is somewhat inflexible. Having a dedicated browser settings policy really doesn't work if different browser settings need to be applied to different users and computers.

Another disadvantage to using this technique is that you will inevitably end up with a lot of policies that you have to maintain, thus making it a bit more challenging to make sure that policies are being applied as required.

Perhaps the biggest disadvantage to using small granular policies if that it takes quite a bit longer for Windows to apply several policies than to apply one big policy containing the same number of settings. That time difference probably won't be a big deal in a lot of organizations, but it may be problematic if you have slow, overworked domain controllers or if you have users authenticating remotely over a slow connection.

Separate User and Computer Policies
Another organizational technique that I sometimes see used is that of creating separate policies for users and for computers. Normally, a group policy contains both computer configuration settings and user configuration settings, but you can create a policy in which only computer configuration settings are used, and a separate policy in which only user configuration settings are used.

As was the case for the last technique that I discussed, one of the big disadvantages to using this approach is that you can end up with a lot of policies. If you have created a separate OU for each department and you are applying group policies at the OU level, then you will end up with two policies for each department. Hence, an organization with 10 departments will have 20 policies to manage,

Of course there are some advantages to using this technique. The biggest advantage is that it allows you to focus each policy on one specific thing -- namely users or computers. To see why this matters, let's go back to the example in which the Active Directory consists of a separate OU for each department and group policies are applied at the OU level. In such an organization, the user policies are likely to differ from one department to the next. However, there is a good chance that the computer level policy settings will be identical for most departments. Having separate policies for users and computers gives you the option of reusing a computer level policy in as many places as it may be needed, while keeping user level policies unique from one OU to the next. Of course I am just using that as an example. You can mix and match policies in whatever way makes the most sense for your organization.

Don't Block Anything
One last thing that I want to quickly mention is that regardless of how your group policies are structured, it's important to avoid blocking policy enforcement or policy inheritance unless you have no other choice. Even though Microsoft does fully support these types of policy blocking, blocking policy enforcement or inheritance makes troubleshooting difficult and its use often does more harm than good.