Creating a Test Forest

Creating a test forest is useful for testing global changes to Active Directory such as elevating the Functional Level or adding new object classes to the schema. These changes are irreversible, so it is important that you test them carefully before you apply them to your production AD forest.

Microsoft recommends that you validate the compatibility of all security-related configuration changes in a test forest before you introduce them in a production environment (KB823659).

To create a test forest it is not necessary to clone all of the domain controllers (DCs) in the forest.

For testing changes to the AD schema the following DCs are usually sufficient:

1. The DC that has the Schema Master Role. It coordinates adding new object classes or new attribute types to the design (schema) of the AD database.
2. The DC that hosts the primary DNS server.
3. A DC that has the Global Catalog (GC).

For testing changes to inter-domain trusts or cross-domain security settings, the following DCs are usually sufficient:

1. The DC that has the Primary Domain Controller (PDC) FSMO role, one for each domain.
2. The DC that hosts the primary DNS server. (If different domains are hosted by different primary DNS servers you will need to include one primary DNS server for each domain.)
3. A DC that has the Global Catalog (GC).

Copying FSMO Roles

Active Directory is a multi-master distributed database. This means that any DC can assume the role of a master for some task. These roles are called Flexible Single Master Operations roles, or FSMO (“fizz-moh”) roles.

Usually the PDC(s) will hold all of the FSMO roles. This is the most common case. Simply clone the PDC(s) to your test network and you are done.

Rare: In rare cases you may have assigned a non-PDC with a FSMO role. In addition to cloning the PDC(s) you will need to clone the DCs that hold the missing FSMO roles (see below).

FSMO Roles

There are five Flexible Single Master Operation (FSMO) roles in Active Directory:

1. The Primary Domain Controller (PDC) emulator role, one per domain. It coordinates password changes and provides PDC emulation for legacy Windows NT domain controllers.
2. The Relative Identifier (RID) Master role, one per domain. It allocates RIDs for newly created users and groups.
3. The Schema Master Role, one per forest. It coordinates adding new object classes to the AD schema.
4. The Domain Naming Master role, one per forest. It coordinates adding or deleting domains and renaming domains.
5. The Infrastructure role, one per domain. It updates cross-domain references to renamed objects. (The Infrastructure FSMO role has special rules -- see below.)

Windows Server 2008: To view which DCs have the FSMO roles, type the console command netdom query fsmo.

Windows Server 2000/2003: To view which DCs have the FSMO roles see “How to view and transfer FSMO roles in Windows Server 2003” (KB324801).

Verify that the DCs in your test network have the FSMO roles listed above and that at least one DC has the Global Catalog (GC).

The Infrastructure FSMO role is special

The Infrastructure FSMO role has special rules. The Infrastructure role should be held by a DC that is not a GC in the same domain. This is because the GC holds a partial replica of every object in the forest. The Infrastructure FSMO role must be held by a DC that is not a GC in the same domain so that it can identify and fix discrepancies between the GC and its own domain objects (See KB197132).

General Exception: You can safely ignore the Infrastructure role in the following common case: If all of the DCs in the domain are also GCs (which is a common configuration for the DCs in the forest root domain), or if none of the DCs in the domain are GCs (which is a common configuration for the DCs in other domains), then the Infrastructure FSMO role does not matter (see KB197132).

The all/none rule applies only to the DCs actually running. Typically you only clone one DC per domain (the PDC). If your test lab has only one cloned DC for each domain being tested (for example, if you are cloning only PDCs as recommended above) then the Infrastructure FSMO role does not matter.

Multiple Sites

A site is a physical grouping of domain controllers for the purpose of replication. AD assumes that all computers in the same site can do fast replication.

If you have a geographically dispersed AD forest you may have multiple sites. Sites are usually grouped by subnet (e.g., Site 1 = 10.1.0.0/16, and Site 2 = 10.2.0.0/16).

Your testbed will need to reproduce the site topology of your AD forest. Alternately, you can move all DCs into the same site. To modify the site topology in your testbed run the Active Directory Sites and Services utility.

For more information

See the topic Steps for Testing.