The CreateGPO.wsf script is used to create a single GPO. The GPO is created unlinked. The script has the following usage:

CreateGPO.wsf GPOName [/Domain:value]

The GPOName parameter is the friendly name of the GPO you want to create, and the optional Domain parameter lets you create the GPO in a domain other than the one where the GPMC is installed. Here’s how you can create a GPO called Desktop Configuration Policy:

Cscript CreateGPO.wsf "Desktop Configuration Policy"

The DeleteGPO.wsf script lets you delete a particular GPO. You can optionally keep all the links to the GPO. The syntax for this script is as follows:

DeleteGPO.wsf GPOName [/KeepLinks] [/Domain:value]

When you use this script, you supply the friendly name for the GPO. If you choose the KeepLinks parameter, the links to the GPO on container objects are kept when the GPO no longer exists. This might be a good strategy if you need to restore the GPO from a backup. In that case, with the links in place, you won’t lose the references to the SOMs where that GPO was linked. You can also specify the domain name to perform the operation against. An example is shown here:

Cscript DeleteGPO.wsf "Desktop Configuration Policy" /KeepLinks

The FindDisabledGPOs.wsf script can locate any GPOs within a domain that have been disabled. The syntax is simple:

FindDisabledGPOs.wsf [/Domain:value]

If you run the script without the option Domain name, it returns all disabled GPOs within the domain where the GPMC is installed. The script returns GPOs that are completely disabled, ones that have only the computer side disabled, and ones that have only the user side disabled.

The FindGPOsBySecurityGroup.wsf script lets you search for GPOs in which a particular group has a particular level of delegation. The syntax for the script is as follows:

FindGPOsBySecurityGroup.wsf GroupName /Permission:value [/Effective] [/None]
[/Domain:value]

For example, if you want to find all the GPOs in which the GPO Admins group has edit permissions on a GPO, you can run the script with the following parameters:

Cscript FindGPOsBySecurityGroup.wsf "GPO Admins" /Permission:Edit

If you use the Effective parameter, the script searches out effective memberships for the specified group. For example, if GPO Admins doesn’t have direct Edit permissions on a GPO but has them by virtue of its membership in another group, the Effective parameter will track that down. If you specify None, the script searches for GPOs in which the GPO Admins group does not have Edit permissions.

The FindUnlinkedGPOs.wsf script lets you locate GPOs within a domain that have not been linked to any SOM. The script has the following syntax:

FindUnlinkedGPOs.wsf [/Domain:value]

The script returns a list of all GPOs within the specified domain that aren’t linked to any containers in Active Directory.

The SetGPOCreationPermissions.wsf script lets you add or remove a groups ability to create GPOs in a domain. The syntax of the script is as follows:

SetGPOCreationPermissions.wsf Group [/Remove] [/Domain:value]

For example, if you want to grant the permission to create GPOs to the GPO Admins group, you call this script:

Cscript SetGPOCreationPermissions.wsf "GPO Admins"

To remove the permission from that group, simply add the /Remove parameter to the command:

Cscript SetGPOCreationPermissions.wsf "GPO Admins" /Remove

The SetGPOPermissions.wsf script lets you set or replace permissions on a GPO. These permissions include both security filtering (which computer or user can process a GPO) and delegation (who can read, edit, and delete a GPO). The syntax for the script is as follows:

SetGPOPermissions.wsf GPOName GroupName /Permission:value /Replace
[/Domain:value]

For example, if you want to change the existing permissions that the GPO Admins group has on the Desktop Configuration Policy from Edit to FullEdit, you call this script:

Cscript SetGPOPermissions.wsf "Desktop Configuration Policy" "GPO Admins"
/Permission:FullEdit /Replace

You use the Backupallgpos.wsf script to back up all GPOs in a domain to a particular backup location—typically a folder on a file system somewhere. The script takes three input parameters—one mandatory and two optional—as shown here:

Backupallgpos.wsf BackupLocation [/Comment:value] [/Domain:value]

The backup location is the directory to which you want to write the backup data—it can be local or remote. The comment is stored with the backup so that when you choose the Manage Backups option in the GPMC interface, you see the comment associated with it, as shown in Figure C-4.

Figure C-4. Viewing GPOs backed up using BackupAllGPOs.wsf

As you can see from the figure, each GPO has the same comment when backed up using the /comment option on this script. You can also optionally specify the domain in DNS format using the /domain option if you need to back up a domain other than the one in which the GPMC is running. An example of usage for this script follows:

Cscript BackupAllGPOs.wsf c:gpobackups /comment:"Backup of all GPOs"
/domain:cpandl.com

The BackupGPO.wsf script lets you back up a single GPO at a time. Its usage is similar to the previous script, except that you need to specify the name of the GPO to back up:

BackupGPO.wsf GPOName BackupLocation [/Comment:value] [/Domain:value]

In this script, you can specify either the GPO’s friendly name or its GUID. Either will be resolved to the correct GPO. An example follows:

Cscript BackupGPO.wsf "Desktop Configuration Policy" c:gpobackups
/comment: "Backup of desktop lockdown before the change" /domain: cpandl.com

The CopyGPO.wsf script is used to copy one GPO to another, new GPO. When you copy a GPO, all of its settings are copied to the new target GPO. The copy feature in the GPMC is supported either within a domain or across domains within a single forest. It is not supported for copying GPOs across forests. The syntax for this script is as follows:

CopyGPO.wsf SourceGPO TargetGPO [/SourceDomain:value] [/TargetDomain:value]
[/SourceDC:value] [/TargetDC:value] [/MigrationTable:value] [/CopyACL]

As you can see, only the SourceGPO and TargetGPO parameters are required—the rest are optional. However, if you don’t specify any options, the source GPO is copied to the same domain and all settings are assumed to be the same. Keep the following in mind:

An example of this usage is shown here:

Cscript CopyGPO.wsf "Desktop Configuration Policy" "Desktop Configuration Policy"
/sourcedomain:cpandl.com /targetdomain:east.cpandl.com
/MigrationTable:c:migrationtableseast.migtable /copyACL

You can use the ImportGPO.wsf script to import a backed up GPO into a a specified target GPO. The script has the following syntax:

ImportGPO.wsf BackupLocation BackupID [TargetGPO] [/MigrationTable:value]
[/CreateIfNeeded] [/Domain:value]

BackupLocation is the folder where your GPO backups are stored, and BackupID is the friendly name or the GUID of the GPO to import. The TargetGPO parameter is the friendly name of the GPO into which you want to import the settings from the backed up GPO. The MigrationTable parameter lets you specify the location of a migration table to apply to the import process. The CreateIfNeeded parameter tells the script to create a new GPO to import the backed up one into if no TargetGPO is found. The Domain parameter lets you specify a different domain as the destination. An example of this script is as follows:

Cscript ImportGPO.wsf c:gpoback "Desktop Configuration Policy" "New Lockdown
Policy" /MigrationTable: c:migtableslockdown.migtable

The GetReportsForGPO.wsf script creates XML and HTML settings reports for a given GPO and saves them to a defined file system location. The syntax for this script is as follows:

GetReportsForGPO.wsf GPOName ReportLocation [/Domain:value]

GPOName is the friendly name for the GPO you want to report on, and ReportLocation is the folder where you want the reports to be saved. Note that both XML and HTML files will be created and will have the same name as the friendly name of the GPO (such as Desktop Configuration Policy.HTML).

The CreateXMLFromEnvironment.wsf and CreateEnvironmentFromXML.wsf scripts are useful for setting up test environments that mirror your production environment. CreateXMLFromEnvironment.wsf is used to create a copy of your production domain environment, including its OU structure, users, permissions, and GPOs. That information is stored to an XML file. You can then use CreateEnvironmentFromXML.wsf within a new Active Directory domain to import the production structure and information so that the environments are identical in most respects.

The syntax for both commands follows:

CreateXMLFromEnvironment.wsf OutputFile [/Domain:value] [/DC:value]
[/TemplatePath:value] [/StartingOU:value] [/ExcludePermissions]
[/IncludeAllGroups] [/IncludeUsers]

CreateEnvironmentFromXML.wsf /XML:value [/Undo] [/Domain:value] [/DC:value]
[/ExcludeSettings] [/ExcludePermissions] [/CreateUsersEnabled]
[/PasswordForUsers:value] [/MigrationTable:value] [/ImportDefaultGPOs] [/Q]

The only mandatory parameters for each script are the location of the XML output file for CreateXMLFromEnvironment.wsf and the location of that XML file as input for CreateEnvironmentFromXML.wsf. In the CreateXMLFromEnvironment.wsf script, you can use the Domain parameter to specify which domain to capture, the DC parameter to specify which domain controller to pull the information from, and the TemplatePath parameter to specify the file system location where you want to store the GPO backups. If you don’t want to capture the whole domain, you can use the StartingOU parameter to specify the DN of the OU where you want to start the capture.

If you choose the ExcludePermissions option, no permissions on either GPOs or container objects (SOMs) are captured for restoration. If you use the IncludeAllGroups option, all groups found in the Users container within the domain or at the root of the domain are included, as well as any other groups found in the domain. Otherwise, these groups are excluded. Finally, if you specify the IncludeUsers option, user accounts as well as groups are captured.

On the receiving side, the options that you can specify on the CreateEnvironmentFromXML.wsf script include the Undo parameter, which actually removes the objects found in the XML file rather than adding them to the new domain. The Domain and DC parameters let you specify the name of the destination domain and the domain controller, respectively, where want to import the captured information. ExcludeSettings and ExcludePermissions let you choose to not include GPO settings from the captured GPOs and to exclude GPO and SOM permissions, respectively. The CreateUsersEnabled option lets you create any captured user object as an enabled user instead of a disabled user, which is the default.

Using the PasswordForUsers parameter, you can specify a password that all newly created user objects will receive. The MigrationTable parameter lets you choose a migration table to apply to all GPOs as they are imported into the destination domain. The ImportDefaultGPOs gives you the option to import the settings captured in the Default Domain Policy and Default Domain Controllers Policy GPOs from the source domain into the target. Finally, the Q parameter lets you run the script quietly (without feedback). Here is sample usage for each script:

Cscript CreateXMLFromEnvironment.wsf c:outputprodenvironment.xml
/Domain:cpandl.com /TemplatePath:"c:gpoback" /
StartingOU:OU=Marketing,DC=cpandl,DC=com /IncludeUsers

Cscript CreateEnvironmentFromXML.wsf /XML: "c:outputprodenvironment.xml"
/Domain:testcpandl.com /CreateUsersEnabled /PasswordForUsers:"P@ssw0rd"
/MigrationTable:c:migtables	est.migtable

The GPMC includes many prebuilt .wsf scripts. We’ve looked at the most frequently used ones. Table C-1 describes the remaining scripts.

Note

In Table C-1, a dash (-) has been added to the script name where needed to allow the line to break. The dash is not part of the script name.