Examining Windows Server 2003 Group Policy Enhancements, Part V

By Marcin Policht (Send Email)
Posted Jun 30, 2003


In this, the final article of our "Windows 2003 Server Group Policy Enhancements" series, we will review the new Group Policy related scripting features. Note that these features are not part of Windows 2003 server installation but instead are built into the same dynamic libraries (DLL files) that Group Policy Management Console (GPMC) takes advantage of. In the final article of his'Windows 2003 Server Group Policy Enhancements' series, Marcin Policht reviews the new Group Policy related scripting features, explaining how to write and implement original scripts and describing the Microsoft-provided sample scripts.

Therefore, to have the scripting functionality available, you must download and install GPMC from its download page on the Microsoft Web site. This also means that you will be able to run Group Policy scripts on a Windows XP computer with SP1 and appropriate hotfixes installed (for the details, refer to the previously mentioned GPMC download page). Unfortunately, since the scripting interface is implemented in the same libraries as the Group Policy Management MMC snap-in, this also means that currently it is not possible to script creation or modification of Group Policy settings themselves.

Note also, that while you can apply scripts to Windows 2000 Active Directory domains, certain features (such as WMI filters, Group Policy modeling, or delegation of Group Policy results) are limited to Windows 2003 Active Directory domains.

Scripting group policies are based on the concept of object model. You might be familiar with this idea if you have some experience with any popular scripting technologies, such as Windows Script Host, FileSystemObject, Active Directory Services Interface, or Windows Management Instrumentation. Each these offers some type of functionality, such as access to the user environment (with drive and printer mappings, shortcuts, and so on), file system, directory services, or other software or hardware components through sets of objects. Most of these objects correspond in a fairly straightforward manner to individual features of the computing environment. For example, FileSystemObject object model contains such objects as File or Folder, while Windows Management Instrumentation has objects named Win32_NetworkAdapter or Win32_ComputerSystem.

Typically, at least one object serves as an entry point to the object model. Generally, the script first creates an object, providing access to the remaining ones within that object model. In the case of the object model based on GPMC, this top-level object is called GPMgmt.GPM. The object model contains a fairly large number of other objects, such as GPMDomain, GPMSitesContainer, GPMBackup, and GPMPermissions -- each corresponding to a different group-policy-related component.

Documentation describing the GPMC object model (in the form of GPMC.CHM file) gets copied to the Program Files\GPMC\Scripts folder during the installation of the GPMC installation program. You can refer to this help file if you intend to create your own scripts to manage GPO-related tasks.

Don't get discouraged if scripting is not your favorite activity. Microsoft provides more than 30 sample scripts, covering basic functionality offered by Group Policy object (GPO) model. The scripts are stored in the same directory as the help file (i.e., Program Files\GPMC\Scipts). All of them are written in VBscript (.wsf files); however, they use helper functions stored in the JScript-based library file (Lib_CommonGPMCFunctions.js). This file must reside in the same folder as the sample scripts. The folder also contains a sample migration table (for more information on the migration tables refer to the previous article in this series).

The following is a list and short description of these sample scripts.

  • BackupAllGPOs.wsf backs up all GPOs for a specified domain
  • BackupGPO.wsf backs up an individual GPO based on its GUID or name that you need to provide
  • CopyGPO.wsf copies settings from a source GPO (based on its GUID or name) and creates a new target GPO (using the name you specify) with identical settings. You can specify migration table as one of the script arguments, in case source and target GPO reside in separate domains and references to security principals (users, computers, or groups) must be changed between the two. Note that you can create a migration table automatically using the CreateMigrationTable script described below.
  • CreateEnvironmentFromXML.wsf uses an XML file to create (or, more commonly, re-create) entire Group Policy environment. Besides Group Policy Objects and GPO links, this might (although it does not have to -- the scope is configurable and entirely up to you) include organizational units, and security principals (users and groups). In combination with CreateGPO.wsf script (described next), this provides a very convenient way of mirroring your production environment in a lab.
  • CreateGPO.wsf creates a new GPO with default settings using the specified name and target domain.
  • CreateMigrationTable.wsf creates an XML file that stores the mapping between security principals (users, groups, and computer accounts) in source and target domains. This file can then be used when copying GPOs between two domains. The number of accounts is determined by the scope of the mapping, which can be set to a single GPO, all GPOs, or the content of an existing GPO backup file (which is created with BackupAllGPOs or BackupGPO scripts).

  • CreateXMLFromEnvironment.wsf can be used to store settings describing the current policy environment (consisting of GPOs, organizational units, GPO links, users, and groups) into an XML file, that can be subsequently used to re-create this environment.

  • DeleteGPO.wsf deletes the GPO based on the name or GUID specified.

  • DumpGPOInfo.wsf displays GPO-specific information, such as its name, GUID, creation and modification dates, version numbers, permissions, and GPO links. Note, however, that the script does not list GPO settings.

  • DumpSOMInfo.wsf displays GPO-related information in the context of a scope of management, i.e., site, domain, or organizational unit, whose name you specify. This includes listing GPO links and accounts with permissions to create them, as well as permissions for generating RSoP logging and planning (in Windows 2003 Active Directory domains) data.

  • FindDisabledGPOs.wsf lists all disabled or partially disabled (user or computer portion) GPOs for a specified domain. This offers an easy way to clean up an environment by removing GPOs that are no longer used. The cleanup process should also include FindUnlinkedGPOs and FindGPOsWithNoSecurityFiltering scripts, described below.

  • FindDuplicateNamedGPOs.wsf lists all GPOs with duplicate names across the specified domain

  • FindGPOsByPolicyExtension.wsf lists all GPOs that have a specified Group Policy extension configured. The types of extensions you can use include Software Installation, EFS Recovery, IP Security, Internet Explorer Branding, Security, Scripts, QoS Packet Scheduler, Microsoft Disk Quota, Registry, Folder Redirection, and Wireless Group Policies.

  • FindGPOsBySecurityGroup.wsf provides a quick way to find GPOs for the domain where a specified user or group has a certain level of permissions (such as read, apply, edit, full edit, or none).

  • FindGPOsWithNoSecurityFiltering.wsf lists all GPOs for which Apply right is not granted to any group (which essentially means that such GPOs are not being used).

  • FindOrphanedGPOsInSYSVOL.wsf GPOs consist of two components. One of them resides in the SYSVOL share on the domain controllers (in the subfolders of the Policies folder, named after GUID of each GPO), the other is stored in the Active Directory database. Under normal circumstances, both should be present and in synch (in terms of version number). Using this script you can find orphaned GPOs (the SYSVOL portion exists but without equivalent Active Directory component). This can happen if, for example, someone without permissions to SYSVOL share deletes a GPO.

  • FindSOMsWithExternalGPOLinks.wsf typically, it is not recommended to link GPOs defined in one domain to other domains (or organizational units residing in other domains). This script searches the specified domain and all of its organizational units for such instances.

  • FindUnlinkedGPOs.wsf lists all GPOs not linked to any site, domain, or organizational unit, and therefore, not being actively applied to any users or computers. As noted previously, you should include this script as part of your GPO cleanup process.

  • GetReportsForAllGPOs.wsf is an excellent way to document all of your Group Policy environment. All you must do is specify a folder and launch the script. (Using optionally the domain name as the argument -- if you omit it, the script will run for the domain of a currently logged on user.) This will produce a number of files (in both XML and HTML format), each containing Group Policy related information for individual GPOs in the domain -- version number, links, security and WMI Filtering, delegation, and more importantly, all of the settings defined in Computer and User configuration of the GPO.

  • GetReportsForGPO.wsf if you want to have XML and HTML formatted report for a single GPO (rather than all of them), then use this script. You will need to specify the name or GUID of the GPO you are interested in.

  • GrantPermissionOnAllGPOs.wsf grants the permission level you specify (read, edit, full edit, or none) to a group or user on all GPOs in the domain.

  • ImportAllGPOs.wsf can serve as a quick way to re-create the production environment in a lab. It uses the backup of existing GPOs to create copies in another domain, including each of their settings. You might need to specify a migration table as a parameter, since it is likely that security principals used in the target domain will be different from the source.

  • ImportGPO.wsf is used for importing a single GPO. You need an existing backup and must specify the name and domain of the target GPO to which to import the settings.

  • ListAllGPOs.wsf gives a quick or detailed (if /v switch is used) listing of all GPOs in the domain. Quick listing provides only name and GUID of each GPO; a detailed view includes links and permissions.

  • ListSOMPolicyTree.wsf lists all domains, organizational units, and sites with GPO links for each.

  • QueryBackupLocation.wsf is useful if you want to script restore or import operation. Its output contains the listing of all GPOs stored in a specified backup folder.

  • RestoreAllGPOs.wsf restores the most recent version of each GPO backed up at a specified location. Note that the restore is different from backup, since the restore location is the same as the one originally backed up, while import results in the creation of identically configured GPOs at new locations.

  • RestoreGPO.wsf restores the most recent version of an individual GPO identified by name or GUID from a specified location.

  • SetGPOCreationPermissions.wsf grants or denies permissions to create GPOs in a domain for a specified group or a user.

  • SetGPOPermissions.wsf sets read, apply, edit, full edit, or none permissions on an individual GPO for a specific group.

  • SetGPOPermissionsBySOM.wsf sets read, apply, edit, full edit, or none permissions on all GPOs linked to a site, domain, or OU for the group you specify.

  • SetSOMPermissions.wsf sets Group Policy related permissions (Link GPO, execute RSoP logging, execute RSoP planning, all, or none) on a domain, organizational unit, or specific site.

Our hope is that this article will encourage you take advantage of new scripting features in Group Policy management. In the long run this could definitely shorten the time spent on managing group policies in your current environment, regardless of your plans for migrating to Windows 2003.

Page 1 of 1


Comment and Contribute

Your name/nickname

Your email

(Maximum characters: 1200). You have characters left.