Several months ago, I wrote a series of articles about Group Policy capabilities and implementation. Judging from the response I received, Group Policy is a hot topic for a lot of us. Because most of your questions addressed migration and troubleshooting, let's discuss three helpful troubleshooting tools included in the Microsoft Windows 2000 Resource Kit. I'll also share some tips I learned from my own experience that might help you as you design your own Group Policy implementation.
Gpolmig.exe
First, let's talk about migration. Because of the differences that exist between Win2K Group Policies and Windows NT 4.0 System Policies, I recommend that you build your Group Policy Objects (GPOs) from scratch instead of migrating your existing System Policy settings. Group Policy capabilities are more extensive than System Policy capabilities, and you must apply Group Policies differently. In other words, the differences between the technologies are too great to justify a migration effort. However, if you really must perform a migration, you can use the resource kit utility gpolmig.exe, a command-line tool that lets you migrate settings from NT 4.0 System Policies to Win2K GPOs. Because of NT 4.0 and Win2K registry and setting-location differences, you need to test GPOs after the migration to verify that they're producing the desired effect.
Gpresult.exe
Most of the troubleshooting questions I've received ask why a particular Group Policy affects a particular user or computer or why a GPO isn't producing the desired results. In these situations, the resource kit utility gpresult.exe can be very useful. Gpresult.exe is a command-line utility that lets you see which GPOs you've applied to the local machine and the user who's logged on. Gpresult.exe also lets you see software you installed using Group Policy, folders you've redirected using Group Policy, IP Security (IPSec) settings, disk quota information, applied registry settings, and information about the last time you applied Group Policy. In other words, GPResult tells you not only what GPOs you've applied to the user and computer, but also what effect those GPOs have had. GPResult can accomplish in a few seconds what might otherwise take half an hour to figure out using Active Directory Users and Computers and Group Policy Editor (GPE).
If we review how you apply GPOs, we might answer many of your migration and troubleshooting questions before they arise. Remember that you apply GPOs to computer objects and user objects based on where those objects reside in the Active Directory (AD) hierarchy. When you look at a GPO in GPE, you see that it consists of Computer Configuration, which applies to computer objects, and User Configuration, which applies to user objects. If a user's user object—not the computer object representing the machine that the user logs on to—resides in the Sales Organizational Unit (OU), and you apply a GPO to the Sales OU, only the GPO's User Configuration settings will apply to that user. The Group Policy settings that apply to the computer configuration will come from the GPO that you apply (or link) to the OU that the computer object is a member of. This arrangement might seem complex, but in a large environment, it's more manageable than System Policy. You apply System Policies to groups, but a user can be a member of multiple groups, all of which can have different System Policies applied. The advantage of Group Policy's application is that a user or a computer will exist in only one AD location at a time.
Gpotool.exe
Another resource kit tool that's useful for supporting Group Policy is gpotool.exe. Client machines receive Group Policy settings from the Win2K domain controller (DC) that authenticates them. The authenticating DC stores these settings in its SYSVOL share, and its SYSVOL contents replicate to every other DC in the domain. This replication ensures that you apply the same Group Policy settings regardless of which DC performs authentication. Gpotool.exe checks to verify that replication occurs properly by comparing the GPO instances on each DC and verifying their consistencies. This step can be useful when you have to troubleshoot inconsistencies.
Some Suggestions
When you begin to realize all of Group Policy's capabilities, you might feel like the proverbial kid in the candy store. However, like that kid, you can run into problems if you try to implement too much too quickly. Instead of trying to implement a Group Policy design that accomplishes everything, start simply. For example, identify a Top 10 list of problems that your IT support group faces and design Group Policies to address those issues. Also, think as broadly as possible, identifying Group Policy settings that should apply to the vast majority of the users and computers on your network. Such thinking will help you implement a design that you can apply at the domain level with one or a few GPOs, which will simplify troubleshooting.
End of Article
Register
