Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2
GPO operations refer to the ability to backup (export), restore, import, and copy GPOs.
Backing up a GPO consists of making of copy of GPO data to the file system. Note that the Backup function also serves as the export function for GPOs. Backed up GPOs can be used either in conjunction with Restore or Import operations.
Restoring a GPO takes an existing GPO backup and re-instantiates it back in the domain. The purpose of a restore is to reset a specific GPO back to the identical state it was in when it was backed up. Since a restore operation is specific to a particular GPO, it is based on the GUID and domain of the GPO. Therefore, a restore operation cannot be used to transfer GPOs across domains.
Importing a GPO allows you to transfer settings from a backed up GPO to an existing GPO. You can perform this operation within the same domain, across domains, or across forests. This allows for many interesting capabilities such as staging of a test GPO environment in a lab before importing into a production environment.
Restoring and Importing a GPO will remove any existing settings already in the GPO. Only the settings in the backup will be in the GPO when these operations are complete.
Copying a GPO is similar to an export/import operation only the GPO is not saved to a file system location first. In addition, a copy operation creates a new GPO as part of the operation, whereas an import uses an existing GPO as its destination. These operations are discussed in additional detail in the following sections.
Backing up a GPO places a copy of all relevant GPO data into a specified file system location. The relevant data includes:
The GPO GUID and domain.
The Discretionary Access Control List (DACL) on the GPO.
WMI filter link (but not the filter itself).
A backup operation only backs up components of a GPO that are in the GPO in Active Directory and in the GPO file structure in SYSVOL. The operation does not capture items stored outside the GPO, such as WMI filters, links on a SOM to that GPO, and IP Security policies. These are separate objects with their own set of permissions, and it is possible that an administrator performing either a backup or restore operation may not have the required permissions on those other objects. In addition, in the case of WMI filters and IP Security policies, these can be used by multiple GPOs, so it is not necessarily desirable to restore these objects when restoring a single GPO. To avoid these complications, the backup and restore operations only handle the contents of the GPO itself.
Note that the link to a WMI filter is actually an attribute of the GPO, so the link is included as part of the GPO backup and restore operation; even though the WMI filter itself is not. Customers who want to backup and restore WMI filters should use the import and export capabilities that are available on the WMI filter node in GPMC. Similarly, a backup operation only includes the link to any IP Security policy set in a GPO, because IPSec policies are stored outside the GPO. You must use the Export Policies and Import Policies commands of the IP Security Policy Management snap-in to back up and restore the IPSec policies themselves.
The backup also contains an XML report of the GPO settings, a date and time stamp, and the user supplied description. The report can be viewed as HTML from within GPMC. Each backup is given a unique ID. This allows for multiple GPOs and/or multiple versions of the same GPO to be backed up to the same file system location. With GPMC, users can identify backups stored in a given file system location based on GPO GUID, the GPO friendly name, the date and time stamp of the backup, the domain name, and the description of the backup. You can manage backups from within GPMC using the Manage Backups dialog box, described later in the "Managing Backups" section.
Administrators can backup one or more GPOs using the following methods:
Right click a GPO under the Group Policy objects node and choose Back up… from the context menu.
Right click one or more GPOs in the Contents tab of the Group Policy objects node and choose Back up… from the context menu. This will backup the selected GPO(s).
On the Group Policy Objects node, right click and choose the Back Up All… option. This will backup all GPOs in the domain. This is shown in the figure below.
Use GPO backup scripts. You can either write your own scripts, or you can use the sample scripts included with GPMC in the GPMC\scripts folder. There are two scripts BackupGPO.wsf and BackupAllGPOs.wsf that are included with GPMC that you can use to back up GPOs.
When you backup a GPO, you must supply the file system location, and optionally, a description for the backup.
The administrator should take precautions to secure this location to trusted administrators only. This should be done to protect the GPO backups from malicious or accidental tampering that could compromise the environment if they were used as the basis for a restore or import operation.
Backing up a GPO requires read access to the GPO and write access to the file system location where the backup will be stored.
GPMC provides a way to manage the GPO backups. This feature can be accessed in 2 ways:
Right-clicking on the Domains container and selecting Manage Backups from the context menu. This will show backed up GPOs for all domains and forests in the specified file system location.
Right-clicking on the Group Policy Objects container in a domain in GPMC and selecting Manage Backups. This will only show GPOs backed up for that domain in the specified file system location.
Either method of starting Manage Backups will provide a dialog box for selecting the location of your stored GPO backups. Select a file system location containing valid GPO backups. Figure 20 shows the Manage Backups dialog box.
In the Manage Backups dialog box, you can sort, delete, restore, and view the backup settings for GPOs. Note the check box that gives the user an option to only show the latest version for each backed up GPO. The dialog box displays the originating domain for the GPO, the display name of the GPO, the timestamp when the GPO was backed up, a user supplied description when the backup was taken, and the GPO GUID.
Upon selecting either the “Restore” or “Delete” buttons, the user is presented with a confirmation dialog box before the operation is performed. Selecting the “View Settings…” button opens a new instance of the user’s default web browser which displays a report of the settings in the selected GPO. Selecting “Browse” allows the user to choose the backup location. It is possible to select multiple GPOs for deleting but not for viewing or restoring.
GPO backups can also be managed from script. The sample script QueryBackupLocation.wsf, in the GPMC\Scripts folder, will display information about backups stored in a particular file system location.
Restoring a GPO restores the GPO to a previous state. A restore operation can be used in both of the following cases: the GPO was backed up but has since been deleted, or the GPO is live and you want to roll back to a known previous state. A restore operation retains the original GPO GUID even if the restore is recreating a deleted GPO. This is a key difference between the restore operation and the import or copy operations discussed in later sections of this white paper.
A restore operation replaces the following components of a GPO:
ACLs on the GPO.
WMI filter links (but not the filters themselves).
The restore operation does not restore links to a SOM (Scope of Management). Any existing links will continue to be used, for example, when restoring an existing GPO to a previous state. However, if the user has deleted a GPO and all links to the GPO, the user must add these links back after restoring the GPO. To facilitate recreating these links, you can view the report in the backup to identify all links in the domain of the GPO.
You can restore GPOs using any of the following methods:
To restore an existing GPO, right-click the GPO in the Group Policy objects container and select Restore from Backup… This opens the Restore Group Policy Object Wizard.
To restore a GPO that has been deleted since it was backed up, use the Manage Backups dialog box (refer to Figure 20 in the Managing Backups section).
Use GPO restore scripts. You can either write your own scripts, or you can use the sample scripts included with GPMC in the GPMC\scripts folder. There are two scripts RestoreGPO.wsf and RestoreAllGPOs.wsf that are included with GPMC that you can use to restore GPOs.
There is also an option to view the settings in the backup before restoring.
The permissions necessary to perform a restore of a GPO are different for restoring an existing GPO or if you are restoring a GPO that has been deleted since it was backed up.
|GPO State||Permissions needed|
The user must have Edit settings, delete, and modify security permissions on the GPO in order to restore it, as well as read access to the file system location where the backup is stored. Notice that this does NOT require GPO creation rights.
The user must have the right to create GPOs in the domain, as well as read access to the file system location where the backup is stored. The person that performs the restore will become the new creator owner for the GPO.
When restoring a GPO, GPMC will handle the GPO version number differently depending on the type of restore.
Restore of existing GPO: The GPO version number is incremented by one over the existing version number of the live GPO. This is done to guarantee that clients will apply the GPO.
Restore of a previously deleted GPO: The GPO version number in the GPO backup is retained in the restored GPO.
Special Considerations for Software Installation GPOs
When restoring a deleted GPO that contains Software Installation settings, some side effects are possible depending on the circumstances under which the GPO is restored. This section describes those side effects and how you can avoid them.
When restoring a GPO that has been deleted, it is possible that:
Cross-GPO upgrade relationships that upgrade applications in the GPO being restored, if any, are not preserved after restore. A cross-GPO upgrade is one where the administrator has specified that an application should upgrade another application, and the two applications are not deployed in the same GPO. Note that cross-GPO upgrade relationships are preserved when applications—in the GPO being restored—upgrade applications in other GPOs.
If the client has not yet seen that the GPO has been deleted (either because the user has not re-logged on or rebooted since the deletion of the GPO), and the application was deployed with the option to “Uninstall this application when it fall out of scope of management,” then the next time the client logs on:
Published apps that the user has previously installed will be removed.
Assigned applications will be uninstalled before re-installation.
This behavior occurs because when the GPO is restored, the object in Active Directory that represents the application (the "deployment object") is assigned a new GUID. Because the GUID is different than the GUID of the original deployment object, Windows interprets this as a different application.
The solution is to restore the GPO using the original GUID for the deployment object. However, because the GUID is controlled by Active Directory, the only way to re-use the original GUID is to re-animate the tombstone of the deleted deployment object. Tombstone re-animation is a new feature of Windows Server 2003.
GPMC automatically attempts to re-animate these objects when performing a restore. Re-animation will succeed if each of the following is true:
GPMC is targeting a domain controller that is running Windows Server 2003.
The user performing the restoration has permissions to re-animate objects in the domain. By default, only Domain Admins and Enterprise Admins have this permission. You can delegate this right to additional users at the domain level using the ACL editor.
The time elapsed between deletion and restoration of the GPO does not exceed the tombstone lifetime specified in Active Directory.
If re-animation fails, a new deployment object will be created and the previously mentioned side effects will occur.
Therefore, as a general rule, if you deploy software using Group Policy, it is recommended that you perform the restoration of GPOs that contain application deployments using a domain controller running Windows Server 2003 and that you grant the tombstone re-animation right to the users who will be performing restoration of those GPOs.
Considerations for Domain Rename
GPO Backups taken prior to a domain rename operation cannot be restored after a renaming a domain. If you are renaming a domain, be sure to backup your GPOs as soon as you complete the rename procedure. For more details on domain rename, see the documentation on Domain Rename at https://www.microsoft.com/windowsserver2003/downloads/domainrename.mspx.
The Import operation transfers settings into an existing GPO in Active Directory using a backed up GPO in the file system location as its source. Import operations can be used to transfer settings across GPOs within the same domain, cross-domain in the same forest, or cross-domain in a separate forest.
Import operations are ideally suited for migrating Group Policy across environments where there is no trust. For example, if you have separate test and production forests with no trust, you can use import operations to migrate GPOs that you develop and verify in the test forest to the production environment. You need to be able to access a file system location from the production environment where the backed up GPOs are stored. Depending on the settings in the GPO, you may also want to use a migration table (described later in this paper) to effectively transfer the settings.
The target of an import operation is an existing GPO. The target GPO’s ACLs, links to any SOMs, and link to a WMI filter are not modified during an Import operation. Importing a GPO requires edit permissions on the target GPO.
Import operations can be performed using either of the following methods:
Right click a GPO under the Group Policy Objects node and click Import Settings. This starts a wizard that guides you through the process of selecting a backup and optionally specifying a migration table if appropriate.
Using either the ImportGPO.wsf or ImportAllGPOs.wsf scripts that are included with GPMC.
A copy operation transfers settings using an existing GPO in Active Directory as the source and creates a new GPO as its destination. A copy operation can be used to transfer settings to a new GPO either in the same domain, cross-domain in the same forest, or cross-domain in a separate forest. Since a copy operation uses an existing GPO in Active Directory as its source, trust is required between the source and destination domains, or you must use the Stored User Names and Passwords tool as described earlier in the section “Managing Multiple Forests,” to gain access to the untrusted forest. Copy operations are ideally suited for migrating GPOs between production environments, as well as for migrating Group Policy that has been staged and tested in a test domain or forest to a production environment.
Copying a GPO requires GPO creation rights in the target domain and read access to the source GPO.
When copying a GPO, the administrator has two options for specifying the DACL to use on the destination GPO:
Use the default permissions that are used when creating new GPOs.
Preserve the DACL from the source GPO. Note that if a migration table (described in the next section) is specified during the copy operation, the migration table will apply to any security principals in the DACL.
There are some minor differences between same-domain and cross-domain copy operations.
When copying a GPO within the same domain, any link to a WMI filter is preserved. However, when copying a GPO to a new domain, the link is dropped because WMI filters can only be linked to GPOs within the same domain.
When copying a GPO within the same domain, any link to an IPSec policy is preserved. However, when copying a GPO to a new domain, the link is dropped because it is unknown whether a corresponding IPSec policy exists in the new domain, and it is not always desirable to link to the original IPSec policy in the original domain.
When copying a GPO within the same domain, the user is presented with a simple choice of choosing the DACL. However, for cross-domain copy operations, GPMC presents a wizard to facilitate the operation. In the cross-domain case, the user has the ability to specify a migration table (described below).
Copy operations can be performed using any of the following methods:
Right-click the source GPO and choose copy, and then right-click the Group Policy Objects container in the desired destination domain and choose the paste option.
Using drag and drop to drag the source GPO to the Group Policy Objects container in the destination domain.
Using the CopyGPO.wsf command-line script that is included with GPMC.
Using migration tables to facilitate cross-domain import and copy operations
This section discusses the use of migration tables to facilitate cross-domain import and copy operations.
The key challenge when migrating GPOs from one domain to another is that some information in the GPO is actually specific to the current domain where the GPO is defined. When transferring the GPO to a new domain, it may not always be desirable, or even possible, to use the exact same settings. Items that can be specific to a domain include references to security principals (users, groups, and computers) and UNC paths. The solution is to modify these references in the GPO that are domain-specific, during the import or copy operation, so that the settings in the destination GPO are written with the appropriate information for the destination domain. GPMC supports this capability using migration tables.
A migration table is a file that maps references to users, groups, computers, and UNC paths in the source GPO to new values in the destination GPO. The migration table consists of one or more mapping entries. Each mapping entry consists of a source type, source reference, and destination reference. If you specify a migration table when performing an import or copy, each reference to the source entry will be replaced with the destination entry when writing the settings into the destination GPO. Note to use a migration table, the security principals specified in the destination entries of the migration table must already exist when you perform the import or copy operation.
The migration table will apply to any references in the settings within a GPO, whether you are performing an import or copy operation. In addition, during a copy operation, if you choose the option to preserve the ACL on the GPO, the migration table will also apply to both the ACL on the GPO and the ACLs on any software installation settings in the GPO.
Migration tables have their own file name extension, .migtable. The mapping information is stored as XML. You can create and edit migration tables using the Migration Table Editor (MTE) described later in this section. A sample migration table file is included with GPMC installation at “%ProgramFiles%\GPMC\Scripts” as SampleMigrationTable.migtable.
Which settings are impacted by Migration Tables:
There are two types of settings that may not transfer well across domains:
Users, groups, and computers (security principals) that are referenced in the settings of the GPO, and optionally for copy operations, in the DACL for the GPO itself and the DACL for any software installation settings in the GPO. Security principals don’t transfer well for several reasons:
Domain local groups are never valid in external domains.
If there is no trust between source and destination domains, then none of the security principals in the source domain will be available in the destination domain.
Even in situations with trust between source and destination domains, it may not always be appropriate to use the exact same group in the new domain.
UNC paths. When you are migrating GPOs from test to production, users in the production environment may not have access to paths in the test environment, and vice versa.
The following items can contain security principals and can be modified using a migration table:
Security policy settings of the following types:
User rights assignment
Advanced folder redirection policy settings.
The GPO DACL, if you choose to preserve it during a copy operation.
The DACL on software installation objects – only preserved if the option to copy the GPO DACL is specified.
The following items can contain UNC paths, which can be updated to new values as part of the migration process:
Folder redirection policy settings.
Software installation policy settings (for software distribution points).
Pointers to scripts deployed through Group Policy (startup, shutdown, logon, and logoff) that are stored outside the GPO. Note that the script itself is not copied as part of the GPO copy operation, unless the script is stored inside the source GPO.
Note that security principals and UNC paths referenced in other types of settings not mentioned above, such as Administrative Templates and Software Restriction Policies, cannot be mapped using migration tables.
Options for specifying migration tables
Migration tables are specified when performing import and copy operations. There are three options for using migration tables with import and copy:
Do not use a migration table. This option will copy all references in the source GPO exactly as is.
Use a migration table. This option will map any references in the GPO that are in the migration table. References in the source GPO that are not contained in the migration table will be copied as is.
Use a migration table exclusively. This option requires that all references to security principals and UNC paths be specified in the migration table. If a security principal or UNC path is referenced in the source GPO and is not included in the migration table, the import or copy operation will not proceed. This option is useful to ensure you have accounted for all security principals and UNC paths in your migration table.
In addition, cross-domain copy operations will apply the migration table to the DACL on the GPO (and any software installation settings) if you choose the option to “Preserve or migrate the existing permissions” and you specify a migration table.
When performing a copy or import, the wizard will scan the source GPO or backup to determine if there are any references to security principals or UNC paths in the GPO. If there are, you will have the opportunity to specify an existing migration table or to create a new migration table. Note that during cross-domain copy operations, if you specify the option to “Preserve or migrate the permissions on the GPO”, the wizard will always present the opportunity to specify a migration table, since a DACL by definition contains security principals.
Creating Migration Tables
The Migration Table Editor (MTE) in GPMC allows the user to create and edit migration tables .You can open the MTE using any of the following methods:
From either the Import Settings or Cross Domain Copying wizards
By right clicking the Group Policy Objects node in any domain and choosing Open Migration Table Editor.
From the Domains node in any forest and choosing Open Migration Table Editor.
By double clicking an existing .migtable file in Explorer.
By manually running the program at %programfiles%\gpmc\mtedit.exe.
A migration table consists of one or more mapping entries, as shown in Figure 21 below. Each mapping entry has three pieces of information: Source type, source name, and destination name.
Source Type: The type of domain-specific information in the domain for the source GPO. Migration tables support the following types:
Domain Local Group
Domain Global Group
Free Text or security identifier (SID). Note: This category is only for use with security principals that are specified as free text and raw SIDs.
Source Name: The exact name of the User, Computer, Group or UNC Path referenced in the source GPO. The type of the source name in the source GPO or backup must match the source type specified in the migration table. Security principals can be specified using any of the following formats:
UPN. For example, "firstname.lastname@example.org".
SAM. For example, "example\someone".
DNS. For example, "example.com\someone".
Free text. For example, "someone". You must specify the type as Free Text or SID in this case.
SID. For example, S-1-11-111111111-111111111-1111111111-1112. You must specify the type as Free Text or SID in this case.
Destination Name: The destination name specifies how the name of the User, Computer, Group or UNC Path in the source GPO should be treated upon transfer to the destination GPO. There are four choices:
Same as source. Copy without changes. Equivalent to not putting the source value in the migration table at all. If specified, the destination entry will appear as <Same As Source> in the MTE.
None. Removes the User, Computer or Group from the GPO. If specified, the destination entry will appear as <None> in the MTE. This option cannot be used with UNC paths.
Map by relative name. For example, map SourceDomain\Group1 to TargetDomain\Group1. If specified, the destination entry will appear as <Map by Relative name> in the MTE. This option cannot be used with UNC paths.
Explicitly specify value. In the destination GPO, replace the source value with the exact literal value specified in the migration table. The same format for destination entries is supported as for source names, except that raw SIDs cannot be specified.
To add entries in the migration table using MTE, you can either manually type in the appropriate information or you can scan an existing GPO or GPO backup to auto-populate existing security and UNC paths in the source column. When using the auto-population methods, the destination will be set to <Same as Source> by default. The user must then adjust the destination entries in the MTE.
GPMC users can also create migration table files using the CreateMigrationTable.wsf script included with GPMC. This script performs an auto-populate operation that is available in the MTE. The user must then edit the file manually to set the target ACLs and paths. Alternatively, you can create a migration table manually using any XML editor.
Scenarios for Copy and Import
There are two key scenarios GPMC enables with the copy and import operations .
The test-to-production scenario is usually a multi-forest environment with separate forests for test and production which are often physically isolated. In this scenario, all groups, users, and computers in all domains will likely need to be mapped.
Sometimes there is a trust between the forests while other times there is not. GPMC handles either scenario, and typically a migration table will be required. In cases with no trust, all security principals and UNC paths must be mapped using a migration table. Also, if there is no trust, you must either use import, or if using copy, you must supply alternate credentials using the Stored User Names and Passwords tool as described earlier in the section “Managing Multiple Forests,” to gain access to the untrusted forest.
Assume for this scenario that the administrator wants to copy or import GPO X in domain B in the TEST forest to Domain E in the PRODUCTION forest. GPO X contains security settings such as the Log on locally setting under User Rights Assignment that reference security principals throughout the TEST forest. These security principals may reside in the same domain as the GPO or potentially in different domains in the TEST forest. In the drawing above, these security principals are represented as A\user, A\group, etc, where “A” is the domain, and “user” is the relative name of the security principal.
In this scenario, when copying GPO X to the new domain, the administrator will want to map all security principals that are referenced in the GPO. At a minimum, the domain prefix will need to change and potentially the relative names as well.
This scenario can be handled by using a migration table.
The production-to-production scenario has all domains in production environments and there is a trust between the source and target domains. The diagram below assumes A, B, and C are all production domains in the same forest. Note that you could also have this scenario across forests provided there was a trust in place.
Assume for this scenario that the administrator wants to copy GPO X from production domain B to production domain C. There are potentially two alternative behaviors that are desired in this scenario:
Retain all references to security principals in the copied GPO. Functionally, this would be equivalent to cross-linking GPO X to domain C (in terms of the settings that are applied from the GPO). This scenario is handled when you choose no migration table.
Map some or all of the security principals to new values. For example for security principals defined in domain B, it may make sense to map them to domain C when copying the GPO from B to C. In particular, and domain local groups must be mapped. However, it probably makes sense to leave references defined in domain A as is. This scenario can also be handled using a migration table.
Creating a Staging Environment
Most administrators will want to deploy Group Policy to a test environment before introducing it to their production environment. Deploying Group Policy ideally requires the following steps:
Gather management requirements for the target platform.
Determine what management tasks can be done through Group Policy.
Test Group Policy in staging environment.
Use GPMC to migrate Group Policy to production environment.
GPMC can be used for planning, creating, testing, and migrating the Group Policy environment.
For best results, you should have a test environment that closely resembles the production environment, in terms of domains, OUs, GPOs, and groups. Using this test environment, you can test and validate changes to your policy deployment in a controlled, isolated manner that does not impact production users. Once the change has been validated, you can use the import and/or copy functions to migrate the GPOs to production.
Creating a staging environment that closely resembles the production environment is essential for this task. GPMC facilitates this by providing two sample scripts that help you create a new test environment, based on an existing environment.
CreateXMLFromEnvironment.wsf: This script uses the information in a live domain to generate an XML file and a set of GPO backups that represent the policy information for that domain. The XML file captures information such as OU structure, groups and users, GPOs and the settings contained in them, links to GPOs, security on GPOs, and WMI filters. By running this script against a production domain, you can capture the essential policy information for that domain for later re-use.
CreateEnvironmentFromXML.wsf: This script populates a domain with policy information such as OU structure, groups, and users, GPOs and the settings contained in them, links to GPOs, security on GPOs, and WMI filters using an XML file and a set of GPO backups referenced in the XML. The XML file required as the input for this script can be generated using the previous script. By using this second script in conjunction with the XML file previously generated, you can replicate the contents of one domain to another.
For more details on using these two scripts, see the chapter, “Staging Group Policy Deployments” in the Windows Server 2003 Deployment Kit.