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 generally 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:
- 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.
- The DC that hosts the primary DNS server.
- 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:
- The DC that has the Primary Domain Controller (PDC) FSMO role, one for each domain.
- 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.)
- 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).
About FSMO Roles
For detailed background information about the different FSMO roles see the topic FSMO Roles.
To view which DCs have the FSMO roles, type the console command netdom query fsmo.
Windows Server 2003: To view which DCs have the FSMO roles see “How to view and transfer FSMO roles in Windows Server 2003” (KB324801).
Generally it is sufficient to clone only the PDCs, one for each domain that you want to test. Verify that the PDCs in your test network have all the FSMO roles and that at least one DC has the Global Catalog (GC).
Important: Select 'Test'
The reason is that when a DC first boots with a reloaded copy of AD, the AD database engine will temporarily block all FSMO operations until the DC can replicate with at least one other DC in the same domain. This is a safety feature to confirm that the reloaded DC actually owns the FSMO roles it claims to have. The purpose is to prevent accidental conflicts between the restored DC and the other DCs that might also have the same roles.
When you select the test as the loading method, U-Move will arrange to notify the reloaded DC during boot that its FSMO roles are indeed valid. The AD engine will then unblock all FSMO operations on the newly reloaded DC.
This is required whenever you clone only the PDC (as recommended above) because there will be no other DCs available for replication. It allows you to perform FSMO-related operations in your test lab using only a single DC: changing a password, adding a new user, updating the AD schema, and so on.
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.
|U-Move for Active Directory|