Deploying a Prototype Lab for the Exchange Server 2003 Migration Process

Regardless of the method that is chosen to migrate Exchange, care should be taken to test design assumptions as part of a comprehensive prototype lab. A prototype environment can help simulate the conditions that will be experienced as part of the migration process. Establishing a functional prototype environment also can help reduce the risk associated with migrations. In addition to traditional approaches for creating a prototype lab, which involves restoring from backups , several techniques exist to replicate the current production environment to simulate migration.

Creating Temporary Prototype Domain Controllers to Simulate Migration

Construction of a prototype lab to simulate existing Exchange 2000 infrastructure is not particularly complicated, but requires thought in its implementation. Because an exact copy of the Active Directory is required, the most straightforward way of accomplishing this is by building a new domain controller in the production domain and then isolating that domain controller in the lab to create a mirror copy of the existing domain data. DNS and global catalog information should be transferred to the server when in production, to enable continuation of these services in the testing environment.

NOTE

There are several considerations to keep in mind if planning this type of duplication of the production environment. First, when the temporary domain controller is made into a global catalog server, the potential exists for Exchange 2000 to identify it as a working global catalog server and refer clients to it for directory lookups. When the server is brought offline, the clients would experience connectivity issues. For these reasons, it is good practice to create a temporary domain controller during off-hours.

A major caveat to this approach is that the system must be completely separate, with no way to communicate with the production environment. This is especially the case because the domain controllers in the prototype lab respond to requests made to the production domain, authenticating user and computer accounts and replicating information. Prototype domain controllers should never be added back into a production environment. Removing the domain controller from the production network topology can help to ensure that it does not communicate back changes as well.

Seizing Operations Master (OM) Roles in the Lab Environment

1. Because Active Directory is a multimaster directory, any one of the domain controllers can authenticate and replicate information. This factor is what makes it possible to segregate the domain controllers into a prototype environment easily. There are several different procedures that can be used to seize the OM roles. One approach uses the ntdsutil utility: Open a Command Prompt by selecting Start, Run and typing cmd . Press Enter.

2. Type ntdsutil and press Enter.

3. Type roles and press Enter.

4. Type connections and press Enter.

5. Type connect to server SERVERNAME (where SERVERNAME is the name of the target Windows Server 2003 domain controller that will hold the OM Roles) and press Enter.

6. Type quit and press Enter.

7. Type seize schema master and press Enter.

8. Click Yes at the prompt asking to confirm the OM change.

9. Type seize domain naming master and press Enter.

10. Click Yes at the prompt asking to confirm the OM change.

11. Type seize pdc and press Enter.

12. Click OK at the prompt asking to confirm the OM change.

13. Type seize rid master and press Enter.

14. Click OK at the prompt asking to confirm the OM change.

15. Type seize infrastructure master and press Enter.

16. Click OK at the prompt asking to confirm the OM change.

17. Exit the Command Prompt Window.

After these procedures have been run, the domain controllers in the prototype lab environment will control the OM roles for the forest and domain, which is necessary for additional migration testing.

NOTE

Although the temporary domain controller procedure just described can be very useful toward producing a copy of the AD environment for a prototype lab, it is not the only method that can accomplish this. The AD domain controllers can also be restored via the backup software's restore procedure. A third optionwhich is often easier to accomplish but is somewhat riskieris to break the mirror on a production domain controller, take that hard drive into the prototype lab, and install it in an identical server. This procedure requires the production server to lose redundancy for a period of time while the mirror is rebuilt, but is a "quick and dirty" way to make a copy of the production environment.

Restoring the Exchange Environment for Prototype Purposes

After all forest and domain roles have been seized in the lab, the Exchange server or servers must be duplicated in the lab environment. Typically, this involves running a restore of the Exchange server on an equivalent piece of hardware. All of the major backup software implementations contain specific procedures for restoring an Exchange 2000 environment. Using these procedures is the most ideal way of duplicating the environment for the migration testing.

Validating and Documenting Design Decisions and Migration Procedures

The actual migration process in a prototype lab should follow, as closely as possible, any design decisions made regarding an Exchange Server 2003 implementation. It is ideal to document the steps involved in the process so that they can be used during the actual implementation to validate the process. The prototype lab is not only an extremely useful tool for validating the upgrade process, it can also be useful for testing new software and procedures for production servers.

The migration strategy chosenwhether it be an in-place upgrade, a move mailbox method, or another approachcan be effectively tested in the prototype lab at this point. Follow all migration steps as if they were happening in production.