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.
Migration Tables
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.
rlogan October 18, 2004 (Article Rating: