Whether you have been running Active Directory for a long time or are just deploying Active Directory in your enterprise, you must consider the effects of GPOs within the organization. We have spent the majority of this chapter talking about what to consider and have outlined some best practices for Group Policy design and deployment.
Before you deploy any Group Policy settings to production computers, you must develop a strategy to test the settings to ensure that they produce the desired results. Ideally, you should have a test environment that closely resembles your production environment—including domain controllers, domain members, operating systems, resource servers, network bandwidth, and so forth. You use the test network to try out your Group Policy settings before they go into production.
Your test network should be in a separate forest from the production forest. The test forest should be a mirror image of the production forest to allow for full interaction between operating systems, servers, services, applications, and network devices. For security reasons, there should not be a trust relationship between the test forest and the production forest.
Because the two forests may contain multiple domains, you should track which domain the GPO is tested in. You should also test GPOs with the correct computer account, user account, and group accounts in mind. Many GPO settings rely on these accounts to allow access or configure restrictions. This tracking is essential during the testing and migration phase because these objects have security identifiers (SIDs) associated with them, and the computer uses this value to track the accounts throughout the entire forest. Because the two forests have different SIDs, you must ensure that test domain accounts are translated into the production domain accounts as you migrate GPOs from one domain to the other.
More Info
For more information on using the GPMC to migrate GPOs from one domain or forest to another, see Chapter 3.
In some instances, you may have a GPO in one of your domains that you want to migrate to another domain or forest. This is common because GPOs are initially tested and placed into production for one domain. After the GPO has proven to be stable and provides the correct settings, you can deploy it in other domains and forests.
Because the GPO is migrated from one domain to another, the SIDs for the accounts must also be translated, even if the GPO is being migrated from one domain to another within the same forest. The reason for this is that each domain has its own unique list of accounts with unique SIDs.
Migration tables are used to tell the GPMC how domain-specific data should be treated during migration of GPOs. Migration tables are required because some of the data in a GPO is unique to the domain and might not be valid if copied directly to another domain. The tables are stored with the file extension .migtable and are formatted as XML files.
Within the migration table, the computer, user, group, and UNC paths are mapped from the old value to a new value specific to the target domain. Migration tables require at least one mapping entry, but typically have more than one. Each mapping entry consists of a source type, source reference, and destination reference. The migration table is referenced when a GPO is imported or copied; each reference to a source entry is replaced with the destination entry when the settings are written into the destination GPO.
The GPMC makes it easy to import or copy GPOs from one domain to another. The key challenge when migrating GPOs is that some information in the GPO is unique to the domain in which the GPO was originally defined. This can cause issues in the target domain if these settings are not modified beforehand in some manner to reference the new domain. Items that can be specific to a domain include user, group, and computer accounts, as well as UNC paths.
The following GPO settings may contain computer, user, or group references and should be translated during migration:
Security policy settings
User Rights Assignment
Restricted Groups
System Services
File System
Registry
Advanced folder redirection policy settings
DACL on the GPO
Only if you are using security filtering and want to preserve it during the migration
DACLs on software installation packages
Only if the DACL has been configured from the default.
These DACLs are preserved only if the option to copy the GPO DACL is specified.
In addition, the following settings might contain UNC paths. The UNC paths from one domain to the next differ based on server name and share name.
Folder redirection policy settings
Software installation policy settings
Scripts
Logon and logoff
Startup and shutdown
Caution
A few GPO settings under the administrative template section of a GPO can’t be mapped using migration tables. These settings must be migrated as is and then modified after the migration. To get more information on these settings and migration tables, refer to http://www.microsoft.com/windowsserver2003/gpmc/migrgpo.mspx.
Migration tables store mapping information for GPO settings as XML files having the file extension .migtable. You can create migration tables manually, but it is more efficient to use the Migration Table Editor, a component of the GPMC. The Migration Table Editor allows you to create, view, and edit migration tables for migration of any GPO.
The migration table files contain only three variables for you to enter: source name, source type, and destination name. Figure 4-4 shows a migration table in the Migration Table Editor using the GPMC.
The source type describes the type of domain-specific information for the source GPO. The following source types are supported in migration tables:
User
Computer
Domain local group
Domain global group
Universal Group
UNC Path
Free Text or SID (This category is for use only with security principals that are specified as free text or raw SIDs.)
Note
The built-in groups (such as Administrators and Account Operators) that are common to all domains have the same SID regardless of the domain. If references to built-in groups are stored in the GPO using their underlying SID, they cannot be mapped in a migration table. If the references to built-in groups are stored as free text, they can be mapped using the Free Text or SID source type.
The source name indicates which setting exists in the GPO as the GPO is migrated from one domain to another. The source reference is the specific name of the computer, user, group, or UNC path used in the source GPO. The source name format must match the source type for each entry in the migration table. Table 4-1 contains examples of source names and their syntax.
The destination name is the final entry in the migration table. It specifies how the name of the computer, user, group, or UNC path in the source GPO should be treated upon transfer to the destination GPO. Table 4-2 shows some descriptions of destination names.
Table 4-2. Destination Names
Destination Name | Description |
|---|---|
Same as source | Copy without changes. Equivalent to not putting the source value in the migration table. |
None | Removes the user, computer or group from the GPO. This option cannot be used with UNC paths. |
Map by relative name | For example, map SourceDomainGroup1 to TargetDomainGroup1. This option cannot be used with UNC paths. |
Explicitly specify value | In the destination GPO, replace the source value with the exact literal value you specify. |
Note
You can specify security principals for destination names using any of the formats described above in the source reference table, except for using a raw SID. You can never use a raw SID for the destination name.
More Info
For more information on the steps required to migrate GPOs using the GPMC and migration tables, see "Testing GPOs Before Deployment" in this chapter.