How Group Policy Management Console Works

Article
10/08/2009

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

How Group Policy Management Console Works

Administrators use Group Policy Management Console (GPMC) to manage Group Policy. An administrator must have an Active Directory environment to use GPMC to manage Group Policy. In an ideal environment, the clients are running Windows XP while the servers are running Windows 2003. However, GPMC can also be used to manage Windows 2000 domains.

In this section

Group Policy Management Console Architecture
Group Policy Management Console Interfaces
Group Policy Management Console Processes and Interactions
Related Information

Group Policy Management Console Architecture

GPMC is one of three administrative tools used to manage Group Policy. The following diagram shows all three of those tools, as well as the domain controller and a client. In addition, the diagram describes the different communication protocols being used by each tool (LDAP, SMB, RPC/COM, DNS), the interactions between the tool, the domain controller and the client, and whether those interactions are READ (lines with a single arrow head) or READ/WRITE (lines with double arrow heads).

Group Policy Management Console Architectural Diagram

GP Management Console Architectural Diagram

Components of Group Policy Management Console Architectural Diagram

Component	Description
Group Policy Management Console (GPMC)	GPMC makes Group Policy much easier to manage by providing a view of GPOs, sites, domains, and OUs across an enterprise. GPMC can be used to manage either Windows Server 2003 or Windows 2000 domains. GPMC simplifies the management of Group Policy by providing a single place for managing core aspects of Group Policy, such as scoping, delegating, filtering, and manipulating inheritance of GPOs. You can also back up GPOs to the file system as well as restore GPOs from backups. GPMC includes features that enable an administrator to predict how GPOs are going to affect the network as well as to determine how GPOs have actually changed settings on any particular computer or user. GPMC is capable of read and write access to the Sysvol using the SMB protocol. It is also capable of read and write access to Active Directory via the LDAP protocol. In addition, GPMC is capable of read access to the event log and RSoP infrastructure.
Server (Domain Controller)	In an Active Directory forest, the domain controller is a server that contains a writable copy of the Active Directory database, participates in Active Directory replication, and controls access to network resources. GPOs are stored in two parts of domain controllers: The Active Directory database and the Sysvol. In addition to storing the GPOs used in normal policy processing, GPMC and the RSoP snap-in use the domain controller and the RSoP infrastructure to simulate the application of policy across the network.
Active Directory	Active Directory, the Windows-based directory service, stores information about objects on a network and makes this information available to users and network administrators. Administrators link GPOs to Active Directory containers such as sites, domains, and OUs that include user and computer objects. In this way, policy settings can be targeted to users and computers throughout the organization. Prior to GPMC, administrators used property pages in various Active Directory administrative tools to manage Group Policy.
Sysvol	The Sysvol is a shared directory that stores the server copy of the domain’s public files, which are replicated among all domain controllers in the domain. The Sysvol contains the largest part of a GPO: the Group Policy template (GPT), which includes Administrative Template-based policy settings, security settings, script files, and information regarding applications that are available for software installation. File Replication Service (FRS) replicates this information throughout the network.
DNS/WINS	Domain Name Service (DNS) and Windows Naming Service (WINS) are network name services. Network name services are used to translate IP addresses to domain names. GPMC can use either DNS or WINS to locate domain controllers.
LDAP Protocol	Lightweight Directory Access Protocol (LDAP) is the protocol used by the Active Directory directory service. GPMC uses LDAP to access the directory store on the domain controller. The client computer on which Group Policy is processed also uses LDAP to read the directory store on the domain controller.
SMB Protocol	The Server Message Block (SMB) protocol is the primary protocol used for file and print sharing. SMB can also be used for named pipes and mail slots. GPMC uses SMB to access the Sysvol as well as back up and retrieve files to a remote file system. The client also uses SMB to read the sysvol on the domain controller.
DNS protocol /WINS protocol	Domain Name Service (DNS) protocol and Windows Internet Name Service (WINS) protocol are used for locating computers on a network by using hostnames instead of IP addresses. GPMC can use either to locate domain controllers.
RPC/COM	RPC (Remote Procedure Call), DCOM (Distributed Component Object Model) and COM (Component Object Model) enable data exchange between different processes. The different process can be on the same machine, on the local area network, or across the Internet. The various binary files that make up the GPMC components primarily use COM calls to communicate. The GPMC COM interfaces are also all scriptable so that an administrator can automate Group Policy Management. DCOM and RPC are used by GPMC for communication with the RSoP provider on the client or domain controller for Group Policy Results and Group Policy Modeling reports.
WMI	WMI is a management infrastructure that supports monitoring and controlling of system resources through a common set of interfaces and provides a logically organized, consistent model of Windows operation, configuration, and status. WMI makes data about a target computer available for administrative use. Such data can include hardware and software inventory, settings, and configuration information. For example, WMI exposes hardware configuration data such as CPU, memory, disk space, and manufacturer, as well as software configuration data from the registry, drivers, file system, Active Directory, the Windows Installer service, networking configuration, and application data. WMI Filtering in Windows Server 2003 allows you to create queries based on this data. These queries (also called WMI filters) determine which users and computers receive the policy configured in the GPO.
RsoP infrastructure	Group Policy processing information is collected and stored in a Common Information Model Object Management (CIMOM) database on the local computer. This information, such as the list of GPOs, as well as the content and logging of processing details for each GPO, can then be accessed by tools using WMI. With Group Policy Results in GPMC, or logging mode for the RSoP snap-in, the RSoP service is used to query the CIMOM database on the target computer; it receives information about the policies and displays it in GPMC or the RSoP snap-in. With Group Policy Modeling in GPMC, or planning mode for the RSoP snap-in, the RSoP service simulates the application of policy using the Group Policy Directory Access Service (GPDAS) on a Domain Controller. GPDAS simulates the application of GPOs and passes them to virtual client-side extensions on the Domain Controller. The results of this simulation are stored to a local CIMOM database on the domain controller before the information is passed back and displayed in either GPMC or the RSoP snap-in.
Group Policy Engine	The Group Policy Engine is a framework that handles common functionality across client-side extensions. GPMC does not communicate directly with the Group Policy Engine. For more information about the Group Policy Engine, see Core Group Policy Technical Reference.
Client-Side Extensions	Client-side extensions (CSEs) consist of one or more dynamic-link libraries (DLLs) that are responsible for implementing Group Policy at the client computer. CSEs typically correspond to snap-ins: Administrative Templates, Scripts, Security Settings, Software Installation, Folder Redirection, Remote Installation Services, and Internet Explorer Maintenance. GPMC does not communicate directly with the Client-side extensions. For more information about client-side extensions, see Group Policy Components.
File System	GPMC can write to the file system of the local machine or any remote machine. GPMC writes to the file system for GPO operations, such as backups or copy, and for saving HTML/XML reports.
Event Log	The Event log is a service that records events in the various logs on the computer. GPMC is capable of read and write access to the Event Log on client computers and domain controllers.
Local Group Policy object	The local Group Policy object (local GPO) is stored on each individual computer, in the hidden %systemroot%\System32\GroupPolicy directory. Each computer running Windows 2000, Windows XP Professional, Windows XP 64-Bit Edition, or Windows Server 2003 has exactly one local GPO, regardless of whether the computers are part of an Active Directory environment. GPMC does not offer access to the local GPO. For more information about the local Group Policy Object, see Core Group Policy Technical Reference.

Group Policy Management Console Interfaces

GPMC includes a set of programmable interfaces designed for use by administrators writing scripts, as well as programmers using languages such as Visual Basic or C++.

The following is a comprehensive list of all the Group Policy Management Console (GPMC) interfaces.

Comprehensive List of GPMC Interfaces

Interface	Description
IGPM	Accesses GPMC interfaces to retrieve GPMC information and to create objects. Manages and queries Group Policy objects (GPOs) and GPO links. Queries scope of management (SOM) objects.
IGPMAsyncCancel	Cancels an asynchronous GPMC operation, such as a backup, restore, import, copy, or report generation. The GPMC function called by the client will asynchronously return a pointer to the IGPMAsyncCancel interface. IGPMAsyncCancel is not available through scripting.
IGPMAsyncProgress	Enables client notification about the progress of an operation. Implemented by the client and passed as a parameter to GPMC methods that can run asynchronously. IGPMAsyncProgress is not available through scripting.
IGPMBackup	Retrieves properties of GPMBackup objects. Deletes GPMBackup objects
IGPMBackupCollection	Accesses a collection of GPO backups.
IGPMBackupDir	Queries GPO backups and GPO backup collections.
IGPMClientSideExtension	Queries client-side extension properties such as ID and display name.
IGPMConstants	Retrieves the values of GPMC constants.
IGPMCSECollection	Accesses a collection of client-side extension objects.
IGPMDomain	Queries SOM objects. Creates, restores, and queries GPOs. Creates and queries WMI filters. WMI filter queries use WMI Query Language (WQL).
IGPMGPO	Manages an individual GPO. Deletes, copies, imports, or backs up a GPO. Enables or disables user and computer configuration options. Sets security information. Retrieves multiple GPO properties for a given GPO and generates reports of the settings in the GPO.
IGPMGPOCollection	Accesses a collection of GPOs.
IGPMGPOLink	Manages a GPO link from a SOM. Sets and retrieves properties of GPO links, such as the link order or whether a link is enabled or enforced.
IGPMGPOLinksCollection	Accesses a collection of GPO links.
IGPMPermission	Retrieves permission properties.
IGPMResult	Retrieves status message information while performing GPMC operations on GPOs, such as restore, import, backup and copy.
IGPMRSOP	Queries Resultant Set of Policy (RSoP) in logging or planning mode. Generates RSoP reports.
IGPMSearchCriteria	Defines the criteria for search operations.
IGPMSecurityInfo	Defines the set of permissions that exist on a SOM, GPO or WMI filter. Removes or adds permissions.
IGPMSitesContainer	Queries SOM objects for particular sites in a forest.
IGPMSOM	Creates and retrieves GPO links for a SOM. Sets and retrieves security attributes and properties for a SOM.
IGPMSOMCollection	Accesses a collection of SOMs.
IGPMStatusMessage	Retrieves properties of status messages of GPO operations.
IGPMStatusMsgCollection	Accesses a collection of status messages.
IGPMTrustee	Retrieves information about a trustee that is a user, group, or computer in the domain.
IGPMWMIFilter	Sets or retrieves security attributes and properties of a WMI filter.
IGPMWMIFilterCollection	Accesses a collection of WMI filters.
IGPMMapEntry	Retrieves map entries.
IGPMMapEntryCollection	Accesses a collection of map entries.
IGPMigrationTable	Accesses a migration table.

For more information about GPMC interfaces, see MSDN.

Group Policy Management Console Processes and Interactions

This section defines how GPO operations are handled by GPMC, as well as important differences between how GPMC and Group Policy Object Editor handle Administrative template files.

GPO Operations in Group Policy Management Console

With Group Policy Management Console (GPMC) administrators can back up, restore, import, or copy Group Policy objects (GPOs). When copying or importing GPOs across domains, an administrator can use migration tables to facilitate the copy or import operation.

Backups

Backing up a Group Policy object (GPO) copies the data in the GPO to the file system. The backup function also serves as the export capability for GPOs. A GPO backup can be used to restore the GPO to the backed-up state, or to import the settings in the backup to another GPO. Because each backup is identified by a unique backup ID, multiple backups of the same or different GPO can be stored in the same file system location. The collection of backups in a given file system location can be managed using the GPMC or through the scriptable interfaces. When you open Manage Backups from the Group Policy Objects node in GPMC, the view is automatically filtered to show only backups of GPOs from that domain. When opened from the Domains node, all backups are displayed, regardless of which domain they are from.

Information saved in a backup

Backing up a GPO saves all information that is stored inside the GPO to the file system. This includes the following information:

GPO globally unique identifier (GUID) and domain.
GPO settings.
Discretionary access control list (DACL) on the GPO.
WMI filter link, if there is one, but not the filter itself.
Links to IP Security Policies, if any.
XML report of the GPO settings, which can be viewed as HTML from within GPMC.
Date and time stamp of when the backup was taken.
User-supplied description of the backup.

Information not saved in a backup

Backing up a GPO only saves data that is stored inside the GPO. Data that is stored outside the GPO is not available when the backup is restored to the original GPO or imported into a new one. This data that becomes unavailable includes the following information:

Links to a site, domain, or organizational unit.
WMI filter.
IP Security policy.

Restore

Restoring a Group Policy object (GPO) re-creates the GPO from the data in the backup. 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. The end effect is the same in either case, except as noted below in some cases for GPOs that contain software installation settings.

GPMC identifies the GPO by its domain and globally unique identifier (GUID). The purpose of a restore operation is to return the GPO to its original state, so the restore operation retains the original GUID even if it is recreating a deleted GPO. This is a key difference between the restore operation and the import or copy operations. You cannot use restore to transfer GPOs to different domains or forests. That capability is provided by import and copy.

Information replaced in a restore

A restore operation replaces the following components of a GPO:

GPO settings.
The Discretionary Access Control List (DACL) on the GPO.
WMI filter links (but not the filters themselves).

Information not replaced in a restore

The restore operation does not restore objects that are not part of the GPO. This includes the following:

Links to a site, domain, or organizational unit. Links are an attribute of the site, domain, or organizational unit, not the GPO. Any existing links in these containers will continue to be used, for example, when restoring an existing GPO to a previous state. However, if you have deleted a GPO and all links to the GPO, you must add these links back after restoring the GPO.
WMI filters. A GPO only contains a link to the WMI filter. If the WMI filter does not exist at the time of restore, the link will be dropped, otherwise the link will be restored.
IPSec Policies. A GPO only contains a link to the IPSec policy. If the IPSec policy does not exist at the time of restore, the link will be dropped, otherwise the link will be restored.

Permissions required to restore a GPO from backup

The permissions necessary to perform a restore of a GPO vary, depending on whether you are restoring an existing GPO or if you are restoring a GPO that has been deleted since it was backed up. Version numbers for the GPO are handled differently as well. The following table summarizes the situation for existing and deleted GPOs:

Permissions Required to Restore GPOs from Backup

GPO state	Permission needed to restore GPO from backup	GPO version number
Existing GPO	The user must have Edit settings, delete, and modify permissions on the GPO, as well as read access to the file system location where the backup is stored. This does NOT require GPO creation rights.	Incremented by 1, which will trigger client refreshes of settings from the GPO.
Deleted GPO	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.	Retained unchanged from the backed-up GPO.

Restoring GPOs with software installation settings

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.

When restoring a GPO that contains software installation settings, 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 in which the administrator has specified that an application should upgrade another application, and the two applications are not in the same GPO. Note that upgrade relationships are preserved when applications — in the GPO being restored — upgrade applications in other GPOs.
If the client computer has not yet detected that the GPO has been deleted (either because the user has not logged on again or rebooted since the deletion of the GPO), and the application was deployed with the option to Uninstall this application when it falls out of scope of management then the next time the user logs on:
- Published applications that the user has previously installed will be removed.
- Assigned applications will be uninstalled before re-installation.
This issue can be avoided if all of the following conditions are met:
- You perform the restore on a Windows Server 2003 domain controller instead of a Windows 2000 domain controller.
- The user performing the restore has permissions to re-animate tombstone objects in the domain.
- The time elapsed between deletion and restoration of the GPO does not exceed the tombstone lifetime specified in Active Directory.

Tombstone re-animation is a new feature of Windows Server 2003 Active Directory. By default, only Domain Admins and Enterprise Admins have this permission but you can delegate this right to additional users at the domain level using the ACL editor.

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.

Finally, when restoring a GPO that contains software installation settings, if you are using categories to classify applications, the application in the restored GPO will appear in its original category only if the category exists at the time of restoration. Note that the category definition is not part of the GPO.

Import

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 from one GPO to another GPO within the same domain, to a GPO in another domain in the same forest, or to a GPO in a domain in a different forest. The import operation always places the backed-up settings into an existing GPO. It erases any pre-existing settings in the destination GPO. Import does not require trust between the source domain and destination domain. Therefore it is useful for transferring settings across forests and domains that don’t have trust. Importing settings into a GPO does not affect its discretionary access control list (DACL), links on sites domains or organizational units to that GPO, or a link to a WMI filter.

When using import to transfer GPO settings to a GPO in a different domain or different forest, you might want to use a migration table in conjunction with the import operation. A migration table allows you to facilitate the transfer of references to security groups, users, computers, and UNC paths in the source GPO to new values in the destination GPO.

Copy

A copy operation allows you to transfer settings from an existing Group Policy object (GPO) in Active Directory directly into a new GPO. The new GPO created during the copy operation is given a new globally unique identifier (GUID) and is unlinked. You can use a copy operation to transfer settings to a new GPO in the same domain, another domain in the same forest, or a domain in another forest. Because a copy operation uses an existing GPO in Active Directory as its source, trust is required between the source and destination domains. Copy operations are suited for moving Group Policy between production environments, and for migrating Group Policy that has been tested in a test domain or forest to a production environment, as long as there is trust between the source and destination domains.

Copying is similar to backing up followed by importing, but there is no intermediate file system step, and a new GPO is created as part of the copy operation. The import operation, in contrast with the copy operation, does not require trust.

Specifying the discretionary access control list (DACL) on the new GPO

You have two options for specifying the DACL to use on the new GPO:

Use the default permissions that are used when creating new GPOs.
Preserve the DACL from the source GPO. For this option, you can specify a migration table, used to facilitate the transfer of references to security groups, users, computers, and UNC paths in the source GPO to new values in the destination GPO. If you specify a migration table for the copy operation, and you choose the option to preserve the DACL from the source GPO, the migration table will apply to any security principals in the DACL.

Copying within a domain compared with copying to another domain

Copying a GPO to another domain is slightly different from copying it to the same domain.

When copying a GPO within the same domain, you have a simple choice of two options, just described, for choosing the DACL. However, for copy operations to another domain, GPMC presents a wizard to facilitate the operation. The wizard guides you through the following choices:

Choice of DACL for the new GPO, as described earlier.
Specification of migration table, if applicable. A migration table allows you to facilitate the transfer of references to security groups, users, computers, and UNC paths in the source GPO to new values in the destination GPO.

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.

Migration Tables

When you copy or import a Group Policy object (GPO) from one domain to another, you can use a migration table to tell Group Policy Management Console (GPMC) how domain-specific data should be treated.

The key challenge when migrating GPOs from one domain to another is that some information in the GPO is actually specific to the 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 such as users, groups, and computers as well as 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. A migration table consists of one or more mapping entries. Each mapping entry consists of a 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.

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 discretionary access control list (DACL) on the GPO, the migration table will also apply to both the DACL on the GPO and the DACLs on any software installation settings in the GPO.

Migration tables store the mapping information as XML, and have their own file name extension, .migtable. You can create migration tables using the Migration Table Editor (MTE). The MTE is a convenient tool for viewing and editing migration tables without having to work in, or be familiar with, XML. The MTE is associated with the .migtable extension so that when you double-click a migration table, it opens in the MTE. The MTE is installed with GPMC. You can also create and edit migration tables using any XML editor or using the GPMC scripting interfaces.

Settings 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 following places: the settings of the GPO, in the ACL for the GPO itself, and the ACL for any software installation settings in the GPO. Security principals do not transfer well for several reasons. For instance, domain local groups are invalid in external domains but other groups are valid if there is trust in place. Even with a trust between domains, it may not always be appropriate to use the exact same group in the new domain. If there is no trust, then none of the security principals in the source domain will be available in the destination domain.
UNC paths. When you are migrating GPOs across domains that do not have trust, such as from test to production environments, users in the destination domain may not have access to paths in the source domain.

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
- Restricted groups
- Services
- File system
- Registry
Advanced folder redirection policies.
The GPO discretionary access control list (DACL), if you choose to preserve it during a copy operation.
The DACL on software installation objects. This is only preserved if the option to copy the GPO DACL is specified. Otherwise the default DACL is used.

Note
- Security Principals referenced in Administrative Templates settings cannot be migrated using a migration table.

The following items can contain UNC paths and can be modified using a migration table:

Folder redirection policies.
Software installation policies (for software distribution points).
Pointers to scripts deployed through Group Policy (such as startup and shutdown scripts) 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.

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 copies the GPO exactly as it is. All references to security principals and UNC paths are copied identically.
Use a migration table. This option maps any references in the GPO that are in the migration table. References that are not contained in the migration table are copied as is.
Use a migration table exclusively. This option requires that all references to security principals and UNC paths that are referenced in the source GPO 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 fails.

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 Preserve or migrate the existing permissions.

When performing a copy or import, the wizard scans the source GPO to determine if there are any references to security principals or UNC paths in the GPO. If there are, you have the opportunity to specify a migration table. During cross-domain copy operations, if you specify the option Preserve or migrate the permissions on the GPO, the wizard will always present the opportunity to specify a migration table, because a DACL by definition contains security principals.

Contents of Migration tables

A migration table consists of one or more mapping entries. Each mapping entry has three pieces of information: type, source and destination. The following sections describe these categories in more detail.

Source Types

Source types describe the type of domain-specific information for the source GPO. Migration tables support the following types of source types:

XML Elements of Source Types

Source Type	How This Type Appears in XML Editor
User	<Type>User</Type>
Computer	<Type>Computer</Type>
Domain Local Group	<Type>LocalGroup</Type>
Domain Global Group	<Type>GlobalGroup</Type>
Universal Group	<Type>UniversalGroup</Type>
UNC Path	<Type>UNCPath</Type>
Free Text or security identifier (SID). This category is only for use with security principals that are specified as free text and raw SIDs.	<Type>Unknown</Type>

Note

Built-in groups such as Administrators and Account Operators have the same SID in all domains. If references to built-in groups are stored in the GPO using their resolved format (based on the underlying SID), they cannot be mapped using migration tables. However, if references to built-in groups are stored as free text, you can map them using a migration table, and in this case, you must specify source type=Free Text or SID.

Source Reference

A source reference is the specific name of the User, Computer, Group or UNC Path referenced in the source GPO. For example, \\server1\publicshare is a specific example of a UNC path. The type of the source reference must match whatever source type has been specified in the migration table.

Source Reference Syntax

Source Reference	Syntax
UPN	someone@example.com
SAM	example\someone
DNS	example.com\someone
Free text	someone (must be specified as the unknown type)
SID	S-1-11-111111111-111111111-1111111111-1112 (must be specified as the unknown type.)

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.

Destination Name Options

Destination Name	Description
Same as source	Copy without changes. Equivalent to not putting the source value in the migration table at all. MTE value: <Same As Source> XML tag:<DestinationSameAsSource />
None	Removes the User, Computer or Group from the GPO. This option cannot be used with UNC paths MTE value: <None> XML tag: <DestinationNone />
Map by relative name	For example, map SourceDomain\Group1 to TargetDomain\Group1. This option cannot be used with UNC paths. MTE value: <Map by Relative name> XML tag: <DestinationByRelativeName />
Explicitly specify value	In the destination GPO, replace the source value with the exact literal value you specify. MTE value: <exact name to use in target> XML tag: <Destination>Exact Name to use in Destination</Destination>

Note

Administrators can specify security principals for destination names using any of the syntactical formats described in source references, with the exception of using a raw SID. A raw SIDs can never be used for the destination name.

Default Entries

Valid migtable files must contain the following entries, which identifies the namespace used by migtables. If you are creating migtables by hand, you need to add this. Otherwise MTE does this for you.

<?xml version="1.0" encoding="utf-16"? >
<MigrationTable xmlns="https://www.microsoft.com/GroupPolicy/GPOOperations/MigrationTable">

Each mapping entry appears in the following format:

<Mapping>
<Type>Type</Type>
<Source>Source</Source>
<Destination>Destination</Destination>
</Mapping>

The Migration Table Editor

The Migration Table Editor (MTE) is provided with Group Policy Management Console (GPMC) to facilitate the editing of migration tables. Migration tables are used for copying or importing Group Policy objects (GPOs) from one domain to another, in cases where the GPOs include domain-specific information that must be updated during copy or import.

MTE displays three columns of information:

Migration Table Editor columns

Source Name	Source Type	Destination Name
Name of the user, computer, group, or UNC path, referenced in the source GPO.	The type of the reference named in the Source Name column. For example, Domain Global Group.	The new value, after copy or import to the new GPO; or the method used to calculate the new value.

Note that you do not specify Destination Type. The Destination Type is determined during the import or copy operation by checking the actual reference identified in the Destination Name.

Migration Table Editor features

You can edit text fields using Cut, Copy, and Paste options, for example when you right-click an item in the Source Name column.
You can add computers, users, and groups, for source and destination names, by using a Browse dialog box.
You can fill in Source Type fields by using a drop-down menu.
MTE provides automatic syntax checking to make sure the XML file is properly populated and also ensures that only compatible entries are entered in the table. For example, \\server1\share1 is not a valid security group name name, and server1 is not a valid UNC path so MTE prompts the user to correct those entries.
You can validate the overall migration table using MTE, in addition to basic syntax checking using the Validate Table option. The Validate Table option checks to ensure:
- The existence of destination security principals and UNC paths. This is important to know before you copy or import a GPO, because if there are unresolvable entries in the migration table, then the copy or import operation might fail.
- Source entries with UNC paths do not have destinations of MapByRelative name or NoDestination.
- Type of the destination entry in the table matches the real type in the destination source.
You can auto-populate a migration table by scanning one or more GPOs or backups to extract all references to security principals and UNC paths, and then enter these items into the table as source name entries. This capability is provided by the Populate from GPO and Populate from Backup options available on the Tools menu. To complete the migration table, you only need to adjust the destination values. By default, the destination name for each entry will be set to Same as source when you use either of the Populate options.

Note
- With either auto-populate option, when the source GPO or backup contains references to built-in groups such as Administrators or Backup Operators, these references will not be entered into the migration table if the references are stored in the source GPO or backup in their resolved format [based on security identifier (SID)]. This is because built-in groups have the same SID in all domains and therefore cannot be mapped to new values using a migration table. However, if references to built-in groups are stored as free text, they will be captured by the auto-populate options. In this case, you can map them as long as you specify the source type as Free Text or SID.

Administrative Templates in GPMC and Group Policy Object Editor

Administrators using Group Policy Management Console need to understand that Administrative template files are handled differently, depending upon whether they are working with Group Policy Management Console or Group Policy Object Editor. How each of the tools handles Administrative template files can be manipulated using Group Policy, but it is important to understand first the differences between the two.

Administrative Templates

Administrative templates, or .adm files, enable administrators to control registry settings using Group Policy. Windows comes with a predefined set of Administrative template files, which are implemented as text files (with an .adm extension), that define the registry settings that can be configured in a GPO. These .adm files are stored in two locations by default: inside GPOs in the Sysvol folder and in the %windir%\inf directory on the local computer.

Windows Server 2003 includes the following .adm files: System.adm*,* Inetres.adm, Conf.adm, Wmplayer.adm, and Wuau.adm, which contain all the settings initially displayed in the Administrative Templates node.

Default Administrative Templates

Administrative Template File	Contains	For Use on	Description
System.adm	Settings to configure the Operating System	Windows 2000 or Windows Server 2003	Loaded by default.
Inetres.adm	Settings to configure Internet Explorer	Windows 2000 or Windows Server 2003	Loaded by default
Conf.adm	Settings to configure NetMeeting v3	Windows 2000 or Windows Server 2003. Note: This tool is not available on Windows XP 64-Bit Edition and the 64-bit versions of the Windows Server 2003 family.	Loaded by default.
Wmplayer.adm	Settings to configure Windows Media Player	Windows XP, Windows Server 2003. Note: This tool is not available on Windows XP 64-Bit Edition and the 64-bit versions of the Windows Server 2003 family.	Loaded by default.
Wuau.adm	Settings to configure Windows Update	Windows 2000 SP3, Windows XP SP1, Windows Server 2003	Loaded by default.

Handling Administrative Template Files in GPMC

GPMC uses .adm files to display the friendly names of policy settings when generating HTML reports for GPOs, Group Policy Modeling, and Group Policy Results.

By default, GPMC uses the local .adm file, regardless of time stamp. If the file is not found, then GPMC will look in the GPO’s directory on Sysvol.

The user can specify an alternate path for where to find .adm files. If specified, this takes precedence over the previous locations.

GPMC never copies the .adm file to the Sysvol.

Handling Administrative Template Files in Group Policy Object Editor

Group Policy Object Editor uses .adm files to display available registry-based policy settings in the Administrative Templates section of a GPO. This includes Group Policy for the Windows Server 2003 operating system and its components and for applications.

By default, it attempts to read .adm files from the GPO (from the Sysvol on the domain controller). Alternatively, the .adm file can be read from the local workstation computer. This behavior can be controlled by a policy setting.

By default, if the version of the .adm file found on the local computer is newer (based on the time stamp of the file) than the version on the Sysvol, the local version is copied to the Sysvol and is then used to display the settings. This behavior can be controlled by a policy setting.

If the GPO contains registry settings for which there is no corresponding .adm file, these settings cannot be seen in Group Policy Object Editor. However, the policy settings are still active and will be applied to users or computers targeted by the GPO.

Policy settings pertaining to a user who logs on to a given workstation or server are written to the User portion of the registry database under HKEY_CURRENT_USER. Computer-specific settings are written to the Local Machine portion of the registry under HKEY_LOCAL_MACHINE.

The following resources contain additional information that is relevant to this section:

How Group Policy Management Console Works