Synchronizing the Staging and Production Environments

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

Once you have created a basic staging infrastructure that reflects your production environment, you need to ensure that all GPO settings and security are identical between the two environments. Synchronization also requires ensuring that a sufficient representation of OUs, users, computers and groups exist 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. Figure 3.6 illustrates the synchronization step in the staging process.

Figure 3.6   Synchronizing the Staging and Production Environments

Synchronizing Staging and Production Environments

The goal of any test environment is to ensure that it mirrors the production environment as closely as possible. You can use GPMC tools to help both with the initial synchronization and to keep the test environment synchronized with the production environment over time. The first set of tools you will use are two Windows Script Host (WSH) scripts that are installed with GPMC. These two scripts, CreateXMLFromEnvironment.wsf and CreateEnvironmentFromXML.wsf, are installed in the Scripts folder in the folder Program Files\GPMC\Scripts. The script CreateXMLFromEnvironment.wsf is run 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 re-create GPOs and other objects from the production domain in a staging domain. Table 3.2 describes the objects and settings that CreateXMLFromEnvironment.wsf captures, and shows additional objects you can capture by using command-line options when running the script.

Table 3.2   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 get 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 switch, along 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 bear 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. (For an example of the syntax, see the file SampleEnvironment.xml in the Program Files\GPMC\Scripts folder on any computer where you have installed GPMC.) Alternatively, if you have any users that do not have passwords specified in the XML file, the CreateEnvironment 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 have an impact on Active Directory replication, it is best to re-create these objects, and GPO links on them, manually in your staging environment.