Group Policy - 09 Feb 2000

Lowering Windows 2000's TCO

Microsoft cites total cost of ownership (TCO) as one of the reasons why you need to upgrade to Windows 2000 (Win2K). TCO goes beyond a computer's purchase price to encompass many other costs, such as the ongoing cost of supporting the computer and the user. Anyone who has worked at a Help desk knows that if you set up policies to prevent users from making unauthorized changes to their systems, you can prevent some problems that would otherwise affect productivity and require expert help to resolve. In Windows NT 4.0, system policies are little more than shell modifications that knowledgeable users can easily circumvent. In Win2K, however, Microsoft has extended the system policy concept significantly. Let's examine Group Policy—specifically, how it works within the Active Directory (AD) model.

What Is Group Policy?
Win2K's Group Policy isn't simply a written guideline, such as a warning to prevent users from installing unauthorized software. Group Policy is a set of rules that Win2K implements, using Registry changes, when a computer starts or when a user logs on. The policies become part of the user environment, imposing restrictions on what the user can and can't do.

What can you do with Group Policy? Let's start at the beginning. You can run a startup script for a computer. This computer-specific script differs from a user logon script. Of course, you can also run user logon scripts, and Win2K lets you run scripts when the user logs off or when the computer shuts down. You can configure a user's desktop by removing or restricting the options to run applications, connect on the network, or even choose wallpaper. You can also use Group Policy to set security restrictions and control access to network resources.

Setting the Security Policy
You can set security policies at different levels in the AD structure. Policies that you set at a high level in the directory tree, for example, can flow down to lower levels such as organizational units (OUs). Optionally, you can modify or override policies at a lower level. Group Policy now controls software distribution, limiting applications to certain clients or computers.

Win2K doesn't use NT's ntconfig.pol file, which NT needed to replicate to the backup domain controllers. Instead, you create a Group Policy Object (GPO). A GPO is a virtual storage location for your policies. You can place different policies in different GPOs, and you can apply each GPO to selected users or computers. (You apply GPOs to only users or computers, but you can also filter the effects of GPOs by groups.) Replication of the policies occurs under the control of the Windows 2000 File Replication Service (FRS). You can associate one GPO with many AD containers, and each AD container can have multiple GPOs associated with it.

Win2K stores Group Policy information in two locations: the Group Policy Container (GPC) and the Group Policy Template (GPT). The GPC is the AD object associated with the GPO. The GPC and GPT contain the GPO's version and status information. The GPT is a set of files residing in the sysvol folder, which you'll find on your domain controllers. (Don't confuse the GPT with the System Volume Information folder. The policies in sysvol reside under systemrootsysvol
sysvoldomainnamepolicies.) In the GPT, you'll find information about administrative templates, security, scripts, and software installation.

Before you start creating GPOs, consider where you need to apply the policy. Does the policy apply to all of your users or computers? If so, perhaps you need to apply the policy at the site level. If the policy is relevant to only one domain or to users within one OU, applying the policy at the domain or OU level might be more appropriate.

Inheriting Policies
When a user logs on, Win2K evaluates policies starting at the top of the AD structure and working down. The order of evaluation is site, domain, then OU. At each level, you can set a policy as Enabled, Disabled, or Not Configured. Not Configured means that at a particular level, no setting changes will occur at the time of evaluation. By default, each container inherits GPO settings from the container above it. However, a setting in a lower container, such as an OU, can override a setting at a higher level. Therefore, if you set a policy in the parent OU, but you don't configure it in the child OU, the child OU will inherit the parent setting. If you configure a similar policy at both parent and child, both settings will apply without conflict. But when the parent and child OU policies conflict, the child policy takes precedence, and the OU won't inherit the parent policy setting. You can apply a broad set of policies to your users, then modify policies for specific subgroups in your organization as necessary.

Managing Inheritance
Sometimes, you won't want child containers to change your GPO at a lower organizational level. You might have corporate policies that you don't want to change at any level. For example, to ensure that users install only software with valid certificates, you might want to enforce the Disable changing certificate setting. The No Override option, which applies to the entire GPO, prevents any child container from overriding the policy. Therefore, you need to place all your corporate, nonnegotiable policies into one GPO, then set the No Override option. You can place other policies that need to vary by OU in another GPO with the No Override turned off.

Occasionally, you might have an OU that needs a separate set of policies—corporate policies won't work. For example, the majority of users in your company might be fairly relaxed about policies—except for the accountants, who want more rigid policies. The Accountants OU can set the Block Inheritance option. That way, the accountants can set their own policies and avoid inheriting any policies from the parent domain or OU. The No Override option takes precedence over Block Inheritance, so an administrator lower in the hierarchy can't block your corporate policies.

Planning Policies
When you're planning policies, the best practice is to start at the top level of your AD structure with the broadest policies, then work your way down to the lower levels for more specific policies that apply to selected user groups or computers in specific OUs. However, you need to consider factors other than the combination of policies at each hierarchy level. The AD structure's depth can affect your planning. Because policy settings at one level modify the inherited settings from the level above, processing all the policies at every level from the top down to a user takes some time. Users at the bottom of the hierarchy might find that logging on takes longer than they expect.

Another consideration is the network traffic that might generate when users connect. A GPO associated with a site affects every computer in the site, regardless of which domain the computers belong to. Therein lies the obvious benefit of a site policy. However, the GPO resides in only one domain, and you might have multiple domains in your site. Therefore, to obtain the policy, all the computers in every domain need to contact a domain controller in the domain that contains the GPO. This necessity creates additional network traffic and a heavy load on the domain controllers. Creating identical GPOs at the domain level—so that each computer can obtain policies from its own domain controller—is often the way to go. To improve performance, you can disable computer or user settings per GPO. You can also set up the GPO so that the system processes it only if its version number has changed since the most recent startup or logon.

Creating a GPO
To create a GPO, go to either Administrative Tools, Active Directory Users and Computers or Active Directory, Sites and Services, depending on the level at which you plan to set policies. (You can also use the Microsoft Management Console—MMC—to find Active Directory Users and Computers or Sites and Services.) Expand the hierarchy, then right-click the AD container (i.e., a domain or an OU) that you want to create the GPO for. Click Properties, and on the Group Policy tab, select New to create a new policy or Edit to edit an existing policy. Screen 1 shows that I've created the policy 2000 Group policy - site at the site level.

The next step is to edit the new policy. To access the Group Policy dialog box that Screen 2 shows, click Edit. In my example, I've expanded the policy hierarchy and opened the Computer Configuration, Administrative Templates, Windows Components, Internet Explorer policy window. Suppose I want to prevent users from changing the Security Zones policies within Microsoft Internet Explorer (IE). I would double-click the policy and open that policy's Properties dialog box (or right-click the policy and select Properties). This action opens the window that Screen 3 shows. Pay particular attention to the check box in this window's upper left corner. When you first open this policy window, the check box is shaded but contains a check mark, which suggests that you can't change it. In fact, this shaded check mark indicates that the policy isn't currently configured for this GPO. (In other words, you have no opinion at this point whether users have the authority to change the Security Zone settings.) If you click the check box, the check mark becomes black against a white background, activating the policy that users can't change their Security Zone settings. If you click the box again, the box clears and users can change their Security Zone settings. One more click returns the box to its nonconfigured state.

You can work your way through the policies by opening this property window for each policy, or you can use the Next Policy and Previous Policy buttons on the window's lower left side. If you make a change to the check box in the upper left corner, you need to click Apply in the lower right corner before you can click Next Policy or Previous Policy. If you don't click Apply, your changes won't take effect. Additionally, Win2K beta 3 offers no hot keys. If your mouse hand becomes exhausted, you can use the Tab key to move around and the space bar to toggle the options on and off. (Let's hear it for browser-based interfaces.) You can set dozens—possibly hundreds—of different items as administrative templates, but that's a subject for another article.

Processing Policies
Unlike NT 4.0 system policies, some Group Policy settings affect both users and computers. In NT, a policy was either a computer policy that integrated into the HKEY_LOCAL_MACHINE Registry key or a user policy that merged with the HKEY_CURRENT_USER Registry key. Win2K lets you specify some policies either for the computer or for the user. This freedom increases the possibility that policies will apply to both the user and the computer—along with the possibility that one policy will overwrite another. Knowing the order in which Win2K processes policies is helpful.

When a computer starts, Win2K processes any Group Policy settings for that computer, and startup scripts run. To ensure that the computer policies are in effect when the user logs on, the Group Policy settings for that computer activate before the logon screen displays. The user logs on, Win2K processes the Group Policy settings, and the logon scripts run. Finally, any individual logon scripts run after the system processes the Group Policy logon scripts.

Another difference between Win2K and NT 4.0 is that the user no longer needs to log off and log on again to receive new policy settings. (Therefore, a user can't retain old policy settings by never logging off.) By default, client computers check for new policies every 90 minutes—with a randomized offset of plus or minus 30 minutes, so that the computers don't all check simultaneously. Domain controllers renew their policy data every 5 minutes. The only exceptions are software-installation and folder-redirections settings, which Win2K processes only when the computer starts or a user logs on. If you need to notify users about the availability of new software in a more timely manner, consider Microsoft Systems Management Server (SMS).

Reducing TCO
Win2K's Group Policy settings are far more complex than NT's system policies, and they require careful planning. However, Group Policy offers a level of control that might reduce long-term support costs and bring down Win2K's TCO. For more information about Group Policy, see Darren Mar-Elia, "Software Installation in Windows 2000," February 2000.