Migrating Group Policy Objects between Domains

For years , I've stood in front of large audiences and recommended testing the power of GPOs in a test forest. In return, I'd get blank stares because this advice was inherently impractical . Sure, it was safesafer than testing GPOs in productionbut ultimately my advice was doomed. How can you do the hard work in a test domain, test it, debug it, get it all right, and then lift it out of its home domain and put it in production? Answer? You couldn't. Until now.

These examples will continue with our fictional multidomain environment. You can flip back to Figure 3.6 to see the relationship between our three domains: corp.com, widgets.corp.com, and the Cross-Forest Trust between bigu.edu and corp.com.

Basic Interdomain Copy and Import

Now using the GPMC, you can take existing GPOs from any domain and copy them to another domain. The target domain can be a parent domain, a child domain, a cross-forest domain, or a completely foreign domain that has no trusts! Both the Copy and the Import operations transfer only the policy settings; these operations do not modify either the source or the destination links of the GPOs.

The Copy Operation

The interdomain Copy operation is meant to be used when you want to copy live GPOs from one domain to another. That is, you have two domains, connectivity between them, and appropriate rights to the GPOs. To copy the GPO, you need "Read" rights on the source GPO you want to copy and "Write" rights in the target domain.

First, you want to tweak your GPMC console so that you can see the two domains you want.

Note

Recall that to add new domains to the GPMC, you simply right-click "Domains" and choose "Show Domains" from the shortcut menu to open up the Show Domains dialog box. Then simply select the domains you want to see. To add other forests, right-click "Group Policy Management" and choose "Add Forest" from the shortcut menu to open the "Add Forest" dialog box. You can then enter the name of the forest in the field labeled "Domain" (yes, domain!).

In this first example, we'll copy a GPO from corp.com to widgets.corp.com. An enterprise administrator will have rights in all domains. Since we're logged in as an enterprise administrator, we have rights in both corp.com (to read) and widgets.corp.com (to write.) Follow these steps:

In the Group Policy Objects container, right-click the GPO you want to copy, as shown in Figure A.1 For this example, I've chosen the "Hide Settings Tab/Restore Screen Saver Tab" GPO.
Adjust your view of the GPMC so that you can see the target domain. In Figure A.2, I've minimized the view of corp.com and expanded widgets.corp.com especially the Group Policy Objects container.
Right-click the target domain's Group Policy Objects container, and choose "Paste" to start the "Cross-Domain Copying Wizard."
Click Next to bypass the initial splash screen and open the Specifying Permissions screen, as shown in Figure A.2.

Figure A.1: You can copy a GPO from the Group Policy Objects container.

Figure A.2: When you paste a GPO, you can choose how to handle permissions.

You can now choose to create a GPO with the default permissions or copy the original permissions to the new GPO. The latter might be useful if you've delegated some special permissions to that GPO and don't want to go through the hassle of redoing your efforts. Most of the time, however, the first option is fine. You can now zip through the rest of the wizard.

Note	You might see a message about Migration tables. Don't fret; they're right around the corner. For this specific GPO, you won't need Migration tables, so it won't be an issue.

Warning

If you copy a GPO between domains, the WMI filtering is lost because the WMI filter won't necessarily exist in the target domain.

The Import Operation

In the previous scenario, we copied a GPO from corp.com to widgets.corp.com. We did this when both domains were online and accessible. But if you are working on an isolated testing network, this won't be possible. How then do you take a GPO you created in the isolated test lab and bring it into production? First, create a backup as described in Chapter 2. You'll then have a collection of files that you can put on a floppy, a CD, and so on and take out the door of your test lab into the real world. You can then create a brand new GPO (or overwrite an existing GPO) and perform the import! Follow these steps:

A Word about Drag and Drop

Dragging and dropping a GPO from one domain into another domain can be hazardous! For example, your intention is to copy a GPO named "Restrict Solitaire" from the GPO container in widgets.corp.com to the Human Resources Users OU in corp.com. It looks like it's going to make sense: you set up your view in the GPMC to show both domains, you can see the Group Policy Objects container in widgets.corp.com, and you can see the Human Resources Users OU in corp.com. Then, you drag and drop, and you're asked the following question:

If you click OK, you're not actually copying! Indeed, you're performing a no-no! You are creating a cross-domain link to the GPO, as you can see when you click the Details tab of the GPO:

In this example, the "Domain" field shows that it "lives" in widgets.corp.com, even though the GPO is linked to an OU in corp.com.

Whenever a GPO is linked from across a domain, the GPO must be pulled from a Domain Controller that actually houses it. If it's across the WAN, so be it. And that could mean major slowdowns.

The moral of the story is to be sure you're copying (as described earlier) and not just linking.

Right-click the Group Policy Objects container, choose New from the shortcut menu to open the "New GPO" dialog box, and in the Name Field enter the name of a new GPO.
Right-click that GPO and choose Import Settings from the shortcut menu, as shown in Figure A.3. This then starts the Import Settings Wizard.

Tip
Anyone with "Edit" rights on the GPO can perform an Import.

Warning
You can choose to overwrite an existing GPO, but that's just it. It's an overwrite, not a merge. So, be careful!
The wizard then presents the "Backup GPO" screen, which allows you to back up the newly created GPO; however, this is unnecessary. This is a safety measure should you decide to overwrite an existing GPO. You can then click Next to see the "Backup Location" screen.
In the "Backup Location" screen, use the Backup folder field to input the path to where your backup set is and select Next. The "Source GPO" screen will appear as seen in Figure A.4.
At the "Source GPO" screen, select the GPO from which you want to import settings, as shown in Figure A.4 and click Next.

Figure A.3: You can import the settings and overwrite an existing GPO.

Figure A.4: Select a GPO from which you want to import settings.

You should now be able to zip through the rest of the wizard. Ignore any references to Migration tables; they're coming up next.

Copy and Import with Migration tables

In the previous examples, we migrated the very simple GPO named "Hide Settings Tab/Restore Screen Saver Tab." That particular GPO contained only Administrative Template settings that affected the desktop. Nothing fancy, for sure.

However, certain policy settings do perform some fancy footwork. Some GPOs can include references to security groups, such as "Allow Log on Locally." Other GPOs can include references to UNC paths, such as Folder Redirection. Indeed, an Advanced Folder Redirection policy setting contains both security group references and UNC path references! Other possibilities include Restricted Groups, Group Policy Software Installation policy settings, and pointers to scripts.

When you migrate GPOs across domains, you need to take care of these references. Copying a GPO in one domain that redirects folders to the \\WinDC01\Data folder will not likely make much sense when used in another domain.

With that in mind, both the Copy and Import functions can leverage Migration tables. Migration tables let you rectify both security group and UNC references that exist in a GPO when you transfer the GPO to another domain. You'll be given the opportunity to use the Migration tables automatically if your Copy or Import operation detects that a policy setting needs it! After the GPO is ready to be copied or imported, you'll be notified that some adjustments are needed. It's that easy!

In the Migrating References screen of the wizard (as shown in Figure A.5), you can choose two paths here:

Selecting "Copying them identically from the source" can be risky. Again, you won't know what the source is using for security groups or UNC paths. The existing security groups and UNC paths may be valid, but they may not be.
Selecting "Using this migration table to map them in the destination GPO" gives you the opportunity to choose an existing Migration table (if you have one), or you can click the New button to open the Migration Table Editor and create on the fly.

Figure A.5: A migration table can smooth the bumps between domains.

To start, use a new blank migration table (after pressing the New button) and follow these steps:

If you're performing a Copy, choose Tools ˜ Populate from GPO to open the Select GPO screen, then simply select the live GPO. If you're performing an Import, choose Tools ˜ Populate from Backup to open the "Select Backup" dialog, which allows you to select a GPO from backup.
Choose the GPO you're copying or importing to display a list of all the references that need to be corrected.
In Figure A.5, you can see both the Source Name and Destination Name fields. The Source name field will automatically be filled in. All that's left is to enter in the Destination Name UNC path for the new environment and you're done!
Save the file (with a.migtable extension), and close the "Migration Table EditorNew" screen.
Back at the Migrating References page, simply click Browse and choose the Migration table you just made.

Before clicking the Next button, you can optionally choose the check box that begins with "Use migration table exclusively." In this example, we have but one UNC reference that needs to be rectified. You might have a meaty GPO with 30 UNC paths and another 50 security principles that need to be cleared up. Perhaps you can't locate all the destination names . If you select this check box, the wizard will not proceed unless all the paths in the destination name are valid. Use this setting if you really need to be sure all settings will be verified successfully.

When ready, click Next, click Next again past the summary screen, and you're finished.

Microsoft has a detailed white paper you'll want to check out if you're planning to do a lot of this. You'll find it at www.microsoft.com/windowsserver2003/gpmc/migrgpo.mspx .