In Part One and Part Two of this series, we looked at some of the general methods you can use to troubleshoot a malfunctioning group policy. Now, it’s time to get into some more specific troubleshooting techniques. In this article I’ll explain some practices that I recommend using for implementing group policies. If you currently have group policies that are malfunctioning, then it may be too late to use some of these techniques. At the same time though, going ahead and implementing those which you can will often resolve the problem.
Minimize Group Policy Objects
The first technique I recommend using is to minimize the number of group policy objects that you’ve implemented. Sure, it’s possible to apply group policies at practically every layer of the Active Directory, and have those policies come together to form one comprehensive policy for the user, but that doesn’t mean that you have to do so. The more group policy objects that you combine, the better the chance that you’ll have an error or an unexpected side effect. If you absolutely must nest group policy objects, then I recommend using no more than two or three at the most. If you need a stronger reason for minimizing group policy objects then remember that each time that a user logs in, Windows must take time to process every group policy object that’s associated with the user. The more group policy objects that exist, the longer the login process will take. Of course this also means that your server will have to use more processing power just to get users logged in.
Disable Unused Portions of Group Policy Objects
By now you’ve probably figured out that group policy objects can be large and somewhat complicated. As a user logs on to the network, it must process every setting of every existing group policy object. Therefore, to significantly speed up the login process and to reduce the chances of an accidental conflict, disable every setting that you aren’t using in every group policy object. Likewise, I also recommend avoiding duplicated settings. For example, it isn’t necessary to set the minimum password length in every group policy object. I recommend setting this and other widespread policies at the highest possible level and disabling them at the lower levels. The setting will still be enforced, but you’ll save Windows from having to process a duplicate setting multiple times.
Don’t Block Policy Inheritance
Many times, when a group policy doesn’t work as expected, it’s because somewhere along the way, someone has used the Block Policy Inheritance or the No Override features. These settings prevent the group policy hierarchies from functioning in the normal manner. The Block Policy Inheritance setting prevents settings that were established in previous group policies from applying after the current policy has been processed. The No Override feature prevents a policy setting from being changed by higher level group policy objects. As you can see, both of these settings prevent group policy objects from functioning in the normal way. I strongly recommend that you avoid using these settings. If you don’t have a choice, then make sure that you document every place where you’ve used one of these options.
As you can see, there are steps that you can take to reduce the chances of a group policy malfunction. In Part 4, I’ll continue the discussion by explaining some more techniques that you can use.
Brien M. Posey is an MCSE who works as a freelance writer. His past experience includes working as the director of information systems for a national chain of health care facilities and as a network engineer for the Department of Defense. Because of the extremely high volume of e-mail that Brien receives, it’s impossible for him to respond to every message, although he does read them all.