Group Policy is near the top of any list of Windows 2000's most powerful features and is becoming more important with each Windows release. The ability to control the characteristics of large numbers of servers and clients is crucial at a time when just one incorrectly configured computer can spread a virus in seconds. Unfortunately, Group Policy is also near the top of any list of Win2K's most complex features. The high point of Win2K Group Policy is its strong capabilities; its low points become obvious when you try to manage these policies across an enterprise.
That's why the Group Policy Management Console (GPMC) is an invaluable tool. GPMC is a new, free Microsoft Management Console (MMC) snap-in for Windows Server 2003 that's designed to be the central management point for anything a Group Policy administrator might want to do. GPMC's UI makes working with Group Policy much simpler.
GPMC's list of features reads like a Group Policy administrator's wish list. GPMC has a new UI that lets you view Group Policy Objects (GPOs) across domains—and even forests—in an intuitive and useful way. You can now generate HTML reports on GPO settings even if you don't have write access to the GPO. You can back up and restore GPOs, export them from one domain and import them into another, and even perform mapping operations to a different set of security principals and Universal Naming Convention (UNC) paths between domains. GPMC also incorporates Resultant Set of Policies (RSoP), the most requested Group Policy enhancement for Windows 2003. You can use the Windows Management Instrumentation Query Language (WQL) to build Windows Management Instrumentation (WMI) filters. GPMC even has a tool that lets you search for GPOs within a domain or across all domains in a forest.
Requirements and Installation
Although GPMC is associated with the Windows 2003 release, the utility doesn't require the most recent OS, but the GPMC license agreement stipulates that you can install the GPMC only on a network on which you're running at least one copy of Windows 2003. You can install GPMC on Windows 2003 in its out-of-the-box configuration or on Windows XP with both Service Pack 1 (SP1) and the Windows .NET Framework (available from Windows Update) installed. If you're installing GPMC on XP, the installation package will automatically install XP Quick Fix Engineering (QFE) update Q326469 if it isn't already present. This QFE updates your version of gpedit.dll to the version GPMC requires. GPMC doesn't run on 64-bit versions of Windows because the Framework doesn't yet have a 64-bit version. GPMC and related documents are available from http://www.microsoft.com/windowsserver2003/gpmc.
In addition to managing Windows 2003 forests, GPMC can manage forests that contain Win2K domain controllers (DCs). The Win2K DCs should be running at least SP2 and preferably SP3. (For more information, see the Microsoft article "Windows 2000 Domain Controllers Require SP3 or Later When Using Windows Server 2003 Administration Tools" at http://support.microsoft.com//?kbid=325465.) To run Group Policy Modeling, you must upgrade at least one DC to Windows 2003. Be forewarned that editing GPOs in a Win2K forest using uplevel clients such as Windows 2003 and XP can result in a subtle consequence. If you use an uplevel client to edit a Win2K GPO, the client's newer policy settings will by default automatically upgrade the GPO without informing you. The Microsoft article "Upgrading Windows 2000 Group Policy for Windows XP" (http://support.microsoft.com//?kbid=307900) documents this behavior. Win2K clients will ignore the new settings, but you should be aware that this guerilla upgrade is taking place. To prevent the upgrade, enable the policy User Configuration/Administrative Templates/System/Group Policy/Turn off automatic update of ADM files in the GPOs you don't want automatically updated.
You can also run into GPO conflicts if you use the base XP release to edit a GPO, then upgrade your DCs to Win2K SP3. The administrative templates are automatically updated based on a simple timestamp, and the timestamps for the newly installed SP3 templates indicate that those files are newer than the XP files. The result is that the Win2K SP3 admin templates (newer in timestamp) overwrite the XP Group Policy templates (newer in code development), which can result in a corrupt admin template. Both the prevention of this problem and its fix are straightforward: Use a Windows 2003, XP SP1, or Win2K client to edit your Win2K GPOs because the timestamps for those OSs' Group Policy administrative templates are newer than the timestamps for Win2K SP3's templates.
When you install GPMC, it appears in the Administrative Tools as Group Policy Management. Because the utility is an MMC snap-in, you can also create a customized MMC console that contains GPMC by launching MMC and adding Group Policy Management from the Add/Remove Snap-in menu.
Let's take a look at GPMC's main console, which Figure 1 shows.
As with all MMC snap-ins, the UI consists of two areas: the scope pane on the left and the results pane on the right. The scope pane shows an Active Directory (AD) structure in a layout similar to the MMC Active Directory Users and Computers snap-in. If you look closely, however, you'll see several important differences. The first difference is that you can include multiple forests (e.g., the corpvm.bigtex.net and deuby.net forests in Figure 1). The second difference is that, within each forest, GPMC shows only containers that can have GPOs linked to them—sites, domains, and organizational units (OUs). Microsoft calls sites, domains, and OUs the scope of management (SOM). The third difference is how this pane shows the true relationship of GPOs to the SOM. As Figure 1 shows, the GPOs associated with these containers are depicted as shortcuts or links (note the little arrows on the icons). GPOs aren't stored in the containers in which they're created; they're stored on a per-domain basis (shown in the GPMC UI within the Group Policy Objects container) and linked to their target SOMs.
The GPMC UI supports drag-and-drop operations as well as the traditional context-menu method of performing tasks on a GPO. For example, you can link a GPO to an OU simply by selecting the GPO in the Group Policy Objects container and dragging it to the DC's OU. A dialog box confirms most GPO drag-and-drop operations; these kinds of operations can have wide-ranging consequences such as inadvertently linking a GPO to the wrong container, and you don't want to let a slip of the wrist screw up your default domain policy or other policies.
Note that the default DC GPO for the amrvm.corpvm.bigtex.net domain is selected on the scope pane, so the results pane provides details about that GPO. The results pane has four property sheets that describe each GPO's scope, details, settings, and delegation. Discovering which containers a user-created GPO is linked to can be a time-consuming process in Win2K. The result pane's Scope tab lets you determine which SOM the GPO is linked to.
In Figure 1, the default DC GPO isn't linked to any other sites, domains, or OUs. The Links list box presents all links to the GPO in one location. The Security Filtering section of the results pane shows which users and computer will process the GPO.
The Details tab provides GPO information that you previously had to hunt all over to find. This information includes the GPO's domain and owner, when the GPO was created and modified, the version numbers of the user and computer settings in AD and on SYSVOL, the GPO's globally unique identifier (GUID), and the GPO's enabled/disabled status.
The Settings tab lets you see the GPO configuration in an expandable HTML report—no more hunting through the MMC Group Policy Editor snap-in. Only the sections that have enabled settings are listed, and only the enabled settings are shown. You can expand or collapse each section by selecting show or hide. By right-clicking anywhere in the report, you can edit the GPO (through the standard MMC Group Policy Object Editor snap-in), print the report, or save it as an HTML file that expands and collapses as the original does.
The Delegation tab describes who has GPO rights. This view is clear and simple compared with the Byzantine complexity of the ACL editor for AD objects. Any listed security principal can have five possible setting combinations: Read, Edit settings, Edit settings/delete/modify security, Read (from Security Filtering) and (if you select the Advanced button on the Delegation tab and use the ACL editor to edit permissions directly) Custom. Security principals that have the Read (from Security Filtering) setting have security filtering applied to them and appear in the Security Filtering section of the Scope tab.
One common task the GPMC won't help you with is triggering the policy-update process, which you must do by using Gpupdate (in Windows 2003 and XP) or Secedit (in Win2K). To trigger a Group Policy update, open a command prompt from the appropriate client and run one of the above commands.
One of the most frustrating aspects of working with Win2K Group Policy is that you can't manipulate GPOs the way you manipulate file system objects. Unlike pure file system objects or purse AD objects, GPOs are hybrid constructs unique in Win2K; each GPO has an AD component as well as a file system component. The AD component is distributed through AD replication, and the file system component is circulated around the DCs' SYSVOLs through the File Replication Service (FRS). This is one reason GPOs are so hard to manipulate. You can create and delete them and edit their settings and security, but performing other kinds of operation against a GPO is just about impossible. You can't back up the GPO for safekeeping, restore it if you mess up something, or make a copy of it for a test forest. However, GPMC makes all these operations easy.
To back up a GPO, simply right-click the GPO in the scope pane and choose Backup. The system will prompt you to enter the save location and a description before it begins backing up the GPO. You can back up all GPOs in the domain by right-clicking the Group Policy Objects container and selecting Back Up All. GPMC will show the progress of the backup, as Figure 2 shows. The same context menu also has a Manage Backups utility that lists all the backed-up GPOs in a specified folder.
When you restore a GPO, the GPO's existing settings are deleted and the backed-up settings are restored to their state at the time you backed them up. You can use the restore operation to roll back a GPO that's in an unhealthy or unwanted state or recover a deleted GPO. GPMC doesn't restore the links to the GPO if you've deleted them, but because the GPO's GUID remains the same, existing links will work on the restored GPO the way they did with the original.
To restore a GPO, right-click the GPO under the GPO container and select Restore From Backup. If you've deleted the GPO, right-click the GPO container, select Manage Backups, and choose the GPO you want to restore. When you select the particular backup you want to use, you can view the backed up GPO's settings (in the same report format as the Settings tab) to be sure it's the GPO you want.
Copy and Import
The Copy and Import operations transfer an existing GPO's settings to a new GPO. The new GPO can be located in the same domain, in another domain, or even in another forest.
Several differences exist between the Copy and Import operations. Import requires that the destination GPO exist before you import the settings, whereas the Copy operation creates the destination GPO. Copy requires a trust relationship between the source and target domains so that you can perform the operation in one step, whereas Import doesn't have this requirement because it works off a backed-up GPO. In a configuration in which no trust relationship exists between the domains, you can't use Copy; you must back up the GPO to a common file system location, then import the backed-up GPO into the destination domain.
To import a GPO's settings, right-click the destination GPO and choose Import Settings. This action launches a wizard that prompts you to back up the existing settings, lets you select the file system location of the backed-up GPO, and restores the settings. If the source GPO references security principals or UNC paths, the wizard will automatically help you use a migration table to map the principals and UNC paths to the destination with a migration table (I discuss migration tables in a moment). Copy lets you develop a GPO change-management process that requires that you develop and test GPOs in a separate domain or forest of domains, then copy them into the production domain after the process has been approved.
Copying a GPO within a domain is straightforward because the users, computers, groups, and UNC paths that a GPO references are available to both the source and the destination SOM. Copying GPOs between domains within a forest—and certainly between domains in different forests—is more complicated than copying GPOs within a domain because UNC paths for folder redirection or software installation and security principals (e.g., domain local groups) referenced in the source GPO's settings might not be available to the target domain. Because security principals are referenced in the GPO as a SID, if you copy them straight across to a target domain that doesn't have access to them, they appear as unresolved SIDs. Not only would the dysfunctional GPO not work as you intended, it would generate recurring SceCli and Userenv errors in the destination domain's Application event log.
To fix this problem, create a one-to-one mapping of the source GPO's domain-specific security principals and UNC paths to the destination domain's counterparts. For example, if you have a domain local group named Test GPO Admins in your TEST domain, when you copy the GPO to the production (PROD) domain, you need to determine which group you should reference in the PROD domain instead of Test GPO Admins. The TEST GPO Admins group doesn't exist in the PROD domain, and creating a group with the same name won't work because the identifier that the GPO uses—Test GPO Admins' SID—is different in the production domain. However, if you create a table that maps TEST\Test GPO Admins to PROD\GPO Admins, GPMC will replace TEST\Test GPO Admins' SID in the GPO with PROD\GPO Admins' SID, and the GPO will function correctly in its destination domain.
Microsoft calls this mapping a migration table. The application associated with migration tables is the migration table editor (MTE) mtedit.exe. The MTE is part of the Copy and Import operations, so when the system detects security principals or UNC paths, the option to launch the MTE appears in the wizard. You can also launch the MTE by right-clicking the GPO container in the scope pane and selecting Open Migration Table Editor.
A Sample GPO Copy Operation
Let's walk through a GPO Copy operation from the child domain amrvm.bigtex.net to its peer domain, gervm.bigtex.net. The source GPO, CoolNewGPO, grants the Capacity Planning Team rights to profile system performance, the Security team rights to manage auditing and the Security log, and the Server Operations team rights to shut down systems remotely. To copy the GPO, right-click CoolNewGPO in the Group Policy Objects container in the AMRVM domain and select Copy. Then, right-click the Group Policy Objects container in the GERVM domain and select Paste. This action launches the Cross-Domain Copying Wizard, which steps you through the rest of the copy operation. Be careful to paste only into the destination domain's Group Policy Objects container; if you accidentally choose another container, you might end up linking the source GPO across domains, an undesirable situation. Fortunately, a confirmation dialog box will appear to confirm that you want to perform the cross-domain link.
If you want to copy a GPO between domains you first need to decide whether to migrate the permissions from the source GPO or simply accept the default permissions for the new destination GPO. For our example, we'll choose to use the default permissions at the destination GPO. The Cross-Domain Copying Wizard then analyzes the source GPO for security principals or UNC paths that might require a migration table. Because our GPO contains security principals, the wizard presents us with two choices: We can either copy the principals from the source, or we can build a migration table to transfer the settings to the destination domain. Because we're interested in migration tables, we'll click New to build a new table.
When you click New, the GPMC presents an empty migration table. From the File menu, select Tools, Populate from GPO. This action lets you choose the source GPO (although you've already determined which GPO you want to copy by beginning the Copy operation) and populate the migration table with the security principals and UNC paths in the source GPO. Next, choose the destination domain, as Figure 3 shows.
Our source domain, AMRVM, has three global groups of interest: AMRVM Security Spooks, AMRVM Capacity Planning, and Server Operations. We need to map these groups to the destination groups GERVM Security Spooks, GERVM Capacity Planning, and Server Operations in the GERVM domain. Right-click the Destination Name field in the MTE and choose Browse. This action launches the AD object picker. Click the Locations button, enter all or part of the destination group's names, then click Check Names or press Enter. When you select the object and click OK, the wizard enters the groups, in user principal name (UPN) format, into the Destination Name field.
Because Server Operations (this isn't the Server Operators built-in group) has the same name in both the source and destination domains, right-click the Destination Name field, and choose Set Destination, Map By Relative Name, as Figure 3 shows. When you specify this mapping option, the GPMC will look for a security principal in the destination domain that has the same relative name and will replace the source security principal in the policy with the destination security principal.
The migration table is now complete, so select File, Exit, and answer "yes" when prompted to save your changes. The wizard will present a summary of the changes about to be made and will execute the Copy operation when you click Finish. To display the copied GPO's settings, select the new GPO in the GPMC scope pane and select the Settings tab in the results pane. Note how the security settings have changed from AMRVM to GERVM.
The GPMC snap-in is based on a set of COM interfaces (also available to VBScript, Jscript, and Visual Basic—VB) that does most of the work. For the majority of us who never learned scripting well enough to take advantage of such an interface set, the GPMC development team has included a collection of GPMC scripts in the %programfiles%\gpmc\scripts directory. These scripts are almost as important as the UI because they let administrators control GPOs (although not their settings) programmatically. You can schedule the scripts to run regularly without operator intervention.
Using the sample scripts, you can back up or restore one GPO or all GPOs in a domain, copy them, delete them, create a GPO with default options, alter permissions, import one or many GPOs into a domain, and generate reports on any or all GPOs in a domain. Twelve other scripts let you query various aspects of the Group Policy environment, such as listing all GPOs in the domain with detailed information or listing all GPOs that aren't linked to a site, domain, or OU.
Two scripts demonstrate the power of this scripting interface and XML: CreateXMLFromEnvironment.wsf captures information about OUs, GPOs, GPO links, and GPO security settings in a domain and saves that information to an XML file. CreateEnvironmentFromXML.wsf reads XML files that CreateXMLFromEnvironment.wsf creates and builds an entire environment based on the saved information. With these scripts, you can quickly create a development or test environment that mimics your production environment.
RSoP is one of Windows 2003's most exciting and most needed features. The policies that users end up with depend on many variables, so a challenge in working with Group Policy is figuring out how a set of GPOs linked to various sites and OUs in a domain actually affects users. RSoP lets you determine the effective policy—for a computer anywhere in the directory hierarchy or for any given user—of all GPOs that apply to that computer or user. RSoP has two aspects: logging mode and planning mode. RSoP logging provides a way to report on which GPOs are delivered to a particular user or computer and which GPO those settings came from. RSoP planning lets you perform what-if analyses to display the effect a GPO or combination of GPOs might have on a user or machine that's moved to a different OU or security group. Two methods exist to let you access RSoP without using GPMC. When you're logged on to your Windows 2003 or XP computer, you can quickly determine the effective policy for your user account by entering
from a command prompt. Displaying the policy settings that are in effect is the essence of logging mode. To run RSoP in planning mode without using GPMC, open MMC on a Windows 2003 server and add the RSoP snap-in to the console. You can then step through what-if scenarios to your heart's content.
Because GPMC is designed to be the central point of Group Policy administration, you can also run RSoP directly from GPMC. In GPMC, Microsoft has wisely renamed RSoP Logging Mode to Group Policy Results, and RSoP Planning Mode is now Group Policy Modeling.
Group Policy Results. You can obtain Group Policy Results from clients in a Win2K domain, but those clients must be running Windows 2003 or XP and you must have local administrator rights on the client you're getting results data from. To start the Group Policy Results Wizard, right-click the Group Policy Results icon in the left-hand pane of the GPMC snap-in and select Group Policy Results Wizard. The wizard will step you through specifying the computer and user whose settings you want to check. GPMC displays the extensive results in the results pane, as Figure 4 shows.
Note the three tabs. The Summary tab shows summaries of the computer user configurations, the Settings tab displays the effective settings, and the Policy Events tab displays Group Policy–related event-log messages.
Group Policy Modeling. Group Policy Modeling lets you simulate applying GPOs to users and computers without all the time, hardware, and anguish that typically accompany a Group Policy deployment. Used in conjunction with the Copy and Import feature, you can use Group Policy Modeling to develop, test, and deploy GPOs in a fraction of the time it takes to do so in Win2K.
As with Group Policy Results, you start the wizard by right-clicking the Group Policy Modeling icon in GPMC's left-hand pane. For this icon to be available, you must have at least one Windows 2003 DC in the forest. Please see http://www.microsoft.com/technet/prodtechnol/windowsserver2003/proddocs/entserver/rspintro.asp for detailed information about Group Policy Modeling and Planning (described as Resultant Set Of Policy in the link).
An Indispensable Tool
GPMC provides sorely needed functionality for GPO development and management and consolidates many separate functions into one cohesive interface. But GPMC doesn't cover every aspect of Group Policy management (e.g., change management), so you'll have to investigate third-party applications that are more comprehensive. The synergy between the Copy, Import, and Group Policy Modeling features let you develop and deploy GPOs much faster and with greater confidence than you can with Win2K. GPMC is such an indispensable tool for Windows 2003 and Win2K that I think Microsoft should include the utility with the OS rather than provide it as an add-on.