By Michael Cherry [bio]
Posted: Dec. 9, 2002

• Sidebar: Group Policy Details
• Illustration: Group Policy Modeling
• Illustration: Group Policy Management Console

The following is the full text of an article published by Directions on Microsoft, an independent research firm focused exclusively on Microsoft strategy & technology. Each month we make one or more key articles available to non-subscribers.

Companies looking to reduce the cost of maintaining large numbers of computers should evaluate Windows .NET Server 2003's improvements to Group Policy, a feature for centrally maintaining standard computer configurations. Administrators have been reluctant to use Group Policy because it requires Active Directory, and it is difficult to understand and troubleshoot. Windows .NET Server 2003 addresses some of these fears by making Group Policy simpler to understand and easier to debug. However, few applications use Group Policy for their configuration and management, so Group Policy remains primarily a solution for Windows configuration, rather than a total computer management solution.

Architecturally, Group Policy has not changed significantly; the main improvements in Windows .NET Server make it easier to interpret the process of how policy is applied to users and computers for planning and monitoring, and increase the granularity of control for administrators setting policy. Microsoft will also provide a single, centralized tool to manage Group Policy, the Group Policy Management Console (GPMC), which it promises will be available shortly after the general availability of Windows .NET Server in 2003.

Complexity Blocked Savings

Group Policy was first introduced with Windows 2000 Server to address weaknesses in System Policy and total cost of ownership issues that were being highlighted by competitors promoting networked computers. Group Policy is enabled by Active Directory (AD) and allows administrators to centrally standardize and control the configuration of Windows 2000 and XP desktops. The idea is that Group Policy will reduce the cost of supporting Windows desktops because users will not be able to change their configurations and inadvertently break something, and because support and training is easier with consistent and standard configurations.

Administrators use Group Policy to define specific Windows configurations and associate those configurations to particular users and computers who are managed by the AD. For example, an organization could use an AD container called an organizational unit (OU) to aggregate users who work in the sales department, then apply policies against that OU that manage Windows settings for those users. Working with managers in the sales department, the administrator can determine which Windows features and applications the sales personnel need to perform their job; they may decide, for example, that sales people can only run programs from the Start menu, that they do not need to see the My Network Places icon on the desktop, and that they need Office installed on every computer. Then the administrator can use Group Policy to create and associate policies with the sales OU that enforce these decisions by removing the Run command, hiding the My Network Places icon on the desktop, and ensuring that Office is installed.

(For more background and details on Group Policy, see the sidebar "Group Policy Details".)

Barriers to Group Policy Adoption

One of the biggest barriers to the adoption of Group Policy is simply that it requires AD. The policy settings for Group Policy are contained in Group Policy Objects (GPOs) that are in turn associated with AD sites, domains, or OUs. The location of a user or computer in the hierarchy of AD containers affects which policies are applied when the computer starts and a user logs on. Therefore, an organization must first deploy AD before it can deploy Group Policy.

The second barrier to adoption of Group Policy is complexity—Group Policy is a powerful tool, but it is hard to understand and master. Group Policy is complex because, during its initial design, Microsoft made sure that it could handle not only simple management scenarios but also some of the complex cases that organizations encounter as they manage users and computers in a directory hierarchy. Therefore, deploying Group Policy can be a daunting task, particularly when an administrator needs to determine which policies will apply to a particular user when that user logs on to a particular computer. Administrators can unintentionally create scenarios where a policy is initially enabled but then subsequently disabled as additional policy assignments and filters associated with a user or computer are processed. Often the administrator cannot detect such conflicts until frustrated users complain about being unable to perform their job. The administrator may struggle to troubleshoot why the policies that he expected to be in effect are not and what changes are necessary to repair the damage. And because a policy can be applied to a large number of users, a problem created by the incorrect application of policy can be widespread. Debugging and repairing these "Resultant Set of Policy" (RSOP) problems is difficult, and ever since administrators were first introduced to Group Policy in Windows 2000 Server, they have asked Microsoft for a tool to evaluate the impact of a set of policies before they assign them.

In the same way that Group Policy depends on AD, the IntelliMirror features of Windows 2000 Server, which ensure that a user’s data, software, and personal settings are available if the user moves from one computer to a different computer, rely on Group Policy. But even the advantages of IntelliMirror, combined with the advantages of Group Policy, did not appear to drive either the significant adoption of either AD or Group Policy.

Microsoft is attacking these barriers on two fronts. First, Microsoft is making AD easier to deploy. (See "Active Directory Improvements Remove Many Migration Roadblocks" on page 3 of the Aug. 2002 Update.) Second, Microsoft has made significant improvements to Group Policy, including creating a new tool focused on managing all aspects of Group Policy, as well as making it easier to plan, monitor, and troubleshoot Group Policy in general. Microsoft has also provided increased granularity to make it easier to target specific policy settings to specific users and computers, made improvements to the information that administrators see in administrative templates that they use to manage Registry settings, and made other changes that improve the administration of policy.

Planning and New Scenarios

Windows .NET Server provides administrators with the ability to determine how the policies they assign to users and computers will affect them, to use Group Policy in AD cross-forest scenarios, and to know which platforms support a specific policy.

Group Policy modeling and reporting. Microsoft has extended the Group Policy infrastructure of Windows .NET Server and provided both the new GPMC tool and RSOP snap-in new tools to help administrators plan and report on their implementation of Group Policy.

The new RSOP information can be used in two modes: a planning (modeling) mode shows what a set of policies would do to a computer or user, and a logging (monitoring or results) mode shows the state of a computer or user to which policy has been applied. (For a screen shot of the RSOP snap-in planning mode report, see "Group Policy Modeling".)

To generate the "what if" planning data before the extensions run and generate their RSOP data, Microsoft provides a Group Policy Data Access Service (GPDAS) that mimics the execution of the extensions and generates the necessary planning data.

To create the data needed to log and report the actual RSOP, all of the server and client extensions that process policy now write logging mode data using a Windows Management Instrumentation (WMI) interface. When running in logging or result mode, the RSOP snap-in is querying the actual WMI data that was written by each extension as it processed the GPO. Queries of this data tell the administrator which policies have been applied, and determine which GPO was actually responsible for the application of the policy, after all filtering, blocking, and inheritance is taken into account.

Cross-forest support. Windows .NET Server offers new flexibility for processing GPOs across forests. For example, if an organization has two forests (A and B), it is conceivable that a user who is managed by an OU in forest A could log on to a computer that is managed by an OU in forest B. With Windows .NET Server, the appropriate policy will be applied to the computer when it starts (from forest B), and to the user (from forest A) when she logs on. (For information on cross-forest scenarios, see "Active Directory Primer" on page 3 and "Active Directory Cross-Forest Trust" on page 5 of the Aug. 2002 Update.)

"Supported on" keyword. To help administrators correctly deploy policy, the administrative templates include a "supported on" (Windows 2000 versus Windows XP) keyword to help administrators determine if the policy they want to set will have any effect on a particular version of Windows—for example, some features on Windows XP do not exist on Windows 2000.

Granularity of Control

The level of policy granularity in Windows 2000 (policy based on filtering, blocking, and inheritance) contributed to Group Policy’s overall complexity. But this has not stopped Microsoft from adding additional granularity, including software restriction, WMI filtering, and new settings.

Software restriction. With the Internet, it is easier for users to bring unauthorized software into an organization by downloading it. Responding to this reality, Group Policy now enables administrators to declare what software the organization trusts and then ensure that users can only execute trusted software. Administrators create software restrictions with the Group Policy Object Manager snap-in, which allows them to create a policy that recognizes new software and identifies it as trusted or untrusted by four criteria: a hash (or cryptographic "fingerprint") of the software, a certificate (a digital signature of the software publisher), the universal naming convention path to the software, or the IE Internet Zone (Internet, Intranet, Restricted Sites, Trusted Sites, My Computer) from which the software was downloaded.

WMI filtering. Administrators can now use any WMI data to filter the processing of policy. In other words, administrators can use machine hardware, configuration, and state characteristics to determine whether a policy should be applied. For example, WMI filtering can be used to configure an IPSec policy so that it would only be applied to computers with a particular network interface card. Although this is a powerful filtering mechanism, administrators will need to use it cautiously, as processing a lot of WMI filters could impact the time it takes to start the computer or log on.

New settings. Group Policy has more than 900 policy settings that administrators can use to control the configuration of Windows desktops, including settings that support the management of Terminal Server, application compatibility, networking (System Network Management Protocol [SNMP], quality of service [QOS], firewall, and dial-up configuration), DNS logon, IntelliMirror, new Control Panel settings, and Windows Media Player. (In comparison, Windows 2000 Server Service Pack 3 has approximately 500 policy settings.)

Group Policy Management Console

The Group Policy Management Console (GPMC) is a new centralized Group Policy management tool that administrators can use to display AD forests, domains, and sites and their associated GPOs; perform Group Policy modeling and reporting; and access new functionality, such as GPO backup and restore. (For a screen shot of the GPMC, see "Group Policy Management Console".)

The GPMC will assist administrators in the following tasks:

Correctly scoping GPOs. The biggest problem with Group Policy is ensuring that policy will be applied correctly to the intended set of users and computers. The user interface and design of the GPMC makes it easier for administrators to correctly determine the effect of Group Policy on users and computers.

Delegating management of Group Policy. Administrators will no longer have to rely on correctly configuring AD access control lists (ACLs) to allow other users or departmental administrators to create, link, and edit GPOs. From the GPMC delegation tab, an administrator can manage the Group Policy-related tasks that he wants to delegate.

Reporting GPO settings. Administrators can create visual reports that display all the defined settings in the GPO. By clicking on the Show All or Hide links on the report, the administrator can control the amount of GPO information being displayed, and save the reports in HTML or XML format.

Group Policy modeling and reporting. Administrators can run the RSOP feature from within the GPMC. This will display the resultant settings in a report that can be saved in HTML or XML format.

Backing up or exporting a GPO. Administrators can create a copy of the GPO data to a specified file system location. This copy can then be used to restore a GPO to a known good state or export the GPO to facilitate Group Policy deployment.

Restoring a GPO. Administrators can use a backup of a GPO to return a GPO to its previous state—for example, an administrator could replace a deleted or damaged GPO.

Copying or importing a GPO. Administrators can transfer the settings of an existing GPO to a new GPO in the same domain, a cross-domain in the same forest, or a cross-forest. For example, a GPO could be exported from a test lab and then imported into a production environment.

In addition to the GPMC, which allows administrators to manage Group Policy via a user interface, all of these tasks are exposed for scripting using either VBScript or JScript. This means that the new features, such as backup of the GPOs, can be scripted and managed to automatically run on a periodic basis. Microsoft indicates it will include 30 VBScripts for the most common operations— administrators can then modify these scripts for their environment or use them as guides to create their own scripts.

The GPMC is currently in a separate beta from Windows .NET Server, but Microsoft says it is covered by the Windows .NET Server license. Therefore, the company will make the GMPC available for free when Windows .NET Server is generally available (which is expected in spring 2003).

Still Work to Do

Although Windows .NET Server improves the ability to manage Windows desktops, a complete desktop configuration solution would also allow the configuration of applications. Unfortunately, Microsoft has not been able to get many developers to policy-enable their applications, even though it provides fairly detailed information for developers on how to use policy with their applications, all the way down to the level of how to write a client-side extension to process the policy.

Microsoft could start by doing a better job of enabling its own applications for Group Policy. For example, although administrators can install Office using the Group Policy-enabled IntelliMirror software distribution feature, managing Office and Windows configurations simultaneously is still a bit of a nuisance. The Office Resource Kit contains Group Policy administrative templates for common Office components (such as Word, Excel, and Access). A separate template is available for Project, and a Visio template can be created by copying the text from a support document, pasting it into Notepad, and saving it with the .adm file extension. Administrators can load these templates into the management console snap-ins and set the policies, and the RSOP tool will report on them, but this process is unnecessarily complex: administrators must gather together the Office templates from three sources, install them (by installing the Office Resource Kit, even though they may not need the other Office tools) on servers, and then add them into the Group Policy management tools.

The situation is even worse with third-party software. Windows XP logo compliance requires only that the developer honors policy that might be set—that is, the application should not bypass or subvert policy, but the developer need not add application-specific policy.

With Windows .NET Server, Group Policy might have crossed the threshold where enough organizations are now using it so that more application developers consider it worthwhile to support it. But before making this kind of commitment, developers will probably look to Microsoft’s own applications, such as Office, to provide better support for Group Policy first.

Resources

For information on how Group Policy works in Windows 2000, see www.microsoft.com/windows2000/techinfo/howitworks/management/grouppolicyintro.asp.

For an overview of the management technologies in Windows .NET Server, including Group Policy, see: www.microsoft.com/windows.netserver/evaluation/overview/technologies/mgmtsrvcs.mspx.

For preliminary information on the Group Policy Management Console, see www.microsoft.com/windows.netserver/gpmc/default.mspx.