Group Policy Planning and Deployment Guide

Applies To: Windows Server 2008

You can use Windows Server 2008 Group Policy to manage configurations for groups of computers and users, including options for registry-based policy settings, security settings, software deployment, scripts, folder redirection, and preferences. Group Policy preferences, new in Windows Server 2008, are more than 20 Group Policy extensions that expand the range of configurable policy settings within a Group Policy object (GPO). In contrast to Group Policy settings, preferences are not enforced. Users can change preferences after initial deployment. For information about Group Policy Preferences, see Group Policy Preferences Overview.

Using Group Policy, you can significantly reduce an organization’s total cost of ownership. Various factors, such as the large number of policy settings available, the interaction between multiple policies, and inheritance options, can make Group Policy design complex. By carefully planning, designing, testing, and deploying a solution based on your organization’s business requirements, you can provide the standardized functionality, security, and management control that your organization needs.

Overview of Group Policy

Group Policy enables Active Directory–based change and configuration management of user and computer settings on computers running Windows Server 2008, Windows Vista, Windows Server 2003, and Windows XP. In addition to using Group Policy to define configurations for groups of users and computers, you can also use Group Policy to help manage server computers, by configuring many server-specific operational and security settings.

The Group Policy settings you create are contained in a GPO. To create and edit a GPO, use the Group Policy Management Console (GPMC). By using the GPMC to link a GPO to selected Active Directory sites, domains, and organizational units (OUs), you apply the policy settings in the GPO to the users and computers in those Active Directory objects. An OU is the lowest-level Active Directory container to which you can assign Group Policy settings.

To guide your Group Policy design decisions, you need a clear understanding of your organization’s business needs, service level agreements, and requirements for security, network, and IT. By analyzing your current environment and users’ requirements, defining the business objectives you want to meet by using Group Policy, and following these guidelines for designing a Group Policy infrastructure, you can establish the approach that best supports your organization’s needs.

Process for implementing a Group Policy solution

The process for implementing a Group Policy solution entails planning, designing, deploying, and maintaining the solution.

When you plan your Group Policy design, make sure that you design the OU structure to ease Group Policy manageability and to comply with service-level agreements. Establish good operational procedures for working with GPOs. Make sure that you understand Group Policy interoperability issues, and determine whether you plan to use Group Policy for software deployment.

During the design phase:

• Define the scope of application of Group Policy.

• Determine the policy settings that are applicable to all corporate users.

• Classify users and computers based on their roles and locations.

• Plan desktop configurations based on the user and computer requirements.

A well-planned design will help ensure a successful Group Policy deployment.

The deployment phase begins with staging in a test environment. This process includes:

• Creating standard desktop configurations.

• Filtering the scope of application of GPOs.

• Specifying exceptions to default inheritance of Group Policy.

• Delegating administration of Group Policy.

• Evaluating effective policy settings by using Group Policy Modeling.

• Evaluating the results by using Group Policy Results.

Staging is critical. Thoroughly test your Group Policy implementation in a test environment before deploying to your production environment. After you complete staging and testing, migrate your GPO to your production environment by using the GPMC. Consider an iterative implementation of Group Policy: Rather than deploying 100 new Group Policy settings, initially stage and then deploy only a few policy settings to validate that the Group Policy infrastructure is working well.

Finally, prepare to maintain Group Policy by establishing control procedures for working with and troubleshooting GPOs by using the GPMC.

Note

Microsoft Advanced Group Policy Management (AGPM) extends the capabilities of the GPMC by providing comprehensive change control and enhanced management of GPOs. For more information about AGPM, see the Microsoft Desktop Optimization Pack (MDOP) Web site (https://go.microsoft.com/fwlink/?LinkId=100757).

What you need to do before designing your Group Policy solution

Before designing your Group Policy implementation, you need to understand your current organizational environment, and you need to take preparatory steps in the following areas:

• Active Directory: Ensure that the Active Directory OU design for all domains in the forest supports the application of Group Policy. For more information, see Designing an OU structure that supports Group Policy later in this guide.

• Networking: Make sure that your network meets the requirements for change and configuration management technologies. For example, because Group Policy works with fully qualified domain names, you must have Directory Name Service (DNS) running in your forest in order to correctly process Group Policy.

• Security: Obtain a list of the security groups currently in use in your domain. Work closely with the security administrators as you delegate responsibility for organizational-unit administration and create designs that require security-group filtering. For more information about filtering GPOs, see "Applying GPOs to Selected Groups (Filtering)" in Defining the scope of application of Group Policy later in this guide.

• IT requirements: Obtain a list of the administrative owners and corporate administrative standards for the domains and OUs in your domain. This will allow you to develop a good delegation plan and to ensure that Group Policy is properly inherited.

Note

Group Policy depends on networking, security, and Active Directory; therefore, it is crucial to understand these technologies. It is highly recommended that you familiarize yourself with these concepts before implementing Group Policy.

Administrative requirements for Group Policy

To use Group Policy, your organization must be using Active Directory, and the destination desktop and server computers must be running Windows Server 2008, Windows Vista, Windows Server 2003, or Windows XP.

By default, only members of the Domain Admins or the Enterprise Admins groups can create and link GPOs, but you can delegate this task to other users. For more information about administrative requirements for Group Policy, see Delegating administration of Group Policy later in this guide.

The GPMC

The GPMC provides unified management of all aspects of Group Policy across multiple forests in an organization. The GPMC lets you manage all GPOs, Windows Management Instrumentation (WMI) filters, and Group Policy–related permissions in your network. Think of the GPMC as your primary access point to Group Policy, with all the Group Policy management tools available from the GPMC interface.

The GPMC consists of a set of scriptable interfaces for managing Group Policy and an MMC-based user interface (UI). The 32 and 64-bit versions of the GPMC are included with Windows Server 2008.

The GPMC provides the following capabilities:

• Importing and exporting GPOs.

• Copying and pasting GPOs.

• Backing up and restoring GPOs.

• Searching for existing GPOs.

• Reporting capabilities.

• Group Policy Modeling. Allows you to simulate Resultant Set of Policy (RsoP) data for planning Group Policy deployments before implementing them in the production environment.

• Group Policy Results. Allows you to obtain RSoP data for viewing GPO interaction and for troubleshooting Group Policy deployments.

• Support for migration tables to facilitate the importing and copying of GPOs across domains and across forests. A migration table is a file that maps references to users, groups, computers, and Universal Naming Convention (UNC) paths in the source GPO to new values in the destination GPO.

• Reporting GPO settings and RSoP data in HTML reports that you can save and print.

• Scriptable interfaces that allow all operations that are available within the GPMC. You cannot, however, use scripts to edit individual policy settings in a GPO.

Note

Windows Server 2008 does not include the GPMC sample scripts from earlier versions of the GPMC. However, you can download the GPMC sample scripts for Windows Server 2008 from Group Policy Management Console Sample Scripts. For more information about using the GPMC sample scripts, see Using scripts to manage Group Policy later in this guide.

Using the GPMC greatly improves the manageability of your Group Policy deployment and enables you to take full advantage of the power of Group Policy by providing an enhanced and simplified Group Policy management interface.

Designing an OU structure that supports Group Policy

In an Active Directory environment, you assign Group Policy settings by linking GPOs to sites, domains, or OUs. Typically, you assign most GPOs at the OU level, so make sure that your OU structure supports your Group Policy-based client-management strategy. You might also apply some Group Policy settings at the domain level, particularly those such as password policies. Very few policy settings are applied at the site level. A well-designed OU structure that reflects the administrative structure of your organization and takes advantage of GPO inheritance simplifies the application of Group Policy. For example, a well-designed OU structure can prevent duplicating certain GPOs so that you can apply these GPOs to different parts of the organization. If possible, create OUs to delegate administrative authority and to help implement Group Policy.

OU design requires balancing requirements for delegating administrative rights independent of Group Policy needs, and the need to scope the application of Group Policy. The following OU design recommendations address delegation and scope issues:

• Delegating administrative authority: You can create OUs within a domain and delegate administrative control for specific OUs to particular users or groups. Your OU structure might be affected by requirements to delegate administrative authority.

• Applying Group Policy: Think primarily about the objects that you want to manage when you approach the design of an OU structure. You might want to create a structure that has OUs organized by workstations, servers, and users near the top level. Depending on your administrative model, you might consider geographically based OUs either as children or parents of the other OUs, and then duplicate the structure for each location to avoid replicating across different sites. Add OUs below these only if doing so makes the application of Group Policy clearer, or if you need to delegate administration below these levels.

By using a structure in which OUs contain homogeneous objects, such as either user or computer objects but not both, you can easily disable those sections of a GPO that do not apply to a particular type of object. This approach to OU design, illustrated in Figure 1, reduces complexity and improves the speed at which Group Policy is applied. Keep in mind that GPOs linked to the higher layers of the OU structure are inherited by default, which reduces the need to duplicate GPOs or to link a GPO to multiple containers.

When designing your Active Directory structure, the most important considerations are ease of administration and delegation.

Applying Group Policy to new user and computer accounts

New user and computer accounts are created in the CN=Users and CN=Computers containers by default. It is not possible to apply Group Policy directly to these containers, although they inherit GPOs linked to the domain. To apply Group Policy to the default Users and Computers containers, you must use the new Redirusr.exe and Redircomp.exe tools.

Redirusr.exe (for user accounts) and Redircomp.exe (for computer accounts) are two tools that are included with Windows Server 2008. These tools enable you to change the default location where new user and computer accounts are created, so you can more easily scope GPOs directly to newly created user and computer objects. These tools are located on servers with the Active Directory Services Role in %windir%\system32.

By running Redirusr.exe and Redircomp.exe once for each domain, the domain administrator can specify the OUs into which all new user and computer accounts are placed at the time of creation. This allows administrators to manage these unassigned accounts by using Group Policy before the administrators assign them to the OU in which they are finally placed. Consider restricting the OUs used for new user and computer accounts by using Group Policy to increase the security of these accounts.

For more information about redirecting user and computer accounts, see article 324949, "Redirecting the users and computers containers in Windows Server 2003 domains," in the Microsoft Knowledge Base (https://go.microsoft.com/fwlink/?LinkId=100759).

Sites and replication considerations

As you determine which policy settings are appropriate, be aware of the physical aspects of Active Directory, which include the geographical location of sites, the physical placement of domain controllers, and the speed of replication.

GPOs are stored in both Active Directory and in the Sysvol folder on each domain controller. These locations have different replication mechanisms. Use the Resource Kit tool Group Policy Objects (Gpotool.exe) to help diagnose problems when you suspect that a GPO might not have replicated across domain controllers.

For more information about Gpotool.exe, see Microsoft Help and Support (https://go.microsoft.com/fwlink/?LinkId=109283). To download the Windows Server 2008 Resource Kit tools, see Windows Server 2008 Resource Kit tools on the Microsoft Download Center (https://go.microsoft.com/fwlink/?LinkId=4544).

Domain controller placement is an issue when slow links, typically to clients at remote sites, are involved. If the network link speeds between a client and the authenticating domain controller fall below the default slow-link threshold of 500 kilobits per second, only the Administrative template (registry-based) settings, the new Wireless Policy extension, and security settings are applied by default. All other Group Policy settings are not applied by default. However, you can modify this behavior by using Group Policy.

You can change the slow link threshold by using the Group Policy Slow Link Detection policy for both the user and computer aspects of a GPO. If necessary, you can also adjust which Group Policy extensions are processed below the slow-link threshold. Even then, it might be more appropriate to place a local domain controller at a remote location to serve your management needs.

Complying with service-level agreements

Some IT groups use service-level agreements to specify how services should operate. For example, a service-level agreement might stipulate the maximum length of time required for computer startup and logon, how long users can use the computer after they log on, and so on. Service-level agreements often set standards for service responsiveness. For example, a service level agreement might define the amount of time allowed for a user to receive a new software application or gain access to a previously disabled feature. Issues that can affect service responsiveness are the site and replication topology, the positioning of domain controllers, and the location of Group Policy administrators.

To reduce the amount of time required to process a GPO, consider using one of the following strategies:

• If a GPO contains only computer configuration or user configuration settings, disable the portion of the policy setting that does not apply. When you do this, the destination computer does not scan the portions of a GPO that you disable, which reduces processing time. For information about disabling portions of a GPO, see Disabling the User Configuration or Computer Configuration settings in a GPO later in this guide.

• When possible, combine smaller GPOs to form a consolidated GPO. This reduces the number of GPOs that are applied to a user or computer. Applying fewer GPOs to a user or computer can reduce startup or logon times and make it easier to troubleshoot the policy structure.

• The changes you make to GPOs are replicated to domain controllers and result in new downloads to client or destination computers. If you have large or complex GPOs that require frequent changes, consider creating a new GPO that contains only the sections that you update regularly. Test this approach to determine whether the benefits you get by minimizing the impact on the network and improving the destination computer’s processing time outweigh the increased troubleshooting potential by making the GPO structure more complex.

• You should implement a Group Policy change control process and log any changes made to GPOs. This can help you troubleshoot and correct problems with GPOs. Doing so also helps comply with service-level agreements that require keeping logs. Consider using AGPM for implementing change control process for GPOs and for managing GPOs.

Defining your Group Policy objectives

When you plan the deployment of Group Policy, identify your specific business requirements and how Group Policy can help achieve them. You can then determine the most appropriate policy settings and configuration options to meet your requirements.

The objectives for each Group Policy implementation vary depending on user location, job needs, computer experience, and corporate security requirements. In some cases, you might remove functionality from users’ computers to prevent them from modifying system configuration files (which might disrupt computer performance), or you might remove applications that are not essential for users to perform their jobs. In other cases, you might use Group Policy to configure operating system options, specify Internet Explorer settings, or establish a security policy.

Having a clear understanding of your current organizational environment and requirements helps you design a plan that best meets your organization’s needs. Collecting information about the types of users, such as process workers and data entry workers, and existing and planned computer configurations is essential. Based on this information, you can define your Group Policy objectives.

Evaluating existing corporate practices

To help you identify the appropriate Group Policy settings to use, begin by evaluating current practices in your corporate environment, including such factors as:

• User requirements for various types of users.

• Current IT roles, such as the various administrative duties divided among administrator groups.

• Existing corporate security policies.

• Other security requirements for your server and client computers.

• Software distribution model.

• Network configuration.

• Data storage locations and procedures.

• Current management of users and computers.

Defining Group Policy objectives

Next, as part of defining the goals for Group Policy, determine:

• The purpose of each GPO.

• The owner of each GPO—the person who requested the policy setting and who is responsible for it.

• The number of GPOs to use.

• The appropriate container to link each GPO (site, domain, or OU).

• The types of policy settings contained in each GPO, and the appropriate policy settings for users and computers.

• When to set exceptions to the default processing order for Group Policy.

• When to set filtering options for Group Policy.

• The software applications to install and their locations.

• The network shares to use for redirecting folders.

• The location of logon, logoff, startup, and shutdown scripts to run

Planning for ongoing administration of Group Policy

As you design and implement your Group Policy solution, it is also important to plan for the ongoing administration of Group Policy. Establishing administrative procedures to track and manage GPOs can ensure that all changes are implemented in a prescribed manner.

To simplify and regulate ongoing management of Group Policy, we recommend that you:

• Always stage Group Policy deployments by using the following predeployment process:

  • Use Group Policy Modeling to understand how a new GPO will interoperate with existing GPOs.

  • Deploy new GPOs in a test environment that is modeled after your production environment.

  • Use Group Policy Results to understand which GPO settings actually are applied in your test environment.

• Use the GPMC to make backups of your GPOs on a regular basis.

• Use the GPMC to manage Group Policy across the organization.

• Do not modify the default domain policy or default domain controller policy unless necessary. Instead, create a new GPO at the domain level and set it to override the default policy settings.

• Define a meaningful naming convention for GPOs that clearly identifies the purpose of each GPO.

• Designate only one administrator per GPO. This prevents one administrator’s work from being overwritten by another’s work.

Windows Server 2008 and the GPMC allow you to delegate to different groups of administrators permission to edit and link GPOs. Without adequate GPO control procedures in place, delegated administrators can duplicate GPO settings or create GPOs that conflict with policy settings set by another administrator or that are not in accordance with corporate standards. Such conflicts might adversely affect the users’ desktop environment, generate increased support calls, and make troubleshooting GPOs more difficult.

Identifying interoperability issues

You need to consider possible interoperability issues when planning a Group Policy implementation in a mixed environment. Windows Server 2008 and Windows Vista include many new Group Policy settings that are not used on Windows Server 2003 or Windows XP. However, even if the client and server computers in your organization run primarily Windows Server 2003 or Windows XP, you should use the GPMC included in Windows Server 2008 because it contains the latest policy settings. If you apply a GPO with newer policy settings to a previous operating system that does not support the policy setting, it will not cause a problem.

Destination computers that are running Windows Server 2003 or Windows XP Professional simply ignore policy settings supported only in Windows Server 2008 or Windows Vista. To determine which policy settings apply to which operating systems, in the description for the policy setting, see the Supported on information, which explains which operating systems can read the policy setting.

Determining when Group Policy changes are applied

Changes to Group Policy settings might not be immediately available on users’ desktops because changes to the GPO must first replicate to the appropriate domain controller. In addition, clients use a 90-minute refresh period (randomized by up to approximately 30 minutes) for the retrieval of Group Policy. Therefore, it is rare for a changed Group Policy setting to be applied immediately. Components of a GPO are stored in both Active Directory and on the Sysvol folder of domain controllers. Replication of a GPO to other domain controllers occurs by two independent mechanisms:

• Replication in Active Directory is controlled by Active Directory’s built-in replication system. By default, this typically takes less than a minute between domain controllers within the same site. This process can be slower if your network is slower than a LAN.

• Replication of the Sysvol folder is controlled by the File Replication Service (FRS) or Distributed File System Replication (DFSR). Within sites, FRS replication occurs every 15 minutes. If the domain controllers are in different sites, the replication process occurs at set intervals based on site topology and schedule; the lowest interval is 15 minutes.

Note

If it is critical to immediately apply a change to a specific group of users or computers in a specific site, you can connect to the domain controller closest to these objects, and then make the configuration change on that domain controller, so those users get the updated policy settings first.

Policy refresh interval

The primary mechanisms for refreshing Group Policy are startup and logon. Group Policy is also refreshed at other intervals on a regular basis. The policy refresh interval affects how quickly changes to GPOs are applied. By default, clients and servers running Windows Server 2008, Windows Vista, Windows Server 2003, and Windows XP check for changes to GPOs every 90 minutes by using a randomized offset of up to 30 minutes.

Domain controllers running Windows Server 2008 or Windows Server 2003 check for computer policy changes every five minutes. This polling frequency can be changed by using one of these policy settings: Group Policy Refresh Interval for Computers, Group Policy Refresh Interval for Domain Controllers, or Group Policy refresh Interval for Users. However, shortening the frequency between refreshes is not recommended because of the potential increase in network traffic and the additional load placed on the domain controllers.

Triggering a Group Policy refresh

If necessary, you can trigger a Group Policy refresh manually from a local computer without waiting for the automatic background refresh. To do this, you can type gpupdate at the command line to refresh the user or computer policy settings. You cannot trigger a Group Policy refresh by using the GPMC. The gpupdate command triggers a background policy refresh on the local computer from which the command is run.

For more information about the gpupdate command, see Changing the Group Policy refresh interval later in this guide.

Note

Some policy settings, such as folder redirection and the assignment of software applications, require the user to log off and log on again before they take effect. Software applications assigned to computers are installed only when the computer is restarted.

Identifying issues pertaining to software installation

Although you can use Group Policy to install software applications, especially in small-sized or medium-sized organizations, you need to determine if it is the best solution for your needs. When you use Group Policy to install software applications, assigned applications are installed or updated only when the computer is restarted or when the user logs on.

Using System Center Configuration Manager 2007—previously Systems Management Server (SMS)—for software deployment provides enterprise-level functionality that is not available with Group Policy–based software deployment, such as inventory-based targeting, status reporting, and scheduling. For this reason, you might use Group Policy to configure the desktop and set system security and access permissions, but use Configuration Manager to deliver software applications. This approach provides bandwidth control by enabling you to schedule application installation outside core business hours.

Your choice of tools depends on your requirements, your environment, and whether you need the additional functionality and security that Configuration Manager provides. For information about Configuration Manager, see System Center Configuration Manager (https://go.microsoft.com/fwlink/?LinkId=109285).

Designing your Group Policy model

Your primary objective is to design the GPO structure based on your business requirements. Keeping in mind the computers and users in your organization, determine which policy settings must be enforced across the organization, and which policy settings are applicable to all users or computers. Also determine which policy settings to use to configure computers or users according to type, function, or job role. Then group these different types of policy settings into GPOs and link them to the appropriate Active Directory containers.

Also, keep in mind the Group Policy inheritance model and how precedence is determined. By default, options set in GPOs linked to higher levels of Active Directory sites, domains, and OUs are inherited by all OUs at lower levels. However, inherited policy can be overridden by a GPO that is linked at a lower level.

For example, you might use a GPO linked at a high level for assigning standard desktop wallpaper, but want a certain OU to get different wallpaper. To do so, you can link a second GPO to that specific lower-level OU. Because lower-level GPOs are applied last, the second GPO will override the domain-level GPO and provide that specific lower-level OU with a different set of Group Policy settings. However, you can modify this default inheritance behavior by using Block Inheritance and Enforced.

The following guidelines can help tailor your Group Policy design to the needs of your organization:

• Determine if there are any policy settings that must always be enforced for particular groups of users or computers. Create GPOs that contain these policy settings, link them to the appropriate site, domain, or OU, and designate these links as Enforced. By setting this option, you enforce a higher-level GPO’s policy settings by preventing GPOs in lower-level Active Directory containers from overriding them. For example, if you define a specific GPO at the domain level and specify that it is enforced, the policies that the GPO contains apply to all OUs under that domain; GPOs linked to the lower-level OUs cannot override that domain Group Policy.

Note

Use the Enforced and Block Policy Inheritance features sparingly. Routine use of these features can make it difficult to troubleshoot policy because it is not immediately clear to administrators of other GPOs why certain policy settings do or do not apply.

• Decide which policy settings are applicable to the entire organization and consider linking these to the domain. You can also use the GPMC to copy GPOs or import GPO policy settings, thereby creating identical GPOs in different domains.

• Link the GPOs to the OU structure (or site), and then use security groups to selectively apply these GPOs to particular users or computers.

• Classify the types of computers and the roles or job function of users in your organization, group them into OUs, create GPOs to configure the environment for each as needed, and then link the GPOs to those OUs.

• Prepare a staging environment to test your Group Policy-based management strategy before deploying GPOs into your production environment. Think of this phase as staging your deployment. This is a crucial step toward ensuring that your Group Policy deployment will meet your management goals. This process is described in Staging Group Policy deployments later in this guide.

Defining the scope of application of Group Policy

To define the scope of application of GPOs, consider the following questions:

• Where will your GPOs be linked?

• What security filtering on the GPOs will you use?

  Security filtering enables you to refine which users and computers will receive and apply the policy settings in a GPO. Security group filtering determines whether the GPO as a whole applies to groups, users, or computers; it cannot be used selectively on different policy settings within a GPO.

• What WMI filters will be applied?

  WMI filters allow you to dynamically determine the scope of GPOs based on attributes of the target computer.

Also, remember that by default GPOs are inherited, cumulative, and affect all computers and users in an Active Directory container and its children. They are processed in the following order: Local Group Policy, site, domain, and then OU, with the last GPO processed overriding the earlier GPOs. The default inheritance method is to evaluate Group Policy starting with the Active Directory container farthest from the computer or user object. The Active Directory container closest to the computer or user overrides Group Policy set in a higher-level Active Directory container unless you set the Enforced (No Override) option for that GPO link or if the Block Policy Inheritance policy setting has been applied to the domain or OU. The LGPO is processed first, so policy settings from GPOs linked to Active Directory containers override the local policy settings.

Another issue is that although you can link more than one GPO to an Active Directory container, you need to be aware of the processing priority. The GPO link with the lowest link order in the Group Policy Object Links list (displayed in the Linked Group Policy Objects tab in the GPMC) has precedence by default. However, if one or more GPO links have the Enforced option set, the highest GPO link set to Enforced takes precedence.

Stated briefly, Enforced is a link property, and Block Policy Inheritance is a container property. Enforced takes precedence over Block Policy Inheritance. In addition, you can disable policy settings on the GPO itself in four other ways: A GPO can be disabled; a GPO can have its computer settings disabled, its user settings disabled, or all of its settings disabled.

The GPMC greatly simplifies these tasks by allowing you to view GPO inheritance across your organization and manage links from one MMC console. Figure 2 shows Group Policy inheritance as displayed in the GPMC.

Note

To view full details of inheritance and precedence for GPO links to a domain, site, or OU, you must have Read permissions on the site, domain, or OU containing the GPO links as well as on the GPOs. If you have Read access to the site, domain, or OU, but not on one of the GPOs linked there, it will appear as Inaccessible GPO, and you will not be able to read the name or other information for that GPO.

Determining the number of needed GPOs

The number of GPOs that you need depends on your approach to design, the complexity of the environment, your objectives, and the scope of the project. If you have a forest with multiple domains or you have multiple forests, you might find that the number of GPOs required in each domain is different. Domains supporting highly complex business environments with a diverse user population typically require more GPOs than smaller, simpler domains.

As the number of GPOs required to support an organization increases, so can the workload of Group Policy administrators. There are steps you can take to ease the administration of Group Policy. In general, you should group into a single GPO those policy settings that apply to a given set of users or computers and are managed by a common set of administrators. Further, if various groups of users or computers have common requirements, and only a few of the groups need incremental changes, consider applying the common requirements to all these groups of users or computers by using a single GPO linked high in the Active Directory structure. Then add additional GPOs that apply only the incremental changes at the relevant OU. This approach might not always be possible or practical, so you might need to make exceptions to this guideline. If so, be sure to keep track of them.

Note

A maximum of 999 GPOs is supported for processing GPOs on any one user or computer. If you exceed the maximum, no GPOs will be processed. This limitation affects only the number of GPOs that can be applied at the same time; it does not affect the number of GPOs you can create and store in a domain.

Consider that the number of GPOs applied to a computer affects startup time, and the number of GPOs applied to a user affects the amount of time needed to log on to the network. The greater the number of GPOs that are linked to a user—especially the greater the number of policy settings within those GPOs—the longer it takes to process them whenever a user logs on. During the logon process, each GPO from the user’s site, domain, and OU hierarchy is applied, provided both the Read and Apply Group Policy permissions are set for the user. In the GPMC, the Read and Apply Group Policy permissions are managed as a single unit called Security Filtering.

If you use Security Filtering and you remove the Apply Group Policy permission for a given user or group, also remove the Read permission unless you need that user to have read access for some reason. (If you are using the GPMC, you need not worry about this, because the GPMC does this for you automatically.) If the Apply Group Policy permission is not set, but the Read permission is, the GPO is still inspected (although not applied) by any user or computer that is in the OU hierarchy where the GPO is linked. This inspection process increases logon time slightly.

Always test your Group Policy solution in a test environment to ensure that the policy settings you define do not unacceptably prolong the time it takes to display the logon screen, and that they comply with desktop service-level agreements. During this staging period, log on with a test account to gauge the net effect of several GPOs on objects in your environment.

Linking GPOs

To apply the policy settings of a GPO to users and computers, you need to link the GPO to a site, domain, or OU. You can add one or more GPO links to each site, domain, or OU by using the GPMC. Keep in mind that creating and linking GPOs is a sensitive privilege that should be delegated only to administrators who are trusted and understand Group Policy.

Linking GPOs to the site

If you have a number of policy settings—such as certain network or proxy configuration settings—to apply to computers in a particular physical location, only these policy settings might be appropriate for inclusion in a site-based policy setting. Because sites and domains are independent, it is possible that computers in the site might need to cross domains to link the GPO to the site. In this case, make sure there is good connectivity.

If the policy settings do not clearly correspond to computers in a single site, it is better to assign the GPO to the domain or OU structure rather than to the site.

Linking GPOs to the domain

Link GPOs to the domain if you want them to apply to all users and computers in the domain. For example, security administrators often implement domain-based GPOs to enforce corporate standards. They might want to create these GPOs with the GPMC Enforce option enabled to guarantee that no other administrator can override these policy settings.

Important

If you need to modify the policy settings contained in the Default Domain Policy GPO, we recommend that you create a new GPO for this purpose, link it to the domain, and set the Enforce option. In general, do not modify the Default Domain Policy GPO or the Default Domain Controller Policy GPO.

As the name suggests, the Default Domain Policy GPO is also linked to the domain. The Default Domain Policy GPO is created when the first domain controller in the domain is installed and the administrator logs on for the first time. This GPO contains the domain-wide account policy settings, Password Policy, Account Lockout Policy, and Kerberos Policy, which is enforced by the domain controllers in the domain. All domain controllers retrieve the values of these account policy settings from the Default Domain Policy GPO. In order to apply account policies to domain accounts, these policy settings must be deployed in a GPO linked to the domain. If you set account policy settings at a lower level, such as an OU, the policy settings affect only local accounts (non-domain accounts) on computers in that OU and the children of the OU.

Before making any changes to the default GPOs, be sure to back up the GPO by using the GPMC. If there is a problem with the changes to the default GPOs and you cannot revert back to the previous or initial states, you can use the Dcgpofix.exe tool as described in the next section to recreate the default policies in their initial state. Alternatively, if you are using AGPM, a record will be maintained of any changes that you make, so you can revert back to previous or initial states.

Restoring the Default Domain Policy GPO and the Default Domain Controller GPO

Dcgpofix.exe is a command-line tool that completely restores the Default Domain Policy GPO and Default Domain Controller GPO to their original states, in the event of a disaster when you cannot use the GPMC. Dcgpofix.exe is included with Windows Server 2008 and Windows Server 2003, and is located in the C:\Windows\system32\ folder.

Dcgpofix.exe restores only the policy settings that are contained in the default GPOs at the time they are generated. Dcgpofix.exe does not restore other GPOs that administrators create; it is only intended for disaster recovery of the default GPOs.

Note

Dcgpofix.exe does not save any information created through applications, such as Configuration Manager or Exchange.

The syntax for Dcgpofix.exe is as follows:

DcGPOFix [/ignoreschema] [/Target: Domain | DC | BOTH]

Table 1 describes the command-line options you can use when using the Dcgpofix.exe tool.

Table 1 Dcgpofix.exe Command-Line Options

Option	Description of options
/ignoreschema	By default, the version of Dcgpofix that is included with Windows Server 2008 works only on Windows Server 2008 domains. This option bypasses the schema check, allowing it to work on non-Windows Server 2008 domains.
/target: DOMAIN or	Specifies that the Default Domain Policy should be recreated.
/target: DC or	Specifies that the Default Domain Controllers Policy should be recreated.
/target: BOTH	Specifies that both the Default Domain Policy and the Default Domain Controllers Policy should be recreated.

For more information about Dcgpofix.exe, see Dcgpofix.exe (https://go.microsoft.com/fwlink/?LinkId=109291).

Linking GPOs to the OU structure

GPOs are usually linked to the OU structure because this provides the most flexibility and manageability. For example:

• You can move users and computers into and out of OUs.

• OUs can be rearranged, if necessary.

• You can work with smaller groups of users who have common administrative requirements.

• You can organize users and computers based on which administrators manage them.

Organizing GPOs into user-oriented and computer-oriented GPOs can help make your Group Policy environment easier to understand and can simplify troubleshooting. However, separating the user and computer components into separate GPOs might require more GPOs. You can compensate for this by configuring the GPO Status setting to disable the user or computer configuration portions of the GPO that do not apply and to reduce the time required to apply a given GPO.

Changing the GPO link order

Within each site, domain, and OU, the link order controls the order in which GPOs are applied. To change the precedence of a link, you can change the link order, moving each link up or down in the list to the appropriate location. Links with the lowest number have higher precedence for a given site, domain, or OU.

For example, if you add six GPO links and later decide that you want the last one that you added to have the highest precedence, you can adjust the link order of the GPO link, so it has a link order of 1. To change the link order for GPO links for a site, domain, or OU, use the GPMC.

Using security filtering to apply GPOs to selected groups

By default, a GPO affects all users and computers contained in the linked site, domain, or OU. However, you can use security filtering on a GPO to modify its effect to apply only to a specific user, members of an Active Directory security group, or computer by modifying the permissions on the GPO. By combining security filtering with appropriate placement in OUs, you can target any given set of users or computers.

In order for a GPO to apply to a given user, security group, or computer, the user, group, or computer must have both Read and Apply Group Policy permissions on the GPO. By default, Authenticated Users have both the Read and Apply Group Policy permissions set to Allow. Both of these permissions are managed together as a single unit by using security filtering in the GPMC.

To set the permissions for a given GPO so that the GPO only applies to specific users, security groups, or computers (rather than to all authenticated users), in the GPMC console tree, expand Group Policy Objects in the forest and domain containing that GPO. Click the GPO, and in the details pane, on the Scope tab, under Security Filtering, remove Authenticated Users, click Add, and then add the new user, group, or computer.

For example, if you want only a subset of users within an OU to receive a GPO, remove Authenticated Users from Security Filtering. Then, add a new security group with Security Filtering permissions that contains the subset of users who are to receive the GPO. Only members of this group that are within the site, domain, or OU where the GPO is linked receive the GPO; members of the group in other sites, domains, or OUs do not receive the GPO.

You might want to prevent certain Group Policy settings from applying to members of the Administrators group. To accomplish this, you can do one of the following:

• Create a separate OU for administrators and keep this OU out of the hierarchy to which you apply most of your management settings. In this way, administrators do not receive most of the policy settings that you provide for managed users. If this separate OU is a direct child of the domain, the only possible policy settings administrators receive are policy settings from GPOs linked either to the domain or the site. Typically, only generic, broadly applicable policy settings are linked here, so it might be acceptable to have administrators receive these policy settings. If this is not what you intend, you can set the Block Inheritance option on the administrators’ OU.

• Have administrators use separate administrative accounts only when they perform administrative tasks. When not performing administrative tasks, they would still be managed.

• Use Security Filtering in the GPMC so that only non-administrators will receive the policy settings.

Applying WMI filters

You can use WMI filters to control the application of GPOs. Each GPO can be linked to one WMI filter; however, the same WMI filter can be linked to multiple GPOs. Before you can link a WMI filter to a GPO, you must create the filter. The WMI filter is evaluated on the destination computer during the processing of Group Policy. The GPO will apply only if the WMI filter evaluates to true. On Windows 2000–based computers, the WMI filter is ignored and the GPO is always applied.

Note

We recommend that you use WMI filters primarily for exception management. They can provide a powerful solution for targeting GPOs to specific users and computers, but because WMI filters are evaluated every time Group Policy is processed, they increase startup and logon time. Also, there is no time-out for WMI filters. Therefore, you should use them only when necessary.

Using the GPMC, you can perform the following operations for WMI filters: create and delete, link and unlink, copy and paste, import and export, and view and edit attributes.

WMI filters can be used only if at least one domain controller in the domain is running Windows Server 2008 or Windows Server 2003, or if you have run ADPrep with the /Domainprep option in that domain. If not, the WMI Filtering section on the Scope tab for GPOs and the WMI Filters node under the domain will not be present. See Figure 3 to help you identify the items described in this section.

Setting WMI filtering options

WMI exposes management data from a destination computer. The data can include hardware and software inventory, settings, and configuration information, including data from the registry, drivers, the file system, Active Directory, SNMP, Windows Installer, and networking. Administrators can create WMI filters, which consist of one or more queries based on this data, to control whether the GPO is applied. The filter is evaluated on the destination computer. If the WMI filter evaluates to true, the GPO is applied to that destination computer; if the filter evaluates to false, the GPO is not applied. On Windows 2000–based client or server targets, WMI filters are ignored, and the GPO is always applied. In the absence of any WMI filter, the GPO is always applied.

You can use WMI filters to target Group Policy settings based on a variety of objects and other parameters. Table 2 illustrates example query criteria that might be specified for WMI filters.

Table 2 Sample WMI Filters

WMI data queried	Sample query criteria
Services	Computers with the DHCP service running
Registry	Computers that have a specified registry key or entry populated
Windows Event Log	Computers that reported an audit event in the last five minutes
Operating system version	Computers running Windows Server 2003 and later
Hardware inventory	Computers with a Pentium III processor
Hardware configuration	Computers with network adapters on in level 3
Service associations	Computers that have any service dependent on the SQL service

A WMI filter consists of one or more WMI Query Language (WQL) queries. The WMI filter applies to every policy setting in the GPO, so administrators must create separate GPOs if they have different filtering requirements for different policy settings. The WMI filters are evaluated on the destination computer after the list of potential GPOs is determined and filtered based on security group membership.

Although you can perform limited inventory-based targeting for software deployment by combining Group Policy–based software deployment with WMI filters, this is not recommended as a general practice for the following reasons:

• Each GPO can only have one WMI filter. If applications have different inventory requirements, you need multiple WMI filters and therefore multiple GPOs. Increasing the number of GPOs impacts startup and logon times and also increases management overhead.

• WMI filters can take significant time to evaluate, so they can slow down logon and startup time. The amount of time depends on the construction of the query.

Example WMI filters

As mentioned, WMI filters are most useful as tools for exception management. By filtering for particular criteria, you can target particular GPOs to only specific users and computers. The following section describes WMI filters that illustrate this technique.

Targeting based on operating system

In this example, an administrator wants to deploy an enterprise monitoring policy, but wants to target only Windows Vista–based computers. The administrator can create a WMI filter such as the following:

Select * from Win32_OperatingSystem where Caption like "%Vista%"

Most WMI filters use the Root\CimV2 namespace, and this option is populated by default in the GPMC user interface.

Because WMI filters are ignored on Windows 2000-based computers, a filtered GPO always applies on these computers. However, you can work around this by using two GPOs and giving the one with Windows 2000 settings higher precedence (by using link order). Then use a WMI filter for that Windows 2000 GPO, and only apply it if the operating system is Windows 2000, not Windows Vista or Windows XP. The Windows 2000–based computer will receive the Windows 2000 GPO and will override the policy settings in the Windows Vista or Windows XP GPO. The Windows Vista or Windows XP client will receive all the policy settings in the Windows Vista or Windows XP GPO.

Targeting based on hardware inventory

In this example, an administrator wants to distribute a new network connection manager tool only to desktops that have modems. The administrator can deploy the package by using the following WMI filter to target those desktops:

Select * from Win32_POTSModem Where Name = " MyModem"

If you use Group Policy with a WMI filter, remember that the WMI filter applies to all policy settings in the GPO. If you have different requirements for different deployments, you need to use different GPOs, each with its own WMI filter.

Targeting based on configuration

In this example, an administrator does not want to apply a GPO on computers that support multicast. The administrator can use the following filter to identify the computers that support multicast:

Select * from Win32_NetworkProtocol where SupportsMulticasting = true

Targeting based on amount of disk space and file system type

In this example, an administrator wants to target computers that have more than 10 megabytes (MB) of available space on the C, D, or E partition. The partitions must be located on one or more local fixed disks, and they must be running the NTFS file system. The administrator can use the following filter to identify computers that meet these criteria:

SELECT * FROM Win32_LogicalDisk WHERE (Name = " C:"  OR Name = " D:"  OR Name = " E:" ) AND DriveType = 3 AND FreeSpace > 10485760 AND FileSystem = " NTFS"

In the preceding example, DriveType = 3 represents a local disk and FreeSpace units are in bytes (10 MB = 10,485,760 bytes).

To create a WMI filter

1. In the GPMC console tree, right-click WMI Filters in the forest and domain in which you want to add a WMI filter.

2. Click New.

3. In the New WMI Filter dialog box, type a name for the new WMI filter in the Name box, and then type a description of the filter in the Description box.

4. Click Add.

5. In the WMI Query dialog box, either leave the default namespace or specify another namespace by doing one of the following:

   • In the Namespace box, type the name of the namespace that you want to use for the WMI query. The default is root\CimV2. In most cases, you do not need to change this.

   • Click Browse, select a namespace from the list, and then click OK.

6. Type a WMI query in the Query box, and then click OK.

7. To add more queries, repeat steps 4 through 6 to add each query.

8. After you add all the queries, click Save.

The WMI filter is now available to be linked.

Using Group Policy inheritance

It is often useful to define a corporate-standard GPO. As used here, "corporate standard" refers to policy settings that apply to a broad set of users in an organization. An example of a scenario in which defining a corporate-standard GPO might be appropriate is a business requirement that states: "Only specially authorized users can access the command prompt or the Registry Editor." Group Policy inheritance can help you apply these corporate standards while customizing policy settings for different groups of users.

One way to do this is to set the policy settings Prevent access to the command prompt and Prevent access to registry editing tools in a GPO (such as the Standard User Policy GPO) that is linked to an OU (such as the User Accounts OU). This applies these policy settings to all users in that OU. Then create a GPO, such as an Administrator User Policy GPO, which explicitly allows administrators access to the command prompt and registry editing tools. Link the GPO to the Administrators OU, which overrides the policy settings configured in the Standard User Policy GPO. This approach is illustrated in Figure 4.

If another group of users requires access to the command prompt, but not the registry, you can create another GPO that allows them to do so. Access to the registry editing tools is still denied because the new GPO does not override the registry tools setting made in the Standard User Policy GPO. Typically, a corporate standard GPO includes more policy settings and configuration options than those shown in the preceding illustration. For example, corporate standard GPOs are typically used to achieve the following:

• Remove all potentially harmful and nonessential functionality for users.

• Define access permissions, security settings, and file system and registry permissions for member servers and workstations.

Typically, GPOs are assigned to the OU structure instead of the domain or site. If you structure your OU model around users, workstations, and servers, it is easier to identify and configure corporate-standard policy settings. You can also disable either the user or computer portions of the GPO that do not apply, making Group Policy easier to manage.

When you set default values for security-related policy settings such as restricted group membership, file system access permissions, and registry access permissions, it is important to understand that these policy settings work on a last-writer-wins principle, and that the policy settings are not merged. The following example demonstrates this principle.

Example: Last-writer-wins principle

An administrator creates a Default Workstations GPO that defines the membership of the local Power Users group as the Technical Support and Help Desk groups. The Business Banking group wants to add the Business Banking Support group to this list and creates a new Default Workstations GPO to do so. Unless the new GPO specifies that all three groups are members of Power Users, only the Business Banking Support group has Power User rights on affected workstations.

Deploying Group Policy

Before deploying Group Policy, make sure that you are familiar with the procedures for working with GPOs, including creating GPOs, importing policy settings, backing up and restoring GPOs, editing and linking GPOs, setting exceptions to default inheritance of GPOs, filtering the application of GPOs, delegating administration, and using Group Policy Modeling for planning and Group Policy Results for evaluating GPO application.

Always fully test your GPOs in a safe environment prior to production deployment. The more you plan, design, and test GPOs prior to deployment, the easier it is to create, implement, and maintain an optimal Group Policy deployment. The importance of testing and pilot deployments in this context cannot be overemphasized. Your tests should closely simulate your production environment.

A design is not complete until you test and validate all its significant variations and your deployment strategy. Thorough testing of your GPO implementation strategy is not possible until you configure your GPOs by using specific policy settings, such as security settings, and desktop and data management. Do this for each group of users and computers in the network. Use your test environment to develop, test, and validate specific GPOs. Take full advantage of the GPMC Modeling Wizard and the Results Wizard.

Also, consider an iterative implementation of Group Policy. That is, rather than deploying 100 new Group Policy settings, stage and then initially deploy only a few policy settings to validate that the Group Policy infrastructure is working well.

For more information about staging Group Policy, see Staging Group Policy deployments in this guide.

Creating and working with GPOs

Because changes to a GPO take place immediately, keep the GPO unlinked from its production location (site, domain, or OU) until you have fully tested it in a test environment. While you are developing the GPO, keep it either unlinked or linked to a test OU.

This section describes the process of creating and deploying GPOs. For more information about testing your Group Policy configurations prior to deployment, see Staging Group Policy deployments in this guide.

The following procedures describe how to create and edit GPOs by using the GPMC.

To create an unlinked GPO

1. In the GPMC console tree, right-click Group Policy Objects in the forest and domain in which you want to create a new unlinked GPO.

2. Click New.

3. In the New GPO dialog box, specify a name for the new GPO, and then click OK.

Use the following procedure to edit a GPO.

To edit a GPO

1. In the GPMC console tree, expand Group Policy Objects in the forest and domain containing the GPO that you want to edit.

2. Right-click the GPO that you want to edit, and then click Edit.

3. In the console tree, expand items as needed to locate the item that contains the policy settings that you want to modify. Click an item to view the associated policy settings in the details pane.

4. In the details pane, double-click the names of the policy setting that you want to edit. Note that some policy settings, such as the policy settings for deploying a new software installation package, use unique user interfaces.

5. In the Properties dialog box, modify policy settings as needed, and then click OK.

To link a GPO

The primary way to apply the policy settings in a GPO to users and computers is by linking the GPO to a container in Active Directory. GPOs can be linked to three types of containers in Active Directory: sites, domains, and OUs. A GPO can be linked to multiple Active Directory containers.

GPOs are stored on a per-domain basis. For example, if you link a GPO to an OU, the GPO is not actually located in that OU. A GPO is a per-domain object that can be linked anywhere in the forest. The UI in the GPMC helps clarify the distinction between links and actual GPOs.

In the GPMC, you can link an existing GPO to Active Directory containers by using either of the following methods:

• Right-click a site, domain, or OU item, and then click Link an Existing GPO. This procedure is equivalent to choosing Add on the Group Policy tab that was available in the Active Directory Users and Computers snap-in, prior to installing the GPMC. This procedure requires that the GPO already exist in the domain.

• Drag a GPO from under the Group Policy Objects item to the OU to which you want to link the GPO. This drag-and-drop functionality works only within the same domain.

You can also use the GPMC to simultaneously create a new GPO and link it, as described in the next section.

To create and link a GPO

To create a GPO and link it to a site, domain, or OU, you must first create the GPO in the domain, and then link it.

The following procedure is equivalent to clicking New on the Group Policy tab available in the Active Directory Users and Computers snap-in, prior to installing the GPMC. Although this operation is presented in the GPMC as one action, two actions are taking place: A GPO is created in the domain, and then the new GPO is linked to the site, domain, or OU.

To create a GPO and link it to a site, domain, or OU

1. In the GPMC console tree, expand Group Policy Objects in the forest and domain containing the GPO that you want to link.

2. Right-click a domain or an OU item, and then click Create a GPO in this domain, and Link it here.

3. In the New GPO dialog box, type a name for the new GPO, and then click OK.

Use the following procedure to unlink a GPO (that is, to delete a link from a GPO to a site, domain, or OU).

To delete a link to a GPO from a site, domain, or OU

1. In the GPMC console tree, expand Group Policy Objects in the forest and domain containing the GPO that you want to unlink.

2. Click the GPO that you want to unlink.

3. In the details pane, click the Scope tab.

4. If the following message appears, click OK to close the message (you can also specify that the message not be displayed again when you create a new GPO and link it):

   "You have selected a link to a Group Policy object (GPO). Except for changes to link properties, changes you make here are global to the GPO and will impact all other locations where this GPO is linked."

5. In the Links section, right-click the Active Directory object with the link you want to delete, and then click Delete Link(s).

Note

Deleting a link to a GPO is different than deleting a GPO. It you delete only a link to the GPO, the GPO still exists, as do any other existing links from other domains to that GPO. However, if you delete a GPO, you will be prompted to delete the GPO and all links to it in the selected domain. Doing this does not delete links to the GPO from other domains. Be sure to remove links to the GPO in other domains before deleting this GPO from this domain.

Disabling the User Configuration or Computer Configuration settings in a GPO

If you are creating a GPO to set only user-related policy settings, you can disable the Computer Configuration settings in the GPO. Doing this slightly reduces computer startup time because the Computer Configuration settings in the GPO do not have to be evaluated to determine if any policy settings exist. If you are configuring only computer-related policy settings, disable the User Configuration settings in the GPO.

Review Figure 5 to identify the GPMC items referred to in the procedure that follows it.

To disable the User Configuration or Computer Configuration settings in a GPO

1. In the GPMC console tree, expand Group Policy Objects in the forest and domain containing the GPO that contains the policy settings you want to disable.

2. Right-click the GPO that contains the policy settings that you want to disable.

3. In the GPO Status list, select one of these choices:

   • All policy settings disabled

   • Computer configuration settings disabled

   • Enabled (default)

   • User configuration settings disabled

Special considerations for site-linked GPOs

GPOs linked to sites might be appropriate to use for setting policy for proxy settings, printers, and network-related settings. Any GPO that is linked to a site container is applied to all computers in that site, regardless of which domain in the forest the computer belongs to. This behavior has the following implications:

• Ensure that the computers do not access a site GPO across a WAN link, which would lead to significant performance issues.

• By default, to manage site GPOs, you need to be either a member of the Enterprise Admins group, or a member of the Domain Admins group in the forest root domain.

• Active Directory replication between domain controllers in different sites occurs less frequently than replication between domain controllers in the same site, and occurs during scheduled periods only. Between sites, FRS replication is not determined by the site link replication schedule; this is not an issue within sites.

  The directory service replication schedule and frequency are properties of the site links that connect sites. The default inter-site replication frequency is three hours. To change this frequency, use the following procedure.

  To change inter-site replication frequency

  1. Open Active Directory Sites and Services.

  2. In the console tree, expand Sites, expand Inter-Site Transports, expand IP, and then click the inter-site transport folder that contains the site link for which you are configuring inter-site replication.

  3. In the details pane, right-click the site link whose inter-site replication frequency you want to configure, and then click Properties.

  4. On the General tab, in Replicate every, type or select the number of minutes between replications.

  5. Click OK.

Changing either the replication frequency or schedule can significantly affect Group Policy. For example, assume that you have replication frequency set to three hours or longer, and you create a GPO and link it to an OU in a domain that spans several sites. You will likely need to wait several hours before all users in that OU receive the GPO.

If most of the users in an OU are in a remote location, and you have a domain controller in that site, you can work around inter-site replication latency by performing all Group Policy operations on the domain controller in that site.

Using loopback processing to configure user policy settings

The User Group Policy loopback processing mode policy setting is an advanced option that is intended to keep the configuration of the computer the same regardless of who logs on. This policy setting is appropriate in certain closely managed environments with special-use computers, such as classrooms, public kiosks, and reception areas. For example, you might want to enable this policy setting for a specific server, such as a terminal server. Enabling the loopback processing mode policy setting directs the system to apply the same user policy settings for any user who logs onto the computer, based on the computer.

When you apply GPOs to users, normally the same set of user policy settings applies to those users when they log on to any computer. By enabling the loopback processing policy setting in a GPO, you can configure user policy settings based on the computer that they log on to. Those policy settings are applied regardless of which user logs on. When you enable the loopback processing mode policy setting, you must ensure that both the Computer Configuration and User Configuration settings in the GPO are enabled.

You can configure the loopback policy setting by using the GPMC to edit the GPO and enabling the User Group Policy loopback processing mode policy setting under Computer Configuration\Policies\Administrative Templates\System\Group Policy. Two options are available:

• Merge mode: In this mode, the list of GPOs for the user is gathered during the logon process. Then, the list of GPOs for the computer is gathered. Next, the list of GPOs for the computer is added to the end of the GPOs for the user. As a result, the computer’s GPOs have higher precedence than the user’s GPOs. If the policy settings conflict, the user policy settings in the computer's GPOs will be applied rather than the user's normal policy settings.

• Replace mode: In this mode, the list of GPOs for the user is not gathered. Instead, only the list of GPOs based on the computer object is used. The User Configuration settings from this list are applied to the user.

Delegating administration of Group Policy

Your Group Policy design will probably call for delegating certain Group Policy administrative tasks. Determining what degree to centralize or distribute administrative control of Group Policy is one of the most important factors in assessing the needs of your organization. In organizations that use a centralized administration model, an IT group provides services, makes decisions, and sets standards for the entire company. In organizations that use a distributed administration model, each business unit manages its own IT group.

You can delegate the following Group Policy tasks:

• Managing individual GPOs (for example, granting Edit or Read access to a GPO)

• Performing the following Group Policy tasks on sites, domains, and OUs:

  • Managing Group Policy links for a given site, domain, or OU

  • Performing Group Policy Modeling analyses for objects in that container (not applicable for sites)

  • Reading Group Policy Results data for objects in that container (not applicable for sites)

• Creating GPOs

• Creating WMI filters

• Managing and editing individual WMI filters

Based on your organization’s administrative model, you need to determine which aspects of configuration management can best be handled at the site, domain, and OU levels. You also need to determine how responsibilities at each site, domain, and OU level might be further subdivided among the available administrators or administrative groups at each level.

When deciding whether to delegate authority at the site, domain, or OU level, keep in mind the following considerations:

• Authority delegated at the domain level affects all objects in the domain, if the permission is set to inherit to all child containers.

• Authority delegated at the OU level can affect either that OU only, or that OU and its child OUs.

• Managing permissions is easier and more efficient if you assign control at the highest OU level possible.

• Authority delegated at the site level is likely to span domains and can influence objects in domains other than the domain where the GPO is located.

The following sections describe how to use the GPMC to perform these delegation tasks.

Delegating management of individual GPOs

Using the GPMC, you can easily grant permissions on a GPO to additional users. The GPMC manages permissions at the task level. There are five levels of permissions allowable on a GPO: Read, Edit, Edit/Delete/Modify Security, Read (from Security Filtering), and Custom. These permission levels correspond to a fixed set of low-level permissions. Table 3 shows the corresponding low-level permissions for each option.

Table 3 GPO Permission Options and Low-Level Permissions

GPO permission option	Low-level permissions
Read	Allow Read Access on the GPO.
Read (from Security Filtering)	This setting cannot be set directly, but appears if the user has Read and Apply Group Policy permissions to the GPO, which is set by using Security Filtering on the Scope tab of the GPO.
Edit settings	Allow Read, Write, Create Child Objects, Delete Child Objects.
Edit settings, delete, and modify security	Allow Read, Write, Create Child Objects, Delete Child Objects, Delete, Modify Permissions, and Modify Owner. This grants full control on the GPO, except that the Apply Group Policy permission is not set.
Custom	Any other combinations of rights, such as denying permissions, appear as Custom permissions. You cannot set custom rights by clicking Add. They can only be set by clicking Advanced, and then modifying rights directly.

To grant permissions for a GPO to a user or group, use the following procedure.

To grant permissions for a GPO to a user or group

1. In the GPMC console tree, expand Group Policy Objects in the forest and domain containing the GPO that you want to edit.

2. Click the GPO for which you want to grant permissions.

3. In the details pane, click the Delegation tab.

4. Click Add.

5. In the Select User, Computer, or Group dialog box, specify the user or group to which you want to grant permissions, and then click OK.

6. In the Add Group or User dialog box, under Permissions, click the level of permissions that you want to grant to the user or group, and then click OK.

Note that the Apply Group Policy permission, which is used for security filtering, cannot be set by using the Delegation tab. Because the Apply Group Policy permission is used for scoping the GPO, this permission is managed on the Scope tab for the GPO in the GPMC. To grant a user or group the Apply Group Policy permission for a GPO, on the Scope tab for the relevant GPO, click Add, and then specify the user or group. The name of the user or group will appear in the Security Filtering list. When you grant a user Security Filtering permissions on the Scope tab, you are actually setting both the Read and Apply Group Policy permissions.

Table 4 lists the default security permission settings for a GPO.

Table 4. Default Security Permissions for GPOs

Security group	Permissions
Authenticated Users	Read (from Security Filtering)
ENTERPRISE DOMAIN CONTROLLERS	Read
Domain Admins, Enterprise Admins, Creator Owner, SYSTEM	Edit settings, delete, modify security

Note

Because administrators are also part of the Authenticated Users group, they have the Apply Group Policy access control entry (ACE) set to Allow by default. As a result, policy settings apply to them as well if they are located in the container where the GPO is linked.

Delegating Group Policy tasks on sites, domains, and OUs

You can delegate the following three Group Policy tasks (permissions) on a per-container basis in Active Directory:

• Linking GPOs to an Active Directory container (site, domain, or OU)

• Performing Group Policy Modeling analysis for objects in that container (domains and OUs)

• Reading Group Policy Results data for objects in that container (domains and OUs)

To delegate administrative tasks, you must grant the permission that corresponds to the task on the appropriate Active Directory container by using the GPMC.

By default, members of the Domain Admins group have GPO linking permission for domains and OUs, and members of the Enterprise Admins and Domain Admins groups in the forest root domain can manage links to sites. You can delegate permissions to additional groups and users by using the GPMC.

By default, access to Group Policy Modeling and remote access to Group Policy Results data is restricted to members of the Enterprise Admins and Domain Admins groups. You can delegate access to this data to lower-level administrators by setting the appropriate permissions in the GPMC.

The following procedures describe how to delegate Group Policy administrative tasks by modifying the appropriate permissions on Active Directory containers.

To delegate Group Policy administrative tasks on a site, domain, or OU

1. In the GPMC, click the name of the site, domain, or OU on which you want to delegate Group Policy administrative tasks.

2. In the details pane for the site, domain, or OU, click the Delegation tab.

3. In the Permission list, click one of the following: Link GPOs, Perform Group Policy Modeling analyses, or Read Group Policy Results data. Note that only Link GPOs is available for sites.

4. To delegate the task to a new user or group, click Add, and then specify the user or group to add.

5. To modify the Applies To setting for an existing permission (that is, to change the Active Directory container to which the permission granted to a specific user or group applies), right-click the user or group in the Groups and Users list and then click either This container only or This container and children.

6. To remove an existing group or user from the list of groups or users who have been granted the specified permission, click the user or group in the Groups and users list, and then click Remove. Note that you must be a member of the Domain Admins group to do this.

7. To add or remove custom permissions:

   1. Click Advanced on the Security tab.

   2. Under Group or user names, click the user or group whose permissions you want to change.

   3. Under Permissions, modify permissions as needed, and then click OK.

Delegating creation of GPOs

The ability to create GPOs in a domain is a permission that is managed on a per-domain basis. By default, only members of the Domain Admins, Enterprise Admins, Group Policy Creator Owners, and SYSTEM groups can create new GPOs.

A member of the Domain Admins group can delegate the creation of GPOs to any group or user. There are two methods of granting a group or user this permission, both of which grant identical permissions:

• Add the group or user to the Group Policy Creator Owners group. This was the only method available before the GPMC.

• Use the GPMC to explicitly grant the group or user permission to create GPOs. To do this, in the GPMC console tree, click Group Policy Objects, click the Delegation tab, and then modify permissions as needed.

When a non-administrator member of the Group Policy Creator Owners group creates a GPO, that user becomes the creator owner of the GPO, and can edit and modify permissions on the GPO. However, members of the Group Policy Creator Owners group cannot link GPOs to containers unless they have been separately delegated the right to do so on a particular site, domain, or OU. Being a member of the Group Policy Creator Owners group gives the non-administrator full control of only the GPOs that the user creates. Group Policy Creator Owner members do not have permissions for GPOs that they do not create.

Note

When an administrator creates a GPO, members of the Domain Admins group become the Creator Owner of the GPO. By default, members of the Domain Admins group can edit all GPOs in the domain.

The right to link GPOs is delegated separately from the right to create GPOs and the right to edit GPOs. Remember to delegate both rights to the groups you want to create and link GPOs. By default, non-Domain Admins cannot manage links, and this prevents them from being able to use the GPMC to create and link a GPO. However, non-Domain Admins can create an unlinked GPO if they are members of the Group Policy Creator Owners group. After a non-Domain Admin creates an unlinked GPO, the Domain Admin, or someone else who has been delegated permissions to link GPOs to containers, can link the GPO as appropriate.

Because the Group Policy Creator Owners group is a domain global group, it cannot contain members from outside the domain. Therefore, if you want to delegate permissions to create GPOs to users outside the domain, you must instead use the GPMC to explicitly grant such users the appropriate permissions.

To do this, create a new domain local group in the domain (for example, "GPCO—External"), grant that group GPO creation permissions in the domain, and then add domain global groups from external domains to that group. For users and groups in the domain, you should continue to use the Group Policy Creator Owners group to grant GPO-creation permissions.

Delegating creation of WMI filters

You can delegate either of the following two levels of permission to a user or group for creating WMI filters:

• Creator Owner: Allows the user or group to create new WMI filters in the domain, but does not grant permissions to manage WMI filters created by other users.

• Full Control: Allows the user or group to create WMI filters, and grants full control on all WMI filters in the domain, including new filters that are created after users are granted this permission.

You can delegate these permissions by using the GPMC. In the GPMC console tree, click WMI Filters. In the details pane, click the Delegation tab, and then delegate permissions as needed.

Delegating permissions for managing individual WMI filters

You can delegate either of the following two levels of permissions to a user or group for managing an individual WMI filter:

• Edit: Allows the user or group to edit the selected WMI filter.

• Full Control: Allows the user or group to edit, delete, and modify security on the selected WMI filter.

You can delegate these permissions by using the GPMC. In the GPMC console tree, click the WMI filter for which you want to delegate permissions. In the details pane, click the Delegation tab, and then delegate permissions as needed.

Note that all users have Read access to all WMI filters. The GPMC does not allow this permission to be removed. If Read permission were to be removed, Group Policy processing on the destination computer would fail.

Defining Group Policy operational procedures

To facilitate future management of Group Policy, you should develop operational procedures to ensure that changes to GPOs are made in an authorized and controlled manner. In particular, make sure that all new GPOs and changes in existing GPOs are properly staged before deployment to your production environment. You should also create regular backups of your GPOs.

In some organizations, different teams might be responsible for managing different aspects of Group Policy. For example, a software deployment team is typically concerned with the policy settings under User Configuration\Policies\Software settings\Software Installation and Computer Configuration\Policies\Software Settings\Software Installation. The remaining policy settings, relating to items such as scripts and Folder Redirection, are unlikely to be of interest to this team.

To reduce complexity and minimize the likelihood of introducing errors, consider creating separate GPOs for different groups of administrators. Alternatively, you might restrict administrators' access to the parts of Group Policy they are authorized to change. You can use the Restricted/Permitted Snap-ins\Extension snap-ins policy setting to restrict the snap-ins that administrators can access. This policy setting is available when editing a GPO under User Configuration\Policies\Administrative Templates\Windows Components\Microsoft Management Console. The Restricted/Permitted Snap-ins\Extension snap-ins policy setting pertains to the UI that is accessible by using the editor accompanying the GPMC. Remember that some teams might need access to more than one type of extension snap-in.

Note

The MMC policy settings only affect the UI that is accessible by using MMC; if Group Policy is edited by using programmatic means, any GPO settings can be edited.

For more information about these and other Group Policy settings, double-click the policy setting in the details pane when editing a GPO, and then click the Explain tab in the policy Properties dialog box. Note that this information is always available when you click a policy setting, if Extended View is enabled. By default, this view is enabled.

Specifying a domain controller for editing Group Policy

In each domain, the GPMC uses the same domain controller for all operations in that domain. This includes all operations on the GPOs that are located in that domain, as well as all other objects in that domain, such as OUs and security groups.

The GPMC also uses the same domain controller for all operations on sites. This domain controller is used to read and write information about what links to GPOs exist on any given site, but information regarding the GPOs themselves is obtained from the domain controllers of the domains that host the GPOs.

By default, when you add a new domain to the console, the GPMC uses the domain controller that holds the primary domain controller (PDC) emulator operations master role in that domain for operations in that domain. For managing sites, the GPMC uses the PDC emulator in the user’s domain by default.

The choice of domain controllers is important for administrators to consider to avoid replication conflicts. This is especially important because GPO data is located both in Active Directory and in Sysvol, which rely on independent replication mechanisms to replicate GPO data to the various domain controllers in the domain. If two administrators simultaneously edit the same GPO on different domain controllers, it is possible for the changes written by one administrator to be overwritten by another administrator, depending on replication latency.

To avoid this, the GPMC uses the PDC emulator in each domain as the default. This helps ensure that all administrators are using the same domain controller and guards against data loss. However, it might not always be desirable for an administrator to use the PDC to edit GPOs. For example, if the administrator is located in a remote site, or if the majority of the users or computers targeted by the GPO are in a remote site, the administrator might choose to target a domain controller at the remote location. For example, if you are an administrator in Japan and the PDC emulator is in New York, it might be inconvenient to rely on a WAN link to access the New York PDC emulator.

Important

If multiple administrators manage a common GPO, all administrators should use the same domain controller when editing a particular GPO in order to avoid collisions in the FRS.

To specify the domain controller to be used for a given domain or for all sites in a forest, use the Change Domain Controller command in the GPMC. In either case, the following four options are available:

• The domain controller with the Operations Master token for the PDC emulator (the default option)

• Any available domain controller

• Any available domain controller running Windows Server 2003 or later

• This domain controller (in this case, you must select the domain controller).

The selected option is used each time that you open a saved console, until you change the option.

This preference is saved in the .msc file and is used when you open that .msc file. It is generally not recommended that you use the Any available domain controller option unless you are performing read-only operations.

Group Policy processing and slow links

Sometimes Group Policy is not applied when the connection speed falls below specified thresholds. Therefore, when your Group Policy solution calls for applying policy over slow links or by using remote access, you need to consider policy settings for slow link detection.

Although slow links and remote access are related, Group Policy processing varies for each. Having a computer connected to a LAN does not necessarily imply a fast link, nor does a remote access connection imply a slow link. The default value for what Group Policy considers a slow link is any rate slower than 500 Kilobits per second (Kbps). You can change this threshold by using Group Policy. The following section describes the phases of Group Policy processing and how Group Policy in Windows Server 2008 measures link speed.

Group Policy processing phases

Group Policy processing occurs in three phases. Within each phase of the process is a subset of processing scenarios. When processing Group Policy, the Group Policy service iterates through each scenario as it transitions through each phase. The phases of Group Policy processing are:

• Preprocessing phase: Indicates the beginning instance of Group Policy processing and gathers information required to process Group Policy.

• Processing phase: Uses the information gathered in the preprocessing phase to cycle through each Group Policy extension, which applies policy settings to the user or computer.

• Post-processing phase: Reports the end of the policy processing instance and records if the instance ended successfully, was processed with warnings, or failed.

The Group Policy service relies on successful communication with a domain controller to retrieve computer-specific and user-specific information. Additionally, the service uses the domain controller to discover the GPOs within the scope of the computer or user.

How Group Policy measures link speed

For Group Policy in Windows Server 2008, the slow link detection process has been improved. In Group Policy in Windows Server 2003, a client searches for its domain controller by using Internet Control Message Protocol (ICMP) to determine the availability of the domain controller and the speed of the link between the client and domain controller. In Windows Server 2008, the Group Policy service determines the link speed by using the Network Location Awareness (NLA) service to sample the current TCP traffic between the client and the domain controller. This sampling occurs during the pre-processing phase.

The Group Policy service requests the NLA service to start sampling TCP bandwidth on the network interface that hosts the domain controller shortly after the Group Policy service has discovered a domain controller. The Group Policy service continues through the preprocessing phase by communicating with the domain controller to discover the role of the current computer (member or domain controller), the logged-on user, and GPOs within the scope of the computer or user. Then, the Group Policy service requests the NLA service to stop sampling the TCP traffic and provide an estimated bandwidth between the computer and the domain controller, based on the sampling. As mentioned, by default Group Policy considers a link slow when the NLA service sampling is lower than 500 Kbps.

You can use a policy setting to define a slow link for the purpose of applying Group Policy, as described in the following sections.

Specifying Group Policy settings for slow link detection

You can partially control which Group Policy extensions are processed over a slow link. By default, when processing takes place over a slow link, not all components of Group Policy are processed. Table 5 lists the default settings for processing Group Policy over slow links.

Table 5. Default Settings for Processing Group Policy over Slow Links

Setting	Default
Security	ON (cannot be disabled)
IP Security	ON
EFS	ON
Software Restriction Policies	ON
Wireless	ON
Administrative Templates	ON (cannot be disabled)
Software Installation	OFF
Scripts	OFF
Folder Redirection	OFF
QoS Packet Scheduler	ON
Disk Quotas	OFF
Internet Explorer Zone Mapping	ON
IE maintenance	ON
Group Policy Preferences	ON
Windows Search	ON
Deployed Printer Connections	OFF
802.3 Group Policy	ON
Microsoft Offline Files	ON

You can use a Group Policy setting to define a slow link for the purpose of applying and updating Group Policy. The default value defines a rate slower than 500 Kbps as a slow link.

To specify settings for Group Policy slow link detection for computers, when editing a GPO use the Group Policy slow link detection policy setting located in Computer Configuration\Policies\Administrative Templates\System\Group Policy. The unit of measurement for connection speed is Kbps.

To configure this policy setting for users, use the Group Policy slow link detection policy setting in User Configuration\Policies\Administrative Templates\System\Group Policy.

For User Profiles, the Slow network connection timeout for user profiles policy setting is located in Computer Configuration\Policies\Administrative Templates\System\User Profiles node. This policy setting allows Group Policy to check the network performance of the file server that is hosting the user profile. This step is necessary because user profiles can be stored anywhere, and the server might not support IP. You must specify connection speeds in both Kbps and milliseconds when you configure this policy setting.

Important

If the Do not detect slow network connections policy setting is enabled, the Slow network connection timeout for user profiles policy setting is ignored.
If the Delete cached copies of roaming profiles policy setting is enabled, there is no local copy of the roaming profile to load when the system detects a slow connection.

Setting computer policy for client-side extensions for processing across slow links

Group Policy is implemented almost entirely as a series of client-side extensions, such as security, Administrative templates, and folder redirection. There is a computer policy that allows configuring slow-link behavior for each client-side extension. You can use these policy settings to specify the behavior of client-side extensions when processing Group Policy. There is a maximum of three options for each policy setting. The Allow processing across a slow network connection option controls processing policy settings across slow links. The other two options can be used to specify that the policy setting should not be processed in the background, or that the policy setting be updated and reapplied even if policy settings have not changed. For more information about policy for client-side extensions, see Specifying Group Policy settings for slow link detection in this guide.

Some extensions move large amounts of data, so processing across a slow link can affect performance. By default, only the Administrative templates and security-related policy settings are processed over a slow link.

You can configure Group Policy processing settings for the following policy settings:

• Software Installation

• IP Security

• EFS recovery

• Disk Quota

• Internet Explorer Maintenance

• Scripts

• Folder Redirection

• Registry

• Security

• Wired

• Wireless

• Group Policy Preferences

Configuration for these policy settings is described in Controlling client-side extensions by using Group Policy later in this guide.

Group Policy and remote access connections

Processing of Group Policy over a remote access connection differs from processing over a slow link. Group Policy is applied during a remote access connection as follows:

• When users click to select a remote connection option before logging on to a destination computer over the remote connection, both user and computer Group Policy settings are applied if the computer is a member of the domain that the remote access server belongs to or trusts. However, computer-based software installation policy settings are not processed, and computer-based startup scripts are not run because computer policy is normally processed before the logon screen appears. However, for a remote connection, the application of computer policy is completed as a background refresh during the logon process.

• When the processing of cached credentials is completed and a remote access connection is established, Group Policy is not applied, except during a background refresh.

Group Policy is not applied to computers that are members of a workgroup, because computer policy is never applied to computers that are in a workgroup.

Controlling client-side extensions by using Group Policy

Several Group Policy components include client-side extensions (typically implemented as .dll files) that are responsible for processing and applying Group Policy settings at the destination computers.

For each client-side extension, the GPO processing order is obtained from a list of GPOs, which is determined by the Group Policy engine during processing. Each client-side extension processes the resulting list of GPOs.

A computer policy exists to control the behavior of each of the Group Policy client-side extensions. Each policy includes up to three options, and some include more specific configuration options. You can configure computer policies for client-side extensions when editing a GPO by opening the Computer Configuration\Policies\Administrative Templates\System\Group Policy folder and then double-clicking the policy for the appropriate extension.

You can set the following computer policy options:

• Allow processing across a slow network connection. A few extensions transfer large amounts of data, so processing across a slow link can decrease performance. By default, only the Administrative templates and security policy settings are processed over a slow link. You can set this policy to mandate that other client-side extensions are also processed across a slow link. To control what is considered a slow link, use the Group Policy slow link detection policy setting. For more information, see Specifying Group Policy settings for slow link detection in this guide.

• Do not apply during periodic background processing. Windows applies Computer policy at startup and again every 90 minutes. Also, it applies User policy when the user logs on to the computer and in the background approximately every 90 minutes after that. The Do not apply during periodic background processing option enables you to override this behavior and prevent Group Policy from running in the background.

Note

The Software Installation and Folder Redirection extensions process Group Policy only at startup and when the user logs on to the network because of the risks in processing these policies in the background, when users might have applications and files open.

• Process even if the Group Policy objects have not changed. If GPOs on the server do not change, it is not usually necessary to continually reapply them to the destination computer, except to override possible local changes. Because users who are running as local administrators might be able to modify the parts of the registry where Group Policy settings are stored, you might want to reapply these policy settings as needed during the logon process or during periodic background processing to return the computer to the desired state.

For example, assume that Group Policy defines a specific set of security options for a file. Then a user who has administrative credentials logs on and changes those security options. You might want to enable the Process even if the Group Policy objects have not changed option so that the security options specified in Group Policy are reapplied the next time policy is refreshed. The same considerations apply to applications: With this option enabled, if Group Policy installs an application, but the user removes the application or deletes its icon, the application is readvertised the next time the user logs on to the computer.

By default, Security Policy settings delivered by Group Policy are applied every 16 hours (960 minutes) even if a GPO has not changed. It is possible to change this default period by using the registry entry MaxNoGPOListChangesInterval in the following subkey:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon \GPExtensions\{827D319E-6EAC-11D2-A4EA-00C04F79F83A}.

The data type of this entry is REG_DWORD and the value is number of minutes.

Warning

Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.

Group Policy and Sysvol

Policy settings information in GPOs is stored in two locations: Active Directory and the Sysvol folder of domain controllers. The Active Directory container is known as a Group Policy container, and the Sysvol folder contains the Group Policy template. The Group Policy container contains attributes that are used to deploy GPOs to the domain, OUs, and sites. The Group Policy container also contains a path to the Group Policy template, where most Group Policy settings are stored.

Information stored in the Group Policy template includes security settings, script files, and information for deploying applications, preferences, and Administrative template–based Group Policy settings. Administrative templates (.ADMX files) provide Group Policy setting information for the items that appear under Administrative Templates. In Group Policy for Windows Server 2008, you can store Administrative templates locally or centrally, in Sysvol. To store Administrative templates centrally, you must first create a PolicyDefinitions folder in the Sysvol share on an appropriate domain controller and then copy the Administrative template files that you want to apply across the domain to this folder.

Updates to Sysvol are replicated to all domain controllers in the domain, which results in increased network traffic and load placed on the domain controllers. Therefore, to minimize the impact of this operation in your domain, we recommend that you schedule the copying of Administrative templates to Sysvol outside core business hours.

Administrative templates files in Windows Server 2008 and Windows Vista are divided into .ADMX (language-neutral) and .ADML (language-specific) files. These two file formats replace the .ADM file format used in earlier versions of Windows, which used a proprietary markup language. .ADML files are XML-based ADM Language files that are stored in a language-specific folder. For example, English (United States) .ADML files are stored in a folder that is named “en-US.” By default, the %Systemroot%\PolicyDefinitions folder on a local computer stores all .ADMX files, and .ADML files for all languages that are enabled on the computer.

To download the Administrative template files for Windows Server 2008, see Administrative Templates (ADMX) for Windows Server 2008 (https://go.microsoft.com/fwlink/?LinkId=116434).

Benefits of storing ADMX files in the Sysvol folder

Two primary benefits are gained from creating and using an Administrative template central store. The first benefit is a replicated central storage location for domain Administrative templates. The GPMC included with Windows Server 2008 always uses an Administrative template central store over the local versions of the Administrative templates. This allows you to provide one set of approved Administrative templates for the entire domain.

The other benefit to storing Administrative templates in the Sysvol folder is to provide Administrative templates in a variety of languages. This is especially helpful for environments that span across different countries or use different languages. For example, when Administrative templates are stored in the Sysvol folder, an administrator of a domain can view Administrative template policy settings in English, while another administrator of the same domain views the same policy settings in French.

For more information about managing ADMX files and how to create a central store, see the Managing Group Policy ADMX Files Step-by-Step Guide (https://go.microsoft.com/fwlink/?LinkId=75124).

Drawbacks of storing ADMX files in the Sysvol folder

The benefits of creating and using an Administrative template central store are powerful; however, they do come at a small cost. The GPMC reads the entire set of Administrative template files when you edit, model or report on a GPO. Therefore, the GPMC must read these files from across the network. If you decide to create an Administrative templates central store, you should always connect the GPMC to the closest domain controller.

Note

The additional network traffic created from the central store is limited to users of the GPMC. Clients that apply and process Group Policy do not read the Administrative templates.

Updating Sysvol

In Group Policy for versions of Microsoft Windows earlier than Windows Vista, if you modify Administrative template policy settings on local computers, the Sysvol share on a domain controller within your domain is automatically updated with the new ADM files. In Group Policy for Windows Server 2008 and Windows Vista, if you modify Administrative template policy settings on local computers, Sysvol will not be automatically updated with the new ADMX or ADML files. This change in behavior is implemented to reduce network load and disk storage requirements, and to prevent conflicts from occurring between ADMX files and ADML files when edits to Administrative template policy settings are made across different locales. To ensure that any local updates are reflected in Sysvol as well, you must manually copy the updated ADMX or ADML files from the PolicyDefinitions folder on the local computer to the Sysvol\PolicyDefinitions folder on the appropriate domain controller.

Changing the Group Policy refresh interval

You can change the default refresh policy interval setting by using one of these policy settings: Group Policy Refresh Interval for Computers, Group Policy Refresh Interval for Domain Controllers, or Group Policy refresh Interval for Users. By using these policy settings, you can specify an update rate from 0 to 64,800 minutes (45 days).

Important

When you set the refresh interval to 0 minutes, the computer tries to update Group Policy every seven seconds. Because such updates might interfere with users’ work and increase network traffic, very short update intervals are appropriate only in test environments.

To prevent Group Policy from being updated while a computer is in use, you can enable the Turn off background refresh of Group Policy policy setting. If you enable this policy setting, the system waits until the current user logs off the system before updating Group Policy settings.

Group Policy refresh interval for computers

This policy setting specifies how often Windows updates Group Policy for computers in the background. It specifies a background update rate only for computer Group Policy settings. Windows updates computer Group Policy in the background every 90 minutes by default, with a random offset of 0–30 minutes. In addition to background updates, computer Group Policy is always updated when the system starts. This policy setting is available under Computer Configuration\Policies\Administrative Templates\System\Group Policy.

Group Policy refresh interval for domain controllers

This policy setting specifies how often Windows updates Group Policy in the background on domain controllers. By default, Windows updates Group Policy on domain controllers every five minutes. This policy setting is available under Computer Configuration\Policies\Administrative Templates\System\Group Policy.

Group Policy refresh interval for users

This policy setting specifies how frequently Windows updates Group Policy in the background only for user Group Policy settings. In addition to background updates, user Group Policy always updates when users log on. This policy is available under User Configuration\Policies\Administrative Templates\System\Group Policy.

Turn off background refresh of Group Policy

This policy setting prevents Windows from applying Group Policy settings while the computer is in use. The policy setting applies to Group Policy for computers, users, and domain controllers. This policy setting is available under Computer Configuration\Policies\Administrative Templates\System\Group Policy item.

Running command-line options to refresh policy

From a given computer, you can refresh the policy settings that are deployed to that computer by using the Gpupdate.exe tool. Table 6 describes parameters for Gpupdate.exe. The Gpupdate.exe tool is used in Windows Server 2008, Windows Vista, Windows Server 2003 and Windows XP environments.

The Gpudate.exe tool uses the following syntax:

gpupdate [/target:{computer|user}] [/force] [/wait:value] [/logoff] [/boot] [/sync]

Table 6 Gpudate.exe Parameters

Parameter	Description
/target:{computer|user}	Depending on what target you specify, Gpupdate.exe processes the computer policy settings, the current user policy settings, or both. By default, both the computer and the user policy settings are processed.
/force	Reapplies all policy settings and ignores processing optimizations. By default, only policy settings that have changed are applied.
/wait:value	Specifies the number of seconds that policy processing waits to finish. The default is 600 seconds. A value of 0 means no wait; -1 means wait indefinitely.
/logoff	Logs off after the policy refresh completes. This is required for Group Policy client-side extensions that do not process on a background refresh cycle but do process when the user logs on, such as user Software Installation and Folder Redirection. This option has no effect if there are no extensions called that require the user to log off.
/boot	Restarts the computer after the policy refresh completes. This is required for Group Policy client-side extensions that do not process on a background refresh cycle but do process when the computer starts up, such as computer Software Installation. This option has no effect if there are no extensions called that require the computer to be restarted.
/sync	Forces the next foreground policy application to be synchronous. Foreground Group Policy processing occurs at computer startup and user logon. You can specify foreground policy application for the user, computer, or both by using the /target parameter. If you specify this parameter and the /force and /wait parameters, the /force and /wait parameters will be ignored.
/?	Displays Help at the command prompt.

Using Group Policy Modeling and Group Policy Results to evaluate Group Policy settings

Before deploying Group Policy in a production environment, it is critical that you determine the effects of the policy settings that you have configured, individually and in combination. The primary mechanism for assessing your Group Policy deployment is to create a staging environment and then log on by using a test account. This is the best way to understand the impact and interaction of all the applied GPO settings. Staging your Group Policy deployment is critical for creating a successful managed environment. For more information, see Staging Group Policy deployments in this guide.

For Active Directory networks with at least one Windows Server 2008 domain controller, you can use Group Policy Modeling in the GPMC to simulate the deployment of GPOs to any destination computer. The primary tool for viewing the actual application of GPOs is by using Group Policy Results in the GPMC.

Using Group Policy Modeling to simulate Resultant Set of Policy

The Group Policy Modeling Wizard in the GPMC calculates the simulated net effect of GPOs. Group Policy Modeling can also simulate such factors as security group membership, WMI filter evaluation, and the effects of moving user or computer objects to a different Active Directory container. The simulation is performed by a service that runs on domain controllers running Windows Server 2008 or Windows Server 2003. These calculated policy settings are reported in HTML and displayed in the GPMC on the Settings tab in the details pane for the selected query. To expand and hide the policy settings under each item, click Hide or Show all so that you can view all the policy settings, or only a few. To perform Group Policy Modeling, you must have at least one domain controller running Windows Server 2008 or Windows Server 2003, and you must have the Perform Group Policy Modeling analyses permission on the domain or OU that contains the objects on which you want to run the query.

To run the wizard, in the GPMC console tree, right-click Group Policy Modeling (or an Active Directory container), and then click Group Policy Modeling Wizard. If you run the wizard from an Active Directory container, the wizard completes the Container fields for the user and computer with the Lightweight Directory Access Protocol (LDAP) distinguished name of that container.

After you complete the wizard, the results are displayed as if they were from a single GPO. They are also saved as a query that is represented by a new item in the GPMC, in Group Policy Modeling. Under the heading Winning GPO, the display also shows which GPO is responsible for each policy setting. You can also view more detailed precedence information (for example, which GPOs attempted to set the policy settings, but did not succeed) by right-clicking the query item and then clicking Advanced View. When you do this, the Resultant Set of Policy snap-in opens. When you view the properties for policy settings in Resultant Set of Policy, note that each policy setting has a Precedence tab.

Keep in mind that Group Policy Modeling does not include evaluating any local GPOs. Therefore, in some cases you might see a difference between the simulation and the actual results. You can save modeling results by right-clicking the query, and then click Save Report.

Note

Windows Server 2008 and Windows Vista observe a new policy setting, Turn off Local Group Policy objects processing. It allows you to disable Local Group Policy processing. You can find this policy setting under Computer Configuration\Policies\Administrative Templates\System\Group Policy.

Using Group Policy Results to determine Resultant Set of Policy

Use the Group Policy Results Wizard to determine which Group Policy settings are in effect for a user or computer by obtaining RSoP data from the destination computer. In contrast to Group Policy Modeling, Group Policy Results reveals the actual Group Policy settings that were applied to the destination computer. The destination computer must be running Windows XP Professional or later.

The policy settings are reported in HTML and are displayed in the GPMC browser window on the Summary and Settings tabs in the details pane for the selected query. You can expand and contract the policy settings under each item by clicking Hide or Show all so that you can see all the policy settings, or only a few. To remotely access Group Policy Results data for a user or computer, you must have the Remotely access Group Policy Results data permission on the domain or OU that contains the user or computer, or you must be a member of a local Administrators group on the appropriate computer and must have network connectivity to the destination computer.

You can run the wizard by right-clicking the Group Policy Results item, and then clicking Group Policy Results Wizard.

After you have completed the wizard, the GPMC creates a report that displays the RSoP data for the user and computer that you specified in the wizard. Under the heading Winning GPO, the display shows which GPO is responsible for each policy setting on the Settings tab.

You can save the results by right-clicking the query and then clicking Save Report.

Using Gpresult.exe to evaluate policy settings

You can run Gpresult.exe on the local computer to obtain the same data that you can obtain by using Group Policy Results Wizard in the GPMC. By default, Gpresult.exe returns policy settings in effect on the computer on which it runs.

For Windows Server 2008 and Windows Vista with Service Pack 1, Gpresult.exe uses the following syntax:

gpresult [/s <computer> [/u <domain>\<user> /p <password>]] [/scope {user|computer}] [/user <TargetUserName>] [/r | /v | /z] [/x | /h <filename> [/f]]

Table 7 describes the parameters for Gpresult.exe.

Table 7 Gpresult.exe Parameters

Parameter	Description
/s <computer>	Specifies the name or IP address of a remote computer. (Do not use backslashes.) The default is the local computer.
/u <domain>\<user>	Runs the command by using the account permissions of the user that is specified by <User> or <Domain\User>. The default is to use the permissions of the user who is currently logged onto the computer that issues the command.
/p <password>	Specifies the password of the user account that is specified in the /u parameter.
/scope {user | computer}	Displays either user or computer results. Valid values for the /scope parameter are user or computer. If you omit the /scope parameter, Gpresult displays both user and computer policy settings.
/user <TargetUserName>	Specifies the user name of the user whose RSoP data is to be displayed.
/r	Displays RSoP summary data.
/v	Specifies that the output display verbose policy information.
/z	Specifies that the output display all available information about Group Policy. Because this parameter produces more information than the /v parameter, redirect output to a text file when you use this parameter (for example, gpresult /z >policy.txt).
/x <filename>	Saves the report in XML format at the location and with the file name specified by the <filename> parameter (valid in Windows Server 2008 and Windows Vista SP1).
/h <filename>	Saves the report in HTML format at the location and with the file name specified by the <filename> parameter (valid in Windows Server 2008 and Windows Vista SP1).
/f	Forces Gpresult to overwrite the file name specified in the /x or /h parameter.
/?	Displays Help at the command prompt.

To run Gpresult.exe on your computer

1. Open an elevated command prompt. To open an elevated command prompt, click Start, right-click Command Prompt, and then click Run as administrator.

2. At the command prompt, type gpresult /h gpresult.html /f

3. At the command prompt, type Start gpresult.html to view the file.

Backing up, restoring, migrating, and copying GPOs

The GPMC provides mechanisms for backing up, restoring, migrating, and copying existing GPOs. These capabilities are very important for maintaining your Group Policy deployments in the event of an error or a disaster. They help you avoid having to manually recreate lost or damaged GPOs and then repeat the planning, testing, and deployment phases. Part of your ongoing Group Policy operations plan should include regular backups of all GPOs. Inform all Group Policy administrators about how to use the GPMC to restore GPOs.

The GPMC also provides for copying and importing GPOs, both from the same domain and across domains. You can use the GPMC to migrate an existing GPO, for example, from an existing domain into a newly deployed domain. You can either copy GPOs or import policy settings from one GPO into another GPO. Doing this can save you time and trouble by allowing you to re-use the contents of existing GPOs. Copying GPOs allows you to move straight from the staging phase to production, if you have configured the proper trust relationships between the environments. Importing GPOs allows you to transfer policy settings from a backed-up GPO into an existing GPO, and is especially useful in situations where a trust relationship is not present between the source and destination domains. If you want to reuse existing GPOs, copying also allows you to conveniently move GPOs from one production environment to another.

Using the GPMC to work with GPOs

To create GPO backups, you must have at least Read access to the GPOs and Write access to the folder in which the backups are stored. See Figure 6 to help you identify the items referred to in the procedures that follow.

Using the GPMC to back up GPOs and view GPO backups

The backup operation backs up a production GPO to the file system. The location of the backup can be any folder to which you have Write access. After backing up GPOs, you must use the GPMC to display and manipulate the contents of your backup folder, either by using the GPMC UI or programmatically by using a script. Do not interact with archived GPOs directly through the file system. After the GPOs are backed up, use the GPMC to process archived GPOs by using the Import and Restore operations.

Note

You can back up multiple instances of the same GPO to the same location because the GPMC uniquely identifies each backup instance and provides mechanisms to allow you to pick the instance of the archived GPO with which you want to work. For example, you can choose to display only the most recent backups when viewing the contents of a backup folder through the GPMC. This can be useful when you make backups of a GPO after changing it, and later need to restore a previous version of that GPO.

To back up all GPOs in a domain

1. In the GPMC console tree, expand the forest or domain that contains the GPOs that you want to back up.

2. Right-click Group Policy Objects, and then click Back Up All.

3. In the Backup Group Policy Object dialog box, enter the path to the location where you want to store the GPO backups. Alternatively, you can click Browse, locate the folder in which you want to store the GPO backups, and then click OK.

4. Type a description for the GPOs that you want to back up, and then click Back Up.

5. After the backup operation completes, a summary will list how many GPOs were successfully backed up and any GPOs that were not backed up.

6. Click OK.

To back up a specific GPO

1. In the GPMC console tree, expand Group Policy Objects in the forest or domain that contains the GPO that you want to back up.

2. Right-click the GPO you want to back up, and then click Back Up.

3. In the Backup Group Policy Object dialog box, enter the path to the location where you want to store the GPO backup. Alternatively, you can click Browse, locate the folder in which you want to store the GPO backup, and then click OK.

4. Type a description for the GPO that you want to back up, and then click Back Up.

5. After the backup operation completes, a summary will state whether the backup succeeded.

6. Click OK.

To view the list of GPO backups

1. In the GPMC console tree, expand the forest or domain that contains the GPOs that you want to back up.

2. Right-click Group Policy Objects, and the click Manage Backups.

3. In the Manage Backups dialog box, enter the path to the location where you stored the GPO backups that you want to view. Alternatively, you can click Browse, locate the folder that contains the GPO backups, and then click OK.

4. To specify that only the most recent version of the GPOs be displayed in the Backed up GPOs list, select the Show only the latest version of each GPO check box. Click Close.

Important

You should secure backed-up GPOs by ensuring that only authorized administrators have permission to access the folder to which you are saving GPOs. Use security permissions on the file system where they are backed up.

Using the GPMC to restore GPOs

You can also restore GPOs. This operation restores a backed-up GPO to the same domain from which it was backed up. You cannot restore a GPO from a backup into a domain that is different from the GPO’s original domain.

To restore a previous version of an existing GPO

1. In the GPMC console tree, expand Group Policy Objects in the forest or domain that contains the GPOs that you want to restore.

2. Right-click the GPO that you want to restore to a previous version, and then click Restore from Backup.

3. When the Restore Group Policy Object Wizard opens, follow the instructions in the wizard, and then click Finish.

4. After the restore operation completes, a summary will state whether the restore succeeded. Click OK.

To restore a deleted GPO

1. In the GPMC console tree, expand the forest or domain that contains the GPO that you want to restore.

2. Right-click Group Policy Objects, and then click Manage Backups.

3. In the Manage Backups dialog box, click Browse, and then locate the file that contains your backed-up GPOs.

4. In the Backed up GPOs list, click the GPO that you want to restore, and then click Restore.

5. When you are prompted to confirm the restore operation, click OK.

6. After the restore operation completes, a summary will state whether the restore succeeded. Click OK. Click Close.

Backing up and restoring WMI filter data, IPsec policy settings, and links to OUs

Links to WMI filters and IPsec policies are stored in GPOs and are backed up as part of a GPO. When you restore a GPO, these links are preserved if the underlying objects still exist in Active Directory. Links to OUs, however, are not part of the backup data and will not be restored during a restore operation.

Policy settings that are stored outside the GPOs, such as WMI filter data and IPsec policy settings are not backed up or restored during these processes. To back up and restore a small number of WMI filters, you can click the WMI Filters item in the GPMC or a specific WMI filter under this item, and then use the Import or Export commands as needed. For information about how to import or export a WMI filter, see "Import a WMI filter" and "Export a WMI filter" in the GPMC Help. Because you can only import or export a single WMI filter at a time by using these commands, we recommend this approach only if you need to back up or restore a few WMI filters.

To back up and restore a larger number of WMI filters, you can use the Ldifde command-line tool, as described in Customs Check—Importing and Exporting WMI Filters (https://go.microsoft.com/fwlink/?linkid=109519).

Note

Ldifde is a command-line tool that is built into Windows Server 2008. It is available if you have the AD DS or Active Directory Lightweight Directory Services (AD LDS) server role installed. To use Ldifde, you must run the Ldifde command from an elevated command prompt. For more information, see Ldifde (https://go.microsoft.com/fwlink/?LinkId=110104).

Assigning an IPsec policy to a GPO records a pointer to the IPsec policy that is inside the GPO attribute ipsecOwnersReference. The GPO itself contains only an LDAP distinguished name reference to the IPsec policy. Group Policy is used only to deliver the policy assignment to the computer’s IPsec service. The computer’s IPsec service then retrieves the IPsec policy from Active Directory, maintains a current cache of the policy locally, and keeps it current by using a polling interval that is specified in the IPsec policy itself.

To back up and restore IPsec policy settings, you must use the Export Policies and Import Policies commands in the IP Security Policy Management snap-in. The Export Policies command allows you to export all local IPsec policies and save them in a file with an .ipsec extension.

Using the GPMC to copy GPOs and import GPO settings

The GPMC allows you to copy GPOs, both in the same domain and across domains, and import Group Policy settings from one GPO to another. Perform these operations as part of your staging process before deployment in your production environment. These operations are also useful for migrating GPOs from one production environment to another.

Although the collection of policy settings that comprises a GPO is logically a single entity, the data for a single GPO is stored in multiple locations and in a variety of formats. Some data is contained in Active Directory and other data is stored in the Sysvol folder on domain controllers. This means that you cannot simply copy GPOs by copying a folder from one computer to another. However, the GPMC provides built-in support that allows you to do this safely and relatively simply.

A copy operation copies an existing, current GPO to the desired destination domain. A new GPO is always created as part of this process. The destination domain can be any trusted domain in which you have the right to create new GPOs. Simply add the desired forests and domains in the GPMC and use the GPMC to copy and paste (or drag and drop) the desired GPOs from one domain to another. To copy a GPO, you must have permission to create GPOs in the destination domain.

When copying GPOs, you can also copy the Discretionary Access Control List (DACL) on the GPO, in addition to the policy settings within the GPO. This is useful for ensuring that the new GPO that is created as part of the copy operation has the same security filtering and delegation options as the original GPO.

Importing a GPO allows you to transfer policy settings from a backed-up GPO to an existing GPO. Importing a GPO transfers only the GPO settings; it does not modify the existing security filtering or links on the destination GPO. Importing a GPO is useful for migrating GPOs across untrusted environments, because you only need access to the backed-up GPO, not the production GPO. Because an import operation only modifies policy settings, Edit permissions on the destination GPO are sufficient to perform the operation.

When copying or importing a GPO, you can specify a migration table, if the GPO contains security principals or UNC paths that might need to be updated when they are copied to the target domain. You use the Migration Table Editor (MTE) to create and edit migration tables. Migration tables are described in the next section, Using migration tables.

To copy a GPO

1. In the GPMC console tree, expand Group Policy Objects in the forest and domain containing the GPO that you want to copy.

2. Right-click the GPO that you want to copy, and then click Copy.

3. Do one of the following:

   • To place the copy of the GPO in the same domain as the source GPO, right-click Group Policy Objects, and then click Paste.

   • To place the copy of the GPO in a different domain (either in the same or a different forest), expand the destination domain, right-click Group Policy Objects, and then click Paste.

   • If you are copying within a domain, click Use the default permissions for new GPOs or Preserve the existing permissions, and then click OK.

4. If you are copying to or from another domain, follow the instructions in the wizard that opens, and then click Finish.

To import policy settings from a backed-up GPO into a GPO

1. In the GPMC console tree, expand Group Policy Objects in the forest and domain containing the GPO into which you want to import policy settings.

2. Right-click the GPO into which you want to import policy settings, and then click Import Settings.

3. When the Import Settings Wizard opens, follow the instructions in the wizard that opens, and then click Finish.

4. After the import operation completes, a summary will state whether the import succeeded. Click OK.

Using migration tables

Because some data in a GPO is domain-specific and might not be valid when copied directly to another domain, the GPMC provides migration tables. A migration table is a simple table that specifies a mapping between a source value and a destination value. Figure 7 shows a migration table in the MTE in the GPMC.

A migration table converts, during the copy or import operation, the references in a GPO to new references that will work in the target domain. You can use migration tables to update security principals and UNC paths to new values as part of the import or copy operation. Migration tables are stored with the file name extension .migtable, and are actually XML files. You do not need to know XML to create or edit migration tables; the GPMC provides the MTE for manipulating migration tables.

A 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 operation, each reference to the source entry is replaced with the destination entry when the policy settings are written into the destination GPO. Before you use a migration table, ensure that the destination references specified in the migration table already exist.

The following items can contain security principals and can be modified by using a migration table:

• Security policy settings of the following types:

  • User rights assignment

  • Restricted groups

  • System services

  • File system

  • Registry

• Advanced folder redirection policy settings

• The GPO DACL, if it is preserved during a copy operation

• The DACL on software installation objects, which is only preserved if the option to copy the GPO DACL is specified

Also, the following items can contain UNC paths, which might need to be updated to new values as part of the import or copy operation, because servers in the original domain might not be accessible from the domain to which the GPO is being migrated:

• Folder redirection Group Policy settings

• Software installation Group Policy settings

• References to scripts (such as for logon and startup scripts) that are stored outside the source GPO. The script itself is not copied as part of the GPO copy or import operation, unless the script is stored inside the source GPO.

For more information about using migration tables, see Staging Group Policy deployments in this guide.

Maintaining Group Policy

After deployment, your Group Policy implementation might need routine maintenance and modification as your organization and its needs change, and as your experience with Group Policy grows. By establishing control procedures for creating, linking, editing, importing policy settings into, backing up, and restoring GPOs, you can minimize Help desk and support calls caused by inadequately planned Group Policy deployments. You can also simplify troubleshooting GPOs and help lower the total cost of ownership for computers in your network.

By establishing GPO control mechanisms, you can create GPOs that:

• Conform to corporate standards.

• Ensure that policy settings do not conflict with those set by others.

To assist with troubleshooting GPOs, you can use the GPMC Group Policy Results Wizard to identify possible Group Policy deployment errors. For more information about this tool, see Using Group Policy Modeling and Group Policy Results to evaluate Group Policy settings in this guide. You can also use the GPMC Group Policy Modeling Wizard to evaluate the consequences of new Group Policy settings before deploying them to your production environment.

Whenever you deploy new technology solutions, such as wireless networking, you need to revisit your Group Policy configurations to ensure compatibility with the new technology. To help manage various technologies, Group Policy offers policy settings such as those for Wireless Network (IEEE 802.11) Policies (located in Computer Configuration\Policies\Windows Settings\Security Settings, Terminal Services (located in Computer Configuration\Policies\Administrative Templates\Windows Components and User Configuration\Policies\Administrative Templates\Windows Components), and policy settings for many other technologies.

Modifying Group Policy settings can have significant consequences. When performing Group Policy maintenance, you need to take reasonable precautions to test proposed changes and evaluate their effects in a staging environment before deployment.

Group Policy considerations for renaming a domain

Domain names are a critical part of the proper functioning of a Group Policy implementation. In the Windows Server 2008 family, you can rename a domain by using the Rename Domain Tools (Rendom.exe and GPfixup.exe) that are included with Windows Server 2008. The Rename Domain tools provide a secure and supported method for renaming one or more domains (and application directory partitions) in an Active Directory forest.

Important

Be sure to back up all your GPOs by using the GPMC after the domain rename is complete. After you rename a domain, you cannot restore backups made before the domain rename.

Renaming one or more domains is a complex process that requires thorough planning and understanding of domain renaming procedures. You must also modify any affected GPOs so that they work correctly. To modify the GPOs, use the Gpfixup.exe tool, which is included with Windows Server 2008. Gpfixup.exe repairs GPOs and GPO references in each renamed domain. It is necessary to repair the GPOs and the Group Policy links after a domain rename operation in order to update the old domain name embedded in these GPOs and their links.

Important

For more information about the domain renaming process, see the Windows Server 2008 TechCenter (https://go.microsoft.com/fwlink/?LinkId=100876).

Using scripts to manage Group Policy

You can download sample scripts that use the GPMC interfaces, and script many of the operations that are supported by the GPMC. The GPMC sample scripts form the basis for a scripting toolkit that you can use to solve specific administrative problems. For example, you can run queries to find all GPOs in a domain that have duplicate names, or to generate a list of all GPOs in a domain whose policy settings are disabled or partially disabled. The scripts also illustrate key scripting objects and methods to provide an overview of the many administrative tasks that you can accomplish with the GPMC. For information about these scripts, see Group Policy Console Scripting Samples (https://go.microsoft.com/fwlink/?LinkId=109520).

By default, when you download the GPMC sample scripts, they are installed in the Program Files\Microsoft Group Policy\GPMC Sample Scripts folder. The sample scripts echo output to the command window and must be run by using Cscript.exe. If Cscript.exe is not your default scripting host, you will need to explicitly specify Cscript.exe on the command line. For example, type d: \Program Files\Microsoft Group Policy\GPMC Sample Scripts>cscript ListAllGPOs.wsf. To make Cscript.exe the default scripting host, type cscript //h:cscript at the command line.

Many of the sample scripts rely on a library of common helper functions contained in the file Lib_CommonGPMCFunctions.js. If you copy these scripts to another location, you must also copy this library file to that location in order for the script samples to work.

Staging Group Policy deployments

Windows Server 2008 Group Policy provides powerful capabilities for deploying configuration changes across an organization. As with any other change within the organization, Group Policy deployments and ongoing updates require careful planning and testing to ensure a highly available and secure infrastructure. By using features included in the GPMC, you can create a test/staging/production deployment process that ensures predictability and consistency during Group Policy deployments.

Overview of Group Policy staging

Group Policy is a powerful tool for configuring Windows Server 2008, Windows Vista, Windows Server 2003, and Windows XP operating systems across an organization. This ability to affect configurations across hundreds or even thousands of computers necessitates good change management practices to ensure that changes made to a GPO produce the expected results for the intended targets—users and computers.

Most organizations have change management processes in place to ensure that new configurations or deployments to production environments undergo rigorous testing in a nonproduction environment before deployment.

In many change management processes, organizations differentiate between a test environment, which is used to test changes, and a staging environment, which is a pristine environment that resembles production and is the last stop for a change before it is deployed to production. In this section, the terms test and staging are used interchangeably, without differentiating between them as physical environments. You can, however, use the techniques described in this section to create separate test and staging environments if your change management processes require them.

Effective change management processes are equally important for ensuring that you successfully deploy Group Policy changes because Group Policy is capable of affecting everything from registry settings to security settings to deployed software on a computer. In addition to the many configuration settings that Group Policy accommodates, GPOs can be linked to a number of different scopes, and their effect can be filtered by users, computers, or security groups. The ability to stage GPOs in a test environment and then test the various effects before deploying them in a production environment is critical to ensure the reliable, robust operation of your Windows-based infrastructure. Creating a staging environment is critical to any successful deployment of Group Policy within your Active Directory–based infrastructure. There are several options that you can choose from to create such an environment. These options are enabled by using features within the GPMC.

You can combine GPMC console-based features with scripts to create a staging environment that mimics your production environment. You can then use the staging environment to test new or changed GPOs. After those GPOs are validated, you can use the GPMC to migrate them to your production domains.

Group Policy staging process

The process for staging Group Policy involves creating a staging environment that mimics the production environment, testing new Group Policy settings in the staging environment, and then deploying those policy settings in the production environment. The specific deployment approach you use depends on the configuration of your staging environment.

Initially, assembling a staging environment for Group Policy is simply a matter of identifying available hardware that can be used in creating an infrastructure that is similar to your production environment, and then setting up the appropriate logical structure. You can then use tools in the GPMC to import production Group Policy settings into the staging environment. After you have created the environment, testing Group Policy involves implementing changes and measuring their effect on test users and computers that mimic production users and computers. After you have validated your changes, you can again use tools in the GPMC to migrate changed or new Group Policy settings to your production environment.

On an ongoing basis you need to maintain Group Policy and continue to evaluate changes. Consequently, you need to keep the staging environment synchronized with the production environment over time. You can use the GPMC tools such as the sample scripts and the backup, copy, and import features to maintain the staging environment over time.

Note

You can use Windows Server 2008 hypervisor-based virtualization to help create and test a wide variety of Group Policy scenarios. Using virtual machines, you can create a safe, self-contained environment that accurately approximates the operation of physical servers and clients. For information about Windows Server 2008 virtualization, see Virtualization and Consolidation (https://go.microsoft.com/fwlink/?LinkId=109521).

GPMC deployment staging and maintenance capabilities

The GPMC includes several features for staging and maintaining Group Policy:

• The Group Policy Modeling Wizard for planning Group Policy deployments.

• The Group Policy Results Wizard for viewing GPO interaction and for troubleshooting.

• The ability to use a single Microsoft Management Console (MMC) interface (the GPMC) to manage Group Policy across your organization. Management operations include importing and exporting, copying and backing up, and restoring GPOs.

For staging Group Policy, the most important features of the GPMC are backup, import, copy, and migration tables. These features allow you to stage and migrate GPOs between forests and domains.

Backup and import

The GPMC provides the ability to back up one or more GPOs. You can then use these backups to restore individual GPOs to their previous state (by using the restore operation), or you can import policy settings into an existing GPO, overwriting any previous policy settings. The restore operation is used only to restore a GPO into the same domain from which it was backed up.

By contrast, the import operation is used in cases in which the backup was made from any GPO in the same domain, a different domain, or even in a different untrusted forest, such as a test forest isolated from the production forest. Note that although both the restore and import capabilities apply to previously backed-up GPOs, restore provides additional capabilities. You will use the backup, import, and copy operations to stage and migrate GPOs into your production environment.

Figure 8 illustrates the import operation. In this case, GPO X in a test forest contains a number of security principals who are assigned the Log on Locally user right. This GPO is backed up and then imported into the production forest. During the import operation, the original security principals are mapped to new ones that exist in the production domain.

Copy

By using the copy capability in the GPMC, you can right-click a GPO, copy it from one domain, and paste it into a new domain. In a copy operation, when you copy a GPO into a new domain, a new GPO is created. This differs from the import operation, which erases and then overwrites an existing GPO. However, only the policy settings from the source GPO are copied to the new GPO. Scope of Management (SOM) links, ACLs, and WMI filter links for the source GPO are not copied to the new GPO. Copy operations require that the destination domain is trusted by the source domain. To perform copy operations, you must be a member of the local Administrators group or a delegated user with the following rights:

• Read rights on the source GPO and in the source domain.

• The right to create GPOs in the destination domain (the domain to which the new GPO is being copied).

With both the import and copy operations, the GPMC supports the ability to perform security principal and UNC mapping between references to those objects in the source and destination GPOs.

Figure 9 illustrates a copy operation. In this case a GPO is migrated from Domain B to Domain C, and several of its associated security principals are mapped to new principals on Domain C.

Migration tables

GPOs can contain references to security principals and UNC paths as part of a policy setting. For example, within security policy settings, you can control which users or groups can start and stop a particular Windows service. Figure 10 illustrates the security settings that can be applied to the Messenger service. In this case, these security settings can be mapped from security principals in the staging environment to security principals in a production environment by using migration tables.

In addition, a GPO has a security descriptor that contains a DACL that is used to control which computers, users, or groups process a GPO and which users can create, modify, and edit the GPO. The security principals included in the DACL on a GPO can also be taken into consideration when the GPO is deployed from one domain to another.

Migration tables also support mapping of UNC paths, which might exist in Software Installation, Folder Redirection, or Scripts policy. To address any differences in these paths between the test and production environments, you can use migration tables to replace server and share names when you migrate Group Policy settings.

If a GPO created in another domain or forest is migrated to your production environment, you need to modify the associated security principal references to reflect the references found in the production domain. The GPMC provides an MTE that you can use to create a mapping file for security principals and UNC paths. The MTE creates an XML format file with a .migtable extension; this file specifies the source and destination security principals or UNC paths for a GPO migration. For more information about the MTE, see Creating migration tables later in this guide.

Creating the staging environment

The first step in staging and deploying Group Policy is the creation of the staging environment. This step involves building a test infrastructure that mirrors that of the production environment and allows you to test new or changed Group Policy settings without affecting production users and computers.

At this point, you need to make decisions about the placement of your staging environment and its trust relationships to your production environment. You can choose to create:

• A staging domain within the production forest.

• A staging forest with no trusts to the production forest.

• A staging forest with trusts to the production forest.

Each option has its benefits and drawbacks, as described in Table 8.

Table 8 Choosing a Staging Approach

Approach	Advantages	Disadvantages
Staging domain within production forest	Can use the GPMC copy operation to move GPOs between staging and production environments. Can leverage existing production infrastructure services (for example, DNS, DHCP). Might require less hardware to implement than a completely isolated environment that requires a supporting infrastructure. Easier to keep synchronized with production environment because all policy settings and services are in the same forest. Might require less use of migration tables if migrating from domain to domain in the production forest (for example, some security principals can be reused regardless of domain).	Might not be sufficiently isolated from production environment to ensure testing does not affect it (for example, site-linked GPOs cannot easily be tested because sites span domains within a forest. Security principals can be reused regardless of domain). Might prove restrictive if changes to the environment are required for testing.
Staging forest with no trusts to production forest	Completely isolated from production environment; provides maximum protection from test GPOs affecting production computers and users. No security overlap between staging and production; administrators in staging and production forests need not have access to both forests. Provides flexibility; administrators can experiment freely with policy settings and configurations without affecting the production environment.	Difficult to keep synchronized with production forest. Without trusts, movement of data and policy settings between forests is more cumbersome. Migration tables are required to move GPOs that contain security principals or UNC paths from staging to production. Cannot use the GPMC copy operation to migrate GPOs; must use the GPMC import operation.
Staging forest with trusts to production forest	Can use the GPMC copy operation to move GPOs between staging and production environments. Somewhat isolated from production environment. Provides flexibility; administrators can experiment freely with policy settings and configurations without affecting the production environment. Might not need migration tables to map UNC paths, because all paths could be available through current trust relationships.	Difficult to keep synchronized with production forest. Trusts between staging and production environments allow users in one environment to access resources in the other. Migration tables required to move GPOs that contain security principals from the staging environment to the production environment.

Consider the advantages and disadvantages described in Table 8 when choosing a staging approach. After you have made your choice, you are ready to determine the hardware requirements for the staging environment.

Hardware requirements

Regardless of the staging approach that you select, it will be necessary to dedicate some additional hardware to the construction of your staging environment. The amount of hardware that you need depends upon the kinds of testing you need to do and how specific your Group Policy testing requirements are. For example, production environments that include computers across slow network links can affect how Windows applies Group Policy, because some Group Policy settings are not applied across slow links. It is important that your test environment reflect this situation for you to obtain an accurate picture of how changes in Group Policy affect your production environment. The GPMC can help in such a situation by providing the capability to model the impact of Group Policy processing across slow links. However, you might not be able to fully mirror your production environment unless you dedicate sufficient systems and network hardware to the staging environment. Your goal is to produce a testing and staging environment that reflects the performance and behaviors that computers and users in your production environment will encounter when Group Policy applies new or changed GPOs.

Preparing the staging environment

After you have chosen a staging approach and set up your hardware, install Windows Server 2008 and Active Directory on your staging servers in preparation for synchronizing the configuration of production and staging environments. In most cases, you should ensure that computers in the staging environment are running the same operating system, service packs, and hot fixes as in your production environment. This is important to ensure consistent test results. In addition, ensure that the supporting infrastructure, such as DNS, Distributed File System (DFS), and related services are also configured as in the production environment. DNS especially is critical to proper processing of GPOs. If you decide to use a staging approach that places a staging domain or OU structure in your production forest, then you can use your existing production DNS infrastructure for name services.

Important

You can use the Windows Server 2008 GPMC to manage GPOs in Windows Server 2008, Windows Server 2003, and Windows 2000 domains.

If you build a separate forest for staging, you need to address the issue of name services integration. Name services might include either DNS or Windows Internet Name Service (WINS), depending on the types of trusts you created. You might need to create a separate DNS infrastructure for your staging environment. This is particularly true if you are using secure Active Directory–integrated DNS in your production forest, because secure Active Directory–integrated zones cannot support dynamic registration of clients from foreign forests. If you plan to create trusts between your staging and production forests, the name services infrastructure in each forest must be aware of the other. After your staging environment is fully configured with the base elements required to deploy Group Policy, the next step is to synchronize the staging and production environments.

Synchronizing the staging and production environments

After you have created a basic staging infrastructure that reflects your production environment, you need to ensure that all security and GPO settings are identical between the two environments. Synchronization also requires ensuring that a sufficient representation of OUs, users, computers, and groups exists in both environments, because you need to be able to test GPO links and the effects of security group filtering as they would exist in the production environment.

The goal of any test environment is to ensure that it mirrors the production environment as closely as possible. You can download and run two GPMC sample scripts, CreateXMLFromEnvironment.wsf and CreateEnvironmentFromXML.wsf, to help both with the initial synchronization and to keep the test environment synchronized with the production environment over time. As mentioned earlier, by default the GPMC sample scripts are installed in the Program Files\Microsoft Group Policy\GPMC Sample Scripts folder.

The script CreateXMLFromEnvironment.wsf runs against a production domain, stores all policy-related information in an XML format file, and creates backups of the GPOs it finds in the production domain. Note that this script works only against a single domain at a time, not against an entire forest. The script CreateEnvironmentFromXML.wsf uses the XML format file and any backup GPOs created by CreateXMLFromEnvironment.wsf to recreate GPOs and other objects from the production domain in a staging domain. Table 9 describes the objects and policy settings that CreateXMLFromEnvironment.wsf captures, and shows additional objects you can capture by using command-line options when running the script.

Table 9 Objects Captured by CreateXMLFromEnvironment.wsf

Object type	Captured by script	Additional command-line options
All GPOs and GPO settings for the domain or OU	Yes	To capture GPO settings, you must provide a template path by using the /TemplatePath option to specify a file system location to store backed-up GPOs. If no template path is specified, GPOs are not backed up. You can exclude permissions on GPOs by using the /ExcludePermissions option.
Organizational units	Yes	You can capture only a portion of the OU tree by using the /StartingOU option, with the DN-style path to an OU.
GPO links and link attributes (for example, disabled, block inheritance)	Yes, except that links on site objects are not captured	None
Policy-related permissions	Yes	You can exclude permissions by using the /ExcludePermissions option.
WMI filters	Yes	None
Users	Optional	User accounts are not captured unless you use the /IncludeUsers option.
Security groups	Yes	By default, only security groups defined in OUs are captured by the script. You can extend this to include all groups in the Users container and in the domain root by using the /IncludeAllGroups option.
Computers	No	None
Sites	No	None

There are a few things to keep in mind when using the script CreateXMLFromEnvironment.wsf. First, if you use the /IncludeUsers option to capture user objects, when those objects are re-created in the staging domain, you will need to supply a password for each user captured. You can do this by manually editing the resulting XML file and adding a password for each user.

Alternatively, if you have any users that do not have passwords specified in the XML file, the CreateEnvironmentfromXML.wsf script will prompt you to supply a password. All users that do not have passwords specified in the XML file will be created with this password. Also note that the script does not capture computers. This is because computer objects in Active Directory correspond to physical hardware resources, and those might differ between the production and staging environments. Finally, the script captures neither sites nor GPO links on sites. Because sites can span multiple domains and can impact Active Directory replication, it is best to re-create these objects—and GPO links on them—manually in your staging environment.

Example: Creating an XML format file from a production environment

Assume that your production domain is called Contoso.com. You want to export Group Policy settings and related information to create a new staging domain for GPO testing. In this example, assume that you want to capture GPOs from the entire domain and include user accounts and groups. To export the information that you need, complete the following tasks:

To create an XML file from a production environment

1. Ensure that you have sufficient permissions on the production domain to extract the necessary data. You must have the rights to read all objects that you are capturing, including GPOs, OUs, users, and groups (and their memberships).

2. Create a folder to store the XML format file that describes the information collected by the script.

3. Create a folder to store backups of the GPOs that are extracted by the script.

4. Run the script CreateXMLFromEnvironment.wsf from the installation folder. You must precede the script name with the command cscript if cscript.exe is not your default Windows Script Host (WSH) engine. For this example, type the following from the command line:

   Cscript "%programfiles%\Microsoft Group Policy\GPMC Sample Scripts\CreateXmlFromEnvironment.wsf".\production.xml /Domain:contoso.com /DC:contoso-dc1 /TemplatePath:.\GPObackups /IncludeUsers
   

This command creates the XML format file Production.xml in the folder where the script is run. The backed-up GPOs are created in a subfolder of the current folder called GPObackups. Placing a backslash (\) in front of the production.xml and GPObackups paths causes the script to use a relative path, and create the XML file and backup GPO folders in the current directory from which the script is run. Using a relative path makes it easier to copy the XML and backups to different locations from which they can be restored.

The script starts its capture at the domain level, Contoso.com. You can also run the script at an OU level, in which case you would use the /StartingOU option in addition to the /Domain option. If you exclude the /Domain option, the current domain is assumed. The /DC option instructs the script to use the domain controller contoso-dc1, and the /TemplatePath option specifies that the backups of all of the GPOs that are captured are stored in the folder GPOBackups. Finally, the /IncludeUsers option ensures that user accounts are captured by the script as well.

Warning

You can open and edit the XML format files produced by the script CreateXMLFromEnvironment.wsf in a text editor or any XML editor. Be aware, however, that XML-formatted files must adhere to a specific syntax. If you change that syntax, you might affect the ability of the script CreateEnvironmentFromXML.wsf to read the input file.

After you have captured the production environment by running the script CreateXMLFromEnvironment.wsf, you need to run the script CreateEnvironmentFromXML.wsf, using the .XML format file output by CreateXMLFromEnvironment.wsf as input. You must run the script CreateEnvironmentFromXML.wsf from within the staging domain, or you can run this script from a computer that is not in the staging domain if you already have configured trust relationships with the staging domain.

Importing production GPOs into the staging domain

The script CreateEnvironmentFromXML.wsf provides several different options that you can use to qualify the creation of GPOs in your staging environment. The simplest option involves supplying an XML format file created from the production domain to the script and optionally directing the operation of the script to a domain controller in your staging domain. The script creates GPOs and related objects in the staging domain that correspond to the data that was captured from the production domain. If you need to modify this process, the script provides a number of command-line options:

• Undo. This option removes all objects (GPOs, GPO permissions, OUs, WMI filters, users and groups) specified by the XML format file from the staging environment. This option is useful if you need to reverse changes that you made to your staging domain.

• ExcludePolicy Settings. This option creates GPOs in the destination domain, but with no policy settings. Use it when you do not want to import the policy settings in any GPOs, but rather just want to create any OUs, users, and user groups that might have been captured.

• ExcludePermissions. This option causes the script to ignore any Group Policy-related permissions contained in the XML format file. Instead, when the new GPOs and other objects are created in the staging environment, they are created with default permissions.

• MigrationTable. This option enables you to specify a .migtable file that you create by using the MTE to specify mapping of security principals and UNC paths in your production environment GPO settings to the appropriate security principals and UNC paths in the staging environment.

• ImportDefaultGPOs. This option imports policy settings into the Default Domain Policy and the Default Domain Controllers Policy, if policy settings for these GPOs are specified in the XML file. If this option is not specified, these GPOs will not be modified.

• CreateUsersEnabled. This option creates user accounts as enabled instead of disabled.

• PasswordForUsers. This option allows you to specify the password to use for any users that do not have passwords specified in the XML file. The same password will be used for all users that do not already have passwords specified in the XML file.

• Q. This option runs the script in quiet mode, if all necessary parameters have been supplied on the command line. Without this option, you are warned that this script should only be used for creating staging environments, and if necessary, you will be prompted to supply a password for any users that do not have passwords defined in the XML file.

Example: Populating the staging domain from the XML format file

Assume that your staging environment is the domain test.contoso.com, and that this domain is in the same forest as the production domain captured earlier in this chapter. Even if the staging domain is not in the same forest as the production domain, the steps for populating the staging domain are the same, but different mapping of security principals using migration tables might be required.

To populate a staging environment from an XML file

1. Ensure that you are running the script CreateEnvironmentFromXML.wsf with sufficient permissions in the staging domain. You should run the script as a user as a member of Domain Admins or have equivalent access in the domain.

2. Ensure that you have access to the XML format file and backup GPOs that were created in the production domain by running CreateXMLFromEnvironment.wsf.

   When you run CreateEnvironmentFromXML.wsf, you are only referencing the XML format file (not the location of the backup GPOs) in the command-line options. That file includes the paths to the backup GPO files. Consequently, when you specify the XML file to CreateEnvironmentFromXML.wsf, the script uses any backup GPO files in the folder that was specified when the script CreateXMLFromEnvironment.wsf was run. If you ran CreateXMLFromEnvironment.wsf using the command as shown in Example: Creating an XML format file from a production environment, then the XML file will indicate that the backups are in a subfolder of the current folder. If you did not use a relative path when running CreateXMLFromEnvironment.wsf, there are three ways to ensure that CreateEnvironmentFromXML.wsf, can find the required files:

   • Copy the specified folder structure from the location where it was created to an identical path on the local computer from which you run CreateEnvironmentFromXML.wsf.

   • Specify a network share rather than a local drive when you first create the XML format file (the share must be also accessible from the location where you run CreateEnvironmentFromXML.wsf).

   • Edit the XML format file to change the path entries to point to a different location for the backup GPO files.

3. Run CreateEnvironmentFromXML.wsf from the Scripts folder in the GPMC installation folder. You must precede the script name with the command cscript if cscript.exe is not your default WSH engine. For this example, type the following from the command line:

   Cscript CreateEnvironmentFromXml.wsf /xml:c:\staging\production.xml /Domain:test.contoso.com /DC:test-dc1
   

The script generates a warning that it is intended for creating staging environments only, and then prompts you to enter a password for user objects. If you use the /Q option and supply the password using the PasswordForUsers option when you run this script, these messages are not presented. If you confirm that you want to proceed, the script provides status as it processes the XML file and GPOs. You can then confirm that all steps completed correctly by using Active Directory Users and Computers and the GPMC to verify that users, groups, and GPOs were successfully created.

Maintaining synchronization of the staging and production environments

You use the CreateXMLFromEnvironment.wsf and CreateEnvironmentFromXML.wsf scripts to create an initial staging environment from your production environment. But maintaining Group Policy, including testing new and changed GPOs, requires an ongoing effort. How do you keep your staging environment synchronized with the production environment on a continuing basis? These two scripts provide an all-or-nothing method for populating GPOs — they are not specific enough to capture and import only specific GPOs.

The backup and import functions in the GPMC give you the ability to selectively synchronize specific GPOs between your production and staging environments. You use the backup capability to create a backup of the policy settings and security of a production GPO. You can then import the backup over an existing GPO in your staging domain, thereby synchronizing it with the production GPO. For more information about backing up and importing GPOs, see Deployment examples.

Testing Group Policy in the staging environment

After you have created your staging environment and synchronized Group Policy with your production environment, you can begin to test planned Group Policy changes. The best mechanism for testing Group Policy is by using a combination of the Group Policy Results and Group Policy Modeling tools provided with the GPMC, and exercising real user accounts and computers in the test environment to process actual GPOs.

The Group Policy Results feature is useful when you have applied new GPO settings to a computer and user, and need to verify that all of the expected policy settings were actually applied. Group Policy Modeling can be used to determine the effects of changing the location of a user or computer within the Active Directory namespace, changing the group membership of a user or computer, or to observe the effects of a slow link or loopback policy. The Group Policy Modeling feature enables you to test the effects of a change without actually making the change, while the Group Policy Results feature shows you what actually happened. Group Policy Results runs on the destination computer, so you must have access to that computer. Group Policy Modeling runs on a domain controller, so there must be one available to run the modeling process. Note that with Group Policy Modeling, you can model policy settings on computers running Windows Server 2008, Windows Vista, Windows Server 2003 and Windows XP Professional. Keep in mind that Group Policy Modeling simulates the processing of policy, while Group Policy Results shows the effects of policies actually processed.

Testing by logging on as a test user

The first and best method for testing Group Policy is to make the actual changes to your staging domain GPOs and then test the results by logging on to workstations with test user accounts to observe the effect of the changes. In this way you can observe how users are affected by the changes.

Testing by using Group Policy Results

You can use the Group Policy Results Wizard in the GPMC to obtain detailed reports of the GPOs that are applied to users and computers, if the GPMC is installed on the test computer. Otherwise, you can use the command-line version of Group Policy Results to create reports of which GPOs have been applied to the user or computer. You can then make any needed changes in your test GPOs accordingly. You use Group Policy Results after all Group Policy is processed for a given user and computer to inform you about which policy settings were applied. The results are gathered by querying RSoP on the Windows Server 2008, Windows Vista, Windows Server 2003, or Windows XP computer that processed Group Policy. The wizard thus returns the policy settings that were actually applied rather than expected policy settings. This is the same output that is produced when you use Gpresult.exe with the /h parameter.

For more information about the Group Policy Results Wizard, see Using Group Policy Modeling and Group Policy Results to evaluate Group Policy settings in this guide.

Testing by using Group Policy Modeling

The second method for testing Group Policy is to use the Group Policy Modeling Wizard in the GPMC to model changes to your environment before you actually make them. Group Policy Modeling enables you to perform hypothetical tests on user and computer objects prior to a production rollout to observe how Group Policy settings would be applied if you made changes such as moving the user or computer objects to a different OU, changing their security group membership, or changing the effective WMI filters. Be aware, however, that results obtained by using Group Policy Modeling are simulated, rather than actual, policy settings. Therefore, after you have modeled the scenario that meets your needs, it is always best to use the Group Policy Results Wizard to verify the expected policy settings.

Because Group Policy Modeling does not enable you to specify proposed changes to policy settings in a GPO, you need to make the proposed changes to your staging GPOs and then run the Group Policy Modeling Wizard for a given OU, user, or computer to determine the resultant set of policy.

Group Policy Modeling also enables you to model Group Policy behavior when your computers are processing policy across a slow network link, which can determine which Group Policy extensions are processed. If a computer connects to a domain controller over a slow network link, then Group Policy extensions such as Software Installation and Folder Redirection are not processed.

Group Policy Modeling can simulate a slow link speed and use it to determine what the effective policy settings will be for the user and computer being modeled. In addition, Group Policy Modeling supports testing the effects of Group Policy loopback processing. With loopback processing enabled, the same policy settings are applied to a computer regardless of the user who logs on to it. Note that you must specify that you want to model loopback processing within the Group Policy Modeling Wizard; loopback processing is not modeled by default.

You can specify slow-link detection, loopback processing, or both when using the Group Policy Modeling Wizard. For loopback processing, you can choose whether to replace or merge user-specific policy. The replace mode replaces all of a user’s normal policy settings with those defined in the user configuration of the GPOs that apply to the computer object (the loopback policy settings). Merge mode merges the user’s normal policy settings and the loopback policy settings. When a policy item in the user’s normal policy settings conflicts with the loopback policy settings, the loopback settings are applied.

Note

The Group Policy Modeling process runs on a domain controller. By contrast, Gpresults or the Group Policy Results Wizard runs on the Windows Server 2008, Windows Vista, Windows Server 2003, or Windows XP computer that is processing Group Policy. Group Policy Results uses the RSoP WMI provider to generate information about Group Policy processing. Group Policy Modeling relies on the Resultant Set of Policy Provider service on the Windows Server 2008 or Windows Server 2003 domain controller to perform its analysis.

For more information about the Group Policy Modeling Wizard, see Using Group Policy Modeling and Group Policy Results to evaluate Group Policy settings in this guide.

Preparing for deployment to production

After your changes to Group Policy have been thoroughly tested in the staging environment, you are almost ready to deploy the new or changed GPOs in your production environment. Before you can do that, however, you need to assess whether you will need to map security principals or UNC paths contained in your GPOs to different values as part of the migration.

Determining your migration mapping requirements

Your staging environment might be a test domain in production, a separate but trusted test forest, or a separate test forest that is not trusted. In each case, you will probably have to create and use a migration table as you deploy new or changed GPOs in your production environment. Migration tables satisfy three different types of mapping requirements:

• You need to map each Access Control Entry (ACE) on one or more GPOs to different security principals as you migrate the GPOs to the production environment. The ACEs on a GPO describe which users, computers, and computer groups will process that GPO, and which users or user groups can view and edit policy settings in or delete the GPO.

• You need to map security principals within security or folder redirection policy settings defined in one or more GPOs. Specifically, policies such as User Rights Assignment, Restricted Groups, File System, Registry, or System Services allow you to specify particular users or groups who can access or configure those resources. The Security Identifier (SID) for that user or group is stored in the GPO and must be modified to reflect production domain users or groups when the GPO is migrated.

• You need to map UNC paths when you have defined software installation, folder redirection or scripts policy settings that reference UNC paths. For example, you might have a GPO that references a script stored in an external path, such as the Netlogon share, on a remote server. This path might need to be mapped to a different path when the GPO is migrated. UNC paths are usually specific to a given environment, and might need to be changed when you migrate the GPO to your production environment.

If any of these three conditions above is true, you will need to create a migration table that can be used to map the values in your test GPOs to the correct values in the production domain when they are migrated

Creating migration tables

Use the MTE, included with the GPMC, to create and edit migration tables. This table can be accessed in either of two ways:

• You can start the MTE and create or edit a migration table during a GPMC copy or import operation. In this case, the MTE starts in a separate window that allows you to create a new migration table or edit an existing one.

• You can start the MTE in stand-alone mode (independently of an import or copy operation), and create or edit the migration table in advance of migrating GPOs to your production environment.

You can also create migration tables by using sample scripts, as described later in this section.

One advantage of creating the migration table in advance is that you can be sure the migration settings you define are exactly what you want before beginning the deployment. Therefore, when you are ready to move your test GPOs into production, you should first create one or more migration tables for the GPOs that you need to migrate. Note that a single migration table can be used for more than one GPO. You might use a single migration table that covers every possible security principal and UNC path combination for a given migration from a staging to a production domain. In that case you can simply apply the same migration table to every GPO that is deployed from the staging domain to the production domain, and those principals and paths that match will be correctly mapped.

Using the stand-alone MTE

To start the MTE in stand-alone mode, run Mtedit.exe from the GPMC installation folder. The MTE starts with a blank migration table that you can populate manually by typing entries into the grid, or you can auto-populate the table by using one of the auto-populate methods.

Auto-populating the migration table

The easiest way to start creating a migration table is to use one of the auto-populate features, accessed from the Tools menu in the MTE. You can auto-populate from both backup GPOs and from live GPOs. To auto-populate a migration table, use the following procedure.

To auto-populate a migration table

1. Choose to auto-populate the table from live GPOs or from backup GPOs. When you are ready to migrate a GPO in your staging environment into your production environment, you can use Populate From GPO against the live GPO in the staging environment to start the migration table. The process for auto-populating the table from a backup GPO is the same, except that you must provide a path to the backup GPO. In that case, if you have more than one backed-up GPO, a list is displayed from which you can choose. Note that you can select multiple GPOs or backup GPOs when auto-populating a single migration table. This allows you to use a single migration table for all GPOs in a domain.

2. Choose whether to include security principals from the DACL on the GPO. When you auto-populate a migration table, you can select the option to include security principals from the DACL on the GPO. If you select this option, security principals on the GPO’s DACL are included in the table with security principals referenced in the GPO settings. Duplicate source security principals are not repeated in the migration table. The MTE supports a number of different object types that can be mapped, as described in Table 10.

   Table 10 Object Types Supported in the Migration Table

   Object type	Used to map
   User	Individual user accounts.
   Domain global group	Domain global groups.
   Domain local group	Domain local groups.
   Universal group	Universal groups.
   Computer	Computer names. For example, an individual computer can be given Read and Apply Group Policy permissions on a GPO.
   UNC path	UNC paths used in software installation policy.
   Free Text or SID	Undetermined security principals. For example, you might reference security principals in a GPO by name rather than by SID (typed as "administrators" instead of "DomainX\Administrators"); or it might not be possible to resolve security principals to determine the type. This type of mapping might occur if you set restricted group security policy and enter the name of the group rather than resolve the name against a live domain. In this case, the group name is stored in the GPO as the name that you specified, rather than its corresponding SID. The MTE considers such a security principal as Free Text or SID. In addition, you can enter raw SIDs in the MTE. In this case, because the object type is not known by the MTE, it must be specified as Free Text or SID.

3. Modify the Destination Name for each security principal and UNC path. After you have populated the migration table, you can choose to modify the Destination Name field for each record. The default Destination Name value is Same As Source, which means that the same security principal or UNC path will be used in the destination GPO as the source. In this case, the value is copied without modification and the mapping accomplishes no changes. Typically you will need to change this field for one or more source entries when migrating a GPO from a test environment to a production environment. To change the destination field, you can either type an entry or right-click the field and click the appropriate menu item.

4. The two menu items available are Browse and Set Destination. Choosing Browse allows you to select a security principal in any trusted domain. If you choose Set Destination, you can choose one of three options:

   • No Destination. If you specify No Destination, the security principal is not included in the destination GPO when migrated. This option is not available for UNC path entries.

   • Map by Relative Name. If you specify Map by Relative Name, the security principal name is assumed to already exist in the destination domain, and that destination name will be used for the mapping. For example, if the source name is Domain Admins for the test.contoso.com domain and you are migrating the GPO into the contoso.com domain, then the name Domain Admins@test.contoso.com will be mapped to Domain Admins@contoso.com. The group must already exist in the destination domain for the import or copy operation to succeed. This option is not available for UNC path entries.

   • Same As Source. If you specify Same As Source, the same security principal is used in both the source and destination GPOs. Essentially, the security entry is left as-is. Note that this option is only practical if you are migrating from a test domain in the same forest as the production domain, or if you are migrating from a test domain in a different forest that trusts the production forest. The requirement for a source name to map successfully is that it can be resolved by users and computers in the production forest.

   There are several restrictions on the options available for the destination name. UNC paths support only the Same As Source option, or you can manually enter a different UNC path. Security principals that are designated as Free Text or SID do not support Map by Relative Name.

   It is also important to note that you will receive a warning if you map from one group type to another. For example, if you have a source principal that is a Domain Global Group and you select a Domain Local Group as the destination, you will be warned that the destination name is of a different type from the source. If you then try to validate the file, the validation process fails, but you can still use the migration table to perform a migration. Note that the migration table does not support mapping to a built-in security group such as the Administrators group.

   If you need to delete a row from the MTE, select the desired row, right-click it, and then click Delete.

5. Validate the migration table. Before saving the migration table, it is best to validate the file. To do this, on the Tools menu, click Validate. The validation process determines if the XML format of the resulting file is valid and verifies that the destination names are valid from a migration perspective. For example, if you enter a UNC path for the destination, and the path does not exist, the validation process will return a warning. Specifically, the validation process:

   • Validates the existence of destination security principals and UNC paths.

   • Checks that source entries with UNC paths do not have destinations of Map By Relative Name or No Destination, which are not supported.

   • Checks that the type of each destination entry in the table matches the type in Active Directory.

   If you are entering data manually, the validation process is especially important to ensure that an entry error does not prevent a successful migration. Note that a validation of the mapping file might fail because the user editing the file does not have the ability to resolve the security principals or UNC paths specified in the file. However, that does not mean that the file will not work as expected during a migration, provided that the user who performs the migration can resolve the security principal and UNC names. Validation messages will indicate whether there is a syntax error in the table or whether the validator simply cannot resolve a security principal name or UNC path. In the case of a name resolution failure, ensure that you will have sufficient access to both source and destination resources during the actual migration.

6. When you are finished editing the table, save the resulting .migtable file by clicking File and then Save.

Entering migration table entries manually

If you choose not to use the Auto-Populate feature, or if you need to enter data manually, take care to adhere to the proper formats in order for the migration table to be valid. Table 11 shows the proper form for each object type supported in the migration table. Note that these formats are required in both the source and destination fields.

Table 11 Required Formats for Migration Objects

Object type	Required format
User	a. UPN—User@UPN suffix b. SAM—NetBIOS domain name\user c. DNS—DNS domain name\user For example, MonicaB@contoso.com, contoso\MonicaB, or contoso.com\MonicaB.
Domain global group	a. UPN—Group@UPN suffix b. SAM—NetBIOS domain name\group c. DNS—DNS domain name\group For example, DomainAdmins@contoso.com, contoso\DomainAdmins or Contoso.com\DomainAdmins.
Domain local group	a. UPN—Group@UPN suffix b. SAM—NetBIOS domain name\group c. DNS—DNS domain name\group For example, Administrators@contoso.com, contoso\Administrators, or Contoso.com\Administrators.
Universal group	a. UPN—Group@UPN suffix b. SAM—NetBIOS domain name\group c. DNS—DNS domain name\group For example, EnterpriseAdmins@contoso.com, contoso\EnterpriseAdmins, or contoso.com\EnterpriseAdmins.
Computer	a. UPN—Computer Name$@UPN suffix b. SAM—NetBIOS domain name\computer name$ c. DNS—DNS domain name\Computer name$ For example, server1$@contoso.com, contoso\server1$, or contoso.com\server1$. The $ indicates the computer’s hidden computer account.
UNC Path	\\servername\sharename\. For example, \\server1\packages.
Free Text or SID	Either a string or the string representation of a SID. For example, "MonicaB" or "S-1-5-21-1473733259-1489586486-3363071491-1005". SIDs cannot be specified in the destination field.

Creating a migration table by using a script

If you need to automate the process of creating migration tables, you can use the GPMC sample script CreateMigrationTable.wsf. You can also use this script rather than the MTE to generate the initial migration table, and then use the MTE to modify the table.

The CreateMigrationTable.wsf script supports auto-populating a migration table by using either a current GPO or a backup GPO location. You can also have the script read from all GPOs within a domain. In that case, all possible security principals found in GPOs in the staging domain are inserted into the migration table, and that single migration table can be used for any GPO migration from that staging domain to a production domain.

Note that the script always includes the security principals that are part of the DACL on the GPO, unlike the MTE, which gives you the option to exclude them. The script also has an option to set the destination name to Map by Relative Name rather than the default Same As Source. You use the /MapByName option to implement relative naming.

The following command illustrates how the script can be used. In this command, a GPO named Finance OU Desktop Policy is located in a staging domain named staging.contoso.com. This command auto-populates the migration table called FinanceStaging.migtable from the current GPO:

Cscript.exe CreateMigrationTable.wsf c:\migtables\FinanceStaging.migtable /GPO: "Finance OU Desktop Policy" /domain:staging.contoso.com

To create a migration table from the backup of this GPO instead of from the live copy, simply add the /BackupLocation option to the command syntax, and provide a folder path that contains the backup copy of the GPO. Note that if you use the /BackupLocation option and there is more than one backup GPO located in that folder path, all available backed-up GPOs will be used to populate the migration table.

Final preparations for deployment

As a final step before your production deployment, you should back up your staging GPOs. A backup is required if you are using a GPO import to perform your migration from staging to production. This method is required when your staging environment is in a forest that is separate from and not trusted by your production domain, or when you need to update an existing GPO that already exists in your production environment. You can use the GPMC to back up one or more GPOs, or you can use the sample script BackupGPO.wsf to back up a single GPO or all GPOs in the staging domain. To back up a GPO by using the GPMC, in the GPMC console tree, right-click the GPO that you want to back up, and then click Backup.

To back up a GPO by using BackupGPO.wsf, run the script from the Program Files\Microsoft Group Policy\GPMC Sample Scripts folder. The following command-line syntax backs up the GPO Finance OU Workstation Security Policy in the domain staging.contoso.com to the folder c:\gpobacks:

Cscript.exe backupgpo.wsf "Finance OU Workstation Security Policy" c:\gpobacks /comment:"Backup prior to prod" /domain:staging.contoso.com

The preceding syntax includes a comment that indicates the purpose of the backup.

Deploying staged GPOs to the production environment

After you have built your staging environment, synchronized it to your production environment, tested new and changed GPOs, and created migration tables, you are ready to perform the actual production deployment.

Deployment precautions

To ensure uninterrupted service to your users, it is a good idea to observe several precautions when migrating staged GPOs to your production environment. Although migrating new GPOs is typically a quick process that does not adversely impact production users or computers, it is prudent to avoid making such a change until the least possible number of users will be affected. Typically this might be during off hours, when users are not active on the network.

Remember that when a GPO is updated, the update is performed first against the domain controller that is currently targeted by the GPMC for a particular domain. If you are using the GPMC to perform the migration, you can click the Domains item in the console tree to check which domain controller is currently being used for each domain under management. To change the domain controller, in the GPMC console tree, right-click the domain name, click Change Domain Controller, and then specify the new domain controller before migrating your changes.

GPO replication

Keep in mind that GPO changes propagate according to your Active Directory and Sysvol replication topologies, and therefore might take an extended period of time to replicate to all locations in a worldwide Active Directory deployment. Also keep in mind that a GPO comprises two parts—the portion that is stored and replicates as part of Active Directory, and the portion that is stored and replicates as part of Sysvol. Because these are two separate objects that need to replicate across your network, both need to be synchronized before the new GPO is applied.

You can view the replication status on a given domain controller by using the GPMC. In the GPMC console tree, expand Group Policy Objects in the forest or domain containing the GPOs that you want to apply, click a GPO to check, and then click the Details tab in the details pane. If the GPO is synchronized on that domain controller, the Active Directory and Sysvol version numbers will be identical for user and computer configuration. However, the user version numbers do not need to match the computer version numbers.

Requirements for performing the deployment

The primary requirement to keep in mind as you prepare to migrate your staged GPOs to your production environment is whether you have sufficient permissions on the destination GPOs. You typically need only read access to the source domain to complete a deployment. Depending on the configuration of your staging environment, you might need to follow several specific steps prior to migration. If you are performing a copy operation, you will need to have sufficient permissions to create a new GPO in the destination domain. If you are importing a backup GPO, you will need to be able to read the backup files, wherever they might be located, and then have sufficient permissions to modify an existing GPO in the destination domain that is the target of the import operation. Finally, you should ensure that the migration table that you created for each GPO that requires one is stored where it is accessible to you while performing the migration. The following checklist summarizes the items to verify before running the migration:

• For a copy operation: Ensure that the destination domain is trusted by the source domain and that you have GPO Create permissions on the destination domain. You can confirm GPO Create permissions on a domain by using the GPMC. In the GPMC console tree, expand Group Policy Objects in the destination domain and then click the Delegation tab to check which users or groups can create new GPOs in the domain.

• For an import operation: Ensure that you have access to the backup GPO files and that you have GPO Edit Settings permission on the destination GPO.

• If you are using a migration table (.migtable): Ensure that you have access to the file from the GPMC.

Deployment examples

The following two examples illustrate deploying GPOs from staging to production environments. In the first example, the staging domain is located in the same forest as the production domain. In the second example, the staging domain is in a separate forest that is not trusted by the production domain. If you use a separate staging forest that is trusted by the production domain, the steps are the same as in the first example, where the staging domain is part of the production forest.

Staging to a production domain in a single forest or from a trusted staging forest

When the staging domain is part of your production forest or you have a separate staging forest that is trusted by your production domain, your deployment method depends on whether the GPO is new or changed. If the GPO is new and does not exist in the production domain, use the copy method to deploy the new GPO. If you are deploying an update to an existing GPO, then you must to use the import method to update the production GPO’s settings with those from the backup staging GPO.

In this example, you will deploy a new GPO named Sales OU Workstation Security Policy from the staging domain to the production domain by using the GPMC. Figure 11 illustrates the staging and production domain configuration and shows the accompanying migration table.

Before beginning the deployment, load both the source and destination domains in the GPMC. If you are copying from a separate trusted forest, open both forests in the GPMC.

To deploy a new GPO using the copy method

1. In the GPMC console tree, expand Group Policy Objects in the staging domain.

2. Right-click the GPO that you plan to copy, and then click Copy.

3. In the GPMC console tree, right-click Group Policy Objects in the production domain, and then click Paste. The copying wizard opens.

4. On the copying wizard Welcome page, click Next.

5. Select Preserve or migrate the permissions from the original GPOs, and then click Next.

   This option enables you to use a migration table to map the DACL on the staging GPO to its production equivalents. If you selected the first option, Use the default permissions for new GPOs, this GPO would receive the default permissions that would be applied to any new GPO in the production domain.

6. After the wizard completes a scan of the source GPO to determine any security principal or UNC path mapping requirements, click Next.

7. On the Migrating References page, select Using this migration table to map them to new values in the new GPOs.

   This option enables to you choose a migration table to use as part of the deployment. Because you are migrating a new GPO from the staging environment to the production environment, you must choose this option. The alternate option, Copying them identically from the source, leaves all security principals and UNC paths in the new GPO exactly as they are in the source.

8. On the same page, if you want the entire migration to fail if a security principal or UNC path that exists in the source GPO is not present in the migration table, select Use migration table exclusively.

   If you select this option, the wizard will attempt to map all security principals and UNC paths by using the migration table that you specify. This is useful to ensure you have accounted for all security principals and UNC paths in your migration table.

9. Click Next.

10. On the wizard completion page, confirm that you specified the correct migration options, and then click Finish.

    After you click Finish, the migration of the staging GPO begins. Keep in mind that the new GPO is being created in the production domain but will not yet be linked to any container objects.

11. After the wizard completes the copy operation, right-click the Active Directory site, domain, or OU to which you want to link the copied GPO, and then select Link an Existing GPO.

12. In the Select GPO dialog box, select the GPO that you just copied.

After you link the new GPO and replication is complete, the GPO is live in the production domain.

Using a script to perform a copy deployment

You can also perform a copy deployment by using the script CopyGPO.wsf. This script copies a GPO from the staging domain to the production domain in a single command. To perform the same copy operation as described in the previous procedure, use the following command:

Cscript CopyGPO.wsf "Sales OU Workstation Security Policy" "Sales OU Workstation Security Policy" /SourceDomain:staging.contoso.com /TargetDomain:contoso.com /SourceDC:staging-dc1 /TargetDC:prod-DC1 /migrationtable:c:\migtables\SalestoProd.migtable /CopyACL

The first two arguments in this command specify the same name for both the source and target GPO. The next four arguments specify the source and target domain names and a domain controller in each domain. The /migrationtable argument specifies the migration table to use and the /CopyACL argument is used to preserve the DACL from the source GPO and use the specified migration table to map the source DACLs to their production domain equivalents.

Deploying to a production domain from an untrusted staging forest

If you are deploying a GPO from a staging forest that is not trusted by the production forest, the only choice for deployment is an import operation. You can also use an import to deploy an update to an existing GPO in the production domain, even if a trust relationship exists between the staging and production domains.

Import operation prerequisites

Before performing the deployment in this example, ensure that you do the following:

• If you are deploying a new GPO by using the GPMC, you need to create a new, empty GPO in your production domain that can act as a target for the import operation. Remember that the GPMC import operation works by importing the policy settings from a backup GPO into an existing destination GPO. However, you can also use the script, ImportGPO.wsf, to create a new GPO automatically, as part of the import process.

• Before beginning the import, make sure that you back up the GPOs from the staging domain that you plan to deploy to production. This is necessary because the import operation uses backup GPOs rather than live GPOs.

• If you are using the GPMC rather than a script to perform the import, you can back up the current production GPO before completing the import. You should always back up an existing production GPO before deploying a new version in case there are problems with the deployment. That way, you can perform a restore operation from the GPMC to restore the previous version of the GPO.

After you perform these tasks, use the following procedure to deploy a new GPO to the production environment by using the import operation.

To deploy a new GPO to the production domain by using the import operation

1. In the GPMC console tree, expand Group Policy Objects in the production domain.

2. Right-click the GPO to be updated, and then click Import Settings. The Import Settings Wizard opens.

3. On the Welcome page, click Next.

4. On the Backup GPO page, click Backup to back up the existing production GPO before performing the import.

5. In the Backup Group Policy Object dialog box, specify the location where the GPO backup is to be stored, type a description for the backup, and then click Backup.

6. After the GPO backup completes, a message states that the backup succeeded. Click OK.

7. On the Backup GPO page, click Next.

8. On the Backup location page, specify the folder that contains the backup of the staging GPO that you want to import.

   You must have access to the folder where you backed up your staging GPOs. If your backups were completed on a server in your staging forest, you might need to map a drive to that folder from the computer where you are running the import operation, using credentials from the staging forest.

9. Click Next.

10. On the Source GPO page, click the staging GPO that you want to import, and then click Next.

11. On the Scanning Backup page, the wizard will scan the policy settings in the backup to determine references to security principals or UNC paths that need to be transferred, and then display the results of the scan.

12. Click Next.

13. On the Migrating References page, select Using this migration table to map them to new values in the new GPOs, and then specify a path to the migration table you created for this migration.

    This option enables to you choose a migration table to use as part of the deployment. Because you are deploying a GPO from a staging domain that does not have a trust relationship with the production domain, you must use a migration table to migrate security principal and UNC path information. Otherwise, the security principals and UNC paths referenced in the untrusted forest cannot be resolved by the production domain.

14. On the same page, if you want the entire migration to fail if a security principal or UNC path that exists in the source GPO is not present in the migration table, select Use migration table exclusively.

    Use this option to only import the GPO if all security principals found in the backed up version are accounted for in the migration table.

15. Click Next.

16. On the wizard completion page, confirm that you specified the correct migration options, and then click Finish. After you click Finish, the migration of the staging GPO begins. After the wizard completes the import operation, a message will state that the import was successful.

17. Click OK.

If you created a new production GPO to perform this import, you must link the new GPO to the appropriate container object. To link the GPO to the appropriate container object, in the GPMC console tree, in the production domain, right-click the Active Directory site, domain, or OU to which you want to link the imported GPO, click Link an Existing GPO, specify the GPO that you want to link, and then click OK. After you link the new GPO and replication is complete, the GPO is live in the production domain.

Using a script to perform an import deployment

You can also perform an import deployment by using the script ImportGPO.wsf. This script enables you to import a backup GPO into your production domain. If the target GPO does not yet exist, the script also enables you to create a new GPO to receive the import as part of the process. To perform the same import operation as described in the previous procedure, type the following command:

Cscript ImportGPO.wsf c:\gpobacks "Sales OU Workstation Security Policy" "Sales OU Workstation Security Policy" /CreateIfNeeded /MigrationTable:c:\migtables\salesprod.migtable /Domain:contoso.com

The first argument in this command specifies the location of the backup GPO files. The second argument specifies the name of the backed-up GPO from which to import (you can instead provide the Backup ID, which is a 128-bit GUID value generated by the backup utility to uniquely identify the backup). The third argument specifies the name of the destination GPO to import into. The /CreateIfNeeded argument indicates that if the destination GPO does not yet exist, it should be created before performing the import. The /MigrationTable argument specifies the path and name of the migration table file. The /Domain argument provides the DNS name of the destination domain.

Rollback

In the event that you have a problem with a GPO after you deploy it from the staging environment to the production environment, the best way to roll back the deployment is to use the backup GPO that you created to restore the original GPO. You can also use the RestoreGPO.wsf script to perform the restore process. As part of your deployment, it is a good idea to create a set of scripts that you can use to perform an automated rollback of all of your changes by using RestoreGPO.wsf. In the event that you need to perform a rollback, the script is ready and available to use with minimal user disruption.

Additional resources for Group Policy

• Group Policy TechCenter (https://go.microsoft.com/fwlink/?LinkId=109523)

• "Group Policy" in Help and Support Center for Windows Server 2008 (https://go.microsoft.com/fwlink/?LinkId=109524).

• Help in the GPMC for detailed information about using the GPMC to help deploy Group Policy.

• Help for specific Group Policy settings in the default Extended view when editing from the GPMC (select a Group Policy setting to view the detailed information for that policy setting).

• Windows Server 2008 Command Reference A-Z List, for more information about command-line tools such as Dcgpofix.exe, Gpupdate.exe, and Gpresult.exe (https://go.microsoft.com/fwlink/?LinkId=109525).