In Part 1 of this article series, I explained that group policies are implemented in layers. Therefore, the key to troubleshooting group policies is to figure out which policies are being applied, which settings within those group policies are dominant, and which settings are overridden. In this installment, I’ll explain how you can begin making this determination.
Although it may sound obvious, one of the first steps that you need to take in the troubleshooting process is to consider what’s going wrong. Remember that group policies can be really big and complicated. Therefore, you can save yourself a lot of time and trouble if you initially narrow down the problem. This will keep you from having to look at unrelated portions of the group policies. For example, if the problem is that you can’t seem to enable auditing for a particular organizational unit (OU), then you can probably ignore portions of the group policies that deal with passwords.
The next step in the process is to begin documenting related settings for each group policy that exists within the system. For example, if you were having a problem with auditing not being implemented for a particular OU, you should document the audit settings, and any settings that might exist above the audit settings in the group policy console.
As mentioned, documenting these settings can be a bit tedious. To make the process easier, I recommend expanding the group policy console to show any important settings and making a screen print of it. (Be sure to label each screen print so that you’ll know which group policy level that it actually represents.)
Once you’ve got all of the group policies in order, you can look at them in the same way that Windows does. Remember that Windows normally applies group policies in the order of local, site, domain, OU. Therefore, begin by looking at the local policy (or the lowest level policy if no local policy exists). Next write down the settings as they appear at that level. Now, look at the next highest level. Remember that settings which exist in this level, but didn’t exist at the previous level will be appended to the current level. If a setting in a higher level contradicts a setting at a lower level, the lower level’s setting will be overwritten. There is one exception to this though. A setting at a lower level can be configured to override higher level settings.
I’ll explain how to check for this condition in Part 3. In that installment, we’ll also discuss some alternate troubleshooting methods that you can use if there are too many group policies to compare manually, and begin discussing some best practices for implementing group policies.
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.
