Regardless
of the method that is chosen to transition Exchange Server, 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 transition process. Establishing
a functional prototype environment also can help reduce the risk
associated with transitions. 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 transition.
Creating Temporary Prototype Domain Controllers to Simulate Transition
Construction of a
prototype lab to simulate an existing Exchange Server 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
You should
keep several considerations 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 the current network environment 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.
Seizing Operations Master (OM) Roles in the Lab Environment
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 (also referred to as Flexible Single Master
Operations [FSMO]) roles. One approach uses the ntdsutil utility, as follows:
1. | Open a command prompt by selecting Start, Run, typing cmd in the Open text box, and then clicking OK.
Caution
Remember, this procedure
should only be performed in a lab environment or in disaster recovery
situations. Never perform it against a running production domain
controller unless the intent is to forcibly move OM roles.
|
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/2008
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 transition 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 option—which is often easier to accomplish but is
somewhat riskier—is 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 Server 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 the major backup software implementations contain specific
procedures for restoring an Exchange Server 2003 environment. Using
these procedures is the most ideal way of duplicating the environment
for the transition testing.
Validating and Documenting Design Decisions and Transition Procedures
The actual transition
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, but it can also be useful for testing new software
and procedures for production servers.
The chosen transition
strategy—whether it be an in-place upgrade, a move mailbox method, or
another approach—can be effectively tested in the prototype lab at this
point. Follow all transition steps as if they were happening in
production.
