Creating the Staging Environment

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

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

Figure 3.5   Creating the Staging Environment

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 3.1.

Table 3.1   Choosing a Staging Approach

Approach	Advantages	Disadvantages
Staging Domain within Production Forest	Can use 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 supporting infrastructure. Easier to keep synchronized with production environment because all 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 re-used 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). 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 settings and configurations without affecting the production environment.	Difficult to keep synchronized with production forest. Without trusts, movement of data and 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 GPMC copy operation to migrate GPOs; must use GPMC import.
Staging Forest with trusts to Production Forest	Can use GPMC copy operation to move GPOs between staging and production environments. Somewhat isolated from production environment. Provides flexibility; administrators can experiment freely with settings and configurations without affecting the production environment. Might not need migration tables to map UNC paths, since all paths could be available via current trusts.	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.

Weigh the advantages and disadvantages described in Table 3.1 when making your choice of a staging approach. Ultimately, your choice depends on your own unique requirements. Once you have made your choice, you are ready to determine the hardware requirements for the staging environment.

Hardware Requirements

Regardless of the approach you choose, it will be necessary to dedicate some additional hardware to the construction of your staging environment. How much hardware you need depends upon the kinds of testing you need to do and how specific your Group Policy testing requirements are. For example, if your production forest has workstations located across slow network links from your domain controllers, this fact can affect the application of 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 get an accurate picture of how your production environment will be impacted by changes in Group Policy. GPMC can help in such a situation, for example, by providing the capability to model the impact of slow links on GPO application. 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 what computers and users in your production environment will see when new or changed GPOs are applied.

Preparing the Staging Environment

Once you have chosen a staging approach and set up your hardware, install Windows Server 2003 (or Windows 2000 Server) 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 the staging environment is running at the same operating system, service pack and hot fix levels as your production environment. This is important to ensure consistent test results. In addition, ensure that the supporting infrastructure, such as Directory Name Service (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 in your production forest, then you can use your existing production DNS infrastructure for name services.

Important

• You can use GPMC to manage both Windows Server 2003 and Windows 2000 Active Directory–based domains, but you must run GPMC on a computer running a member of the Windows Server 2003 family operating system or Windows XP Professional SP1 and the .Net Framework.

If you build a separate forest for staging, then 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 Active Directory–integrated DNS in your production forest, because 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. Note that if both your staging and production forests are running at Windows Server 2003 forest functionality level, and you want to create inter-forest trusts between the two forests, then DNS integration is required. However, if you are running at Windows 2000 forest functionality level, which requires the use of down-level trusts, you must have the WINS service available and integrated between the two forests to create the required trusts.

Once 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.