One of the primary methods of managing security in Windows 2000 is through the use of group policies. However, sometimes things can go wrong. For example, policies may accidentally overlap, not take effect, or simply not behave the way that they’re supposed to. In this article series, we’ll look at some of the things that can go wrong with group policies, I’ll explain how to fix the problem as we go along, and will add some pointers that will help you avoid such problems in the future.
Most group policy problems boil down to a policy either not behaving as expected or not taking effect at all. There are several reasons why this might be the case. Remember that Windows 2000 security works in layers. There are several different layers to which group policies can be applied. You can apply them to a local machine, a site, a domain, or to an OU (Organizational Unit). While such a structure is designed to make security easier to implement, it can actually confuse things. Not only can group policies be applied at all of these different levels, a particular policy setting at any given level can be set to be the one that takes precedence, regardless of any other settings.
So with all of this potential confusion, you may be wondering how to begin sorting out a group policy problem and how to make sure that such a problem doesn’t reoccur down the road. If you’ve got a group policy that’s not being applied correctly, the first thing that you need to do is to find out why. The easiest way to do so is to make a list of all of the group policies that are set up in your system and the level at which they reside. It’s also helpful to know if each policy is set to control users, computers or both.
Once you’ve got an idea of each existing policy’s location and intended purpose, you can begin the troubleshooting process. To do so, you’ve got to remember that group policies are applied in the following order: local, site, domain, OU. Normally, the later settings take precedence. For example, suppose that you used two contradictory group policy settings, one at the site level and one at the domain level. Because the site level is processed before the domain level, settings at the domain level would be added to any policy settings applied at the site level. Any contradictory settings would be replaced with the contents of the domain level policy. Therefore, the final group policy may still contain elements from the site level policy as long as they didn’t contradict anything in the domain group policy, but any settings that existed at the domain level would almost always be included in the final policy. I say almost, because there is a way to make a lower level policy setting take precedence over higher level settings. I’ll discuss this method in Part 2.
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.
