Implementing Group Policy

Over the past several weeks, I have provided an overview of Group Policy and explained how you can use it for everything from distributing software to securing your network environment. Microsoft has built a tremendous amount of capability into Group Policy, and it's a technology that requires a thorough understanding and a great deal of planning before you implement it. I could spend several weeks delving deeper into Group Policy without giving it the full coverage that it warrants. Because we don't have that time, I'll conclude the series this week by focusing on some of the planning and technical issues that you need to be aware of before you get started with Group Policy.

Setting Your Priorities
The Group Policy Editor (GPE) snap-in includes several settings that you can set within a Group Policy Object (GPO). In addition to the security and software distribution capabilities we discussed last week, you can control everything from clients' desktop appearances to what logon and logoff scripts run. With all the available options, deciding what to implement in your environment can be overwhelming.

A good approach is to develop your own top 10 lists. For example, what 10 issues generate the most support calls to your Help desk, are the highest priority security risks, or cause the most lost productivity for your users? After you develop your lists, identify those issues from your lists that a proper Group Policy implementation could eliminate or greatly reduce. You might decide to limit users' access to the Run command or remove access to the Control Panel Add/Remove Programs applet. If users need access to certain directories or shared resources, you might want to use logon or startup scripts to map drives. Or, perhaps you want to configure NetMeeting and Internet Explorer (IE) settings to specify controls or disable desktop sharing from a centralized location. By focusing on the most important issues for your environment, you can design an implementation that gives you the greatest Return on Investment (ROI). Implemented in this manner, Group Policy helps build the business case for moving to Windows 2000 and Active Directory (AD).

Designing AD with Group Policy in Mind
The Group Policy settings that you apply to a user or computer are based on the user's or computer's location within the AD structure. Group Policies process in the order of site, domain, and Organizational Unit (OU). So, if you apply a Group Policy that removes the Run command from the Start menu at the site level, adds it at the domain level, and then removes it at the OU level, the Run option will disappear from the Run menu when a user logs on who is a member of the OU because that setting applies at the OU level, and it's the last Group Policy that the system applies. If you have a nested OU structure with Group Policies set at each OU level, the Group Policies process from parent to child, and the policy associated with the immediate parent OU that the user or computer object belongs to is the last one that the system applies.

By now, you should realize the importance of identifying your Group Policy objectives before you design your AD structure. If you implement your AD without considering Group Policy, you are likely to end up with a structure of unnecessary complexity that requires disruptive troubleshooting. Particularly, consider Group Policy when you design your OU structure. OUs are primarily beneficial from an administrative perspective, specifically in delegating administration and assigning Group Policy (because the Group Policy settings you apply at the OU level are, by default, the last ones that the system applies).

Group Policy and Groups
You might expect that you use group membership to assign Group Policies, when in fact you don't assign Group Policies to groups, but rather to sites, domains, and OUs. But groups do let you filter Group Policy settings, which is important. Imagine that you want to prevent users from changing configuration settings, so you create a Group Policy that limits access to the Control Panel. Such a limitation is generally a good solution, unless a user who's logged on at the time is a member of the technical support group and needs to have access to the Control Panel to resolve a problem. To avoid this situation, you can set permissions in the GPO's properties to control who in the site, domain, or OU the settings apply to. For users or computers to receive the settings you apply, they must have Read and Apply Group Policy permissions to that GPO. The authenticated users group has these permissions by default, so to prevent a specific GPO from applying to users, you have to add their group and remove the Apply Group Policy permission from them.

Group Policy is a tremendously powerful feature of Win2K. Implemented correctly, it can provide compelling justifications for moving to Win2K and AD. But implementing it correctly requires a great deal of understanding and planning. For more information, see Microsoft's Group Policy white paper at the Microsoft Web site. If you have specific questions, submit them by clicking "Respond to this article" under Reader Feedback, and I'll respond within a day or two.