Any
migration procedure should define the reasons for migration, steps
involved, fallback precautions, and other important factors that can
influence the migration process. After finalizing these items, the
migration can begin.
Identifying Migration Objectives
Two
underlying philosophies influence technology upgrades, each philosophy
working against the other. The first is the expression “If it ain’t
broke, don’t fix it.” Obviously, if an organization has a functional,
easy-to-use, and well-designed Active Directory 2003 infrastructure,
popping in a Windows Server 2008 or 2008 R2 DVD and upgrading the domain
might not be so appealing. The second philosophy is something along the
lines of “Those who fail to upgrade their technologies perish.”
Eventually, all technologies become outdated and unsupported, and a
planned and staged update to the latest technologies keeps the
organization’s network current.
Choosing a pragmatic
middle ground between these two philosophies effectively depends on the
factors that drive an organization to upgrade. If the organization has
critical business needs that can be satisfied by an upgrade, such an
upgrade might be in the works. If, however, no critical need exists, it
might be wise for an organization already on Active Directory 2003 to
remain on Active Directory 2003 and not advance to Active Directory 2008
if they don’t want to migrate since Exchange Server 2010 works fine in
an Active Directory 2003 environment.
Establishing Migration Project Phases
After the decision is made
to upgrade, a detailed plan of the resources, timeline, scope, and
objectives of the project should be outlined. Part of any migration plan
requires establishing either an ad-hoc project plan or a professionally
drawn-up project plan. The migration
plan assists the project managers of the migration project to
accomplish the planned objectives in a timely manner with the correct
application of resources.
The following is a condensed description of the standard phases for a migration project:
Discovery—
The first portion of a design project should be a discovery, or
fact-finding, portion. This section focuses on the analysis of the
current environment and documentation of the analysis results. Current
network diagrams, server locations, wide area network (WAN) throughputs,
server application dependencies, and all other networking components
should be detailed as part of the Discovery phase.
Design—
The Design portion of a project is straightforward. All key components
of the actual migration plan should be documented, and key data from the
Discovery phase should be used to draw up design and migration
documents. The project plan itself would normally be drafted during this
phase. Because Active Directory 2008 is not dramatically different from
Active Directory 2000 or 2003, significant reengineering of an existing
Active Directory environment is not necessary. However, other issues
such as server placement, new feature utilization, and changes in AD DS
replication models should be outlined.
Prototype—
The Prototype phase of a project involves the essential lab work to
test the design assumptions made during the Design phase. The ideal
prototype would involve a mock production environment that is migrated
from Active Directory 2000/2003 to Active Directory 2008. For Active
Directory, this means creating a production domain controller (DC) and
then isolating it in the lab and promoting it to the Operations Master
(OM) server in the lab. The Active Directory migration can then be
performed without affecting the production environment. Step-by-step
procedures for the migration can also be outlined and produced as
deliverables for this phase.
Pilot—
The Pilot phase, or Proof-of-Concept phase, involves a production
“test” of the migration steps, on a limited scale. For example, a single
server could be upgraded to Active Directory 2008 in advance of the
migration of all other global catalog servers. In a slower, phased
migration, the Pilot phase would essentially spill into Implementation,
as upgrades of global catalog and domain controller servers are
performed slowly, one by one.
Implementation—
The Implementation portion of the project is the full-blown migration
of network functionality or upgrades to the operating system. As
previously mentioned, this process can be performed quickly or slowly
over time, depending on an organization’s needs. It is, subsequently,
important to make the timeline decisions in the Design phase and
incorporate them into the project plan.
Training and Support—
Learning the ins and outs of the new functionality that Active
Directory 2008 can bring to an environment is essential in realizing the
increased productivity and reduced administration that the OS can bring
to the environment. Consequently, it is important to include a Training
portion into a migration project so that the design objectives can be
fully realized.
Comparing the In-Place Upgrade Versus New Hardware Migration Methods
Because the
fundamental differences between Active Directory 2000/2003 and Active
Directory 2008 are not significant, the possibility of simply upgrading
an existing Active Directory 2000/2003 infrastructure is an option.
Depending on the type of hardware currently in use in a Windows
2000/2003 network, this type of migration strategy becomes an option.
Often, however, it is more appealing to simply introduce newer systems
into an existing environment and retire the current servers from
production. This technique normally has less impact on current
environments and can also support fallback more easily.
Note
Windows 2000 domain
controllers cannot be upgraded directly to Windows 2008. Migrating a
Windows 2000 domain controller to be a Windows 2008 domain controller
requires the Windows 2000 domain controller to be replaced, rather than
upgraded.
Determining which
migration strategy to use depends on one major factor: the condition of
the current hardware environment. If Windows 2000/2003 is taxing the
limitations of the hardware in use, it might be preferable to introduce
new servers into an environment and simply retire the old Windows
2000/2003 servers. This is particularly true if the existing servers are
veterans of previous upgrades, maybe transitioning from Windows NT 4.0
to Windows 2000 to Windows Server 2003. If, however, the hardware in use
is newer and more robust, and could conceivably last for another two to
three years, it might be easier to simply perform in-place upgrades of
the systems in an environment.
In most cases,
organizations take a hybrid approach to migration. Older hardware or
Windows 2000 domain controllers are replaced by new hardware running
Windows 2003 or 2008. Newer Windows 2003 systems can more easily be
upgraded in place to Windows 2008. Consequently, auditing all systems to
be migrated and determining which ones will be upgraded and which ones
will be retired are important steps in the migration process.
Identifying Migration Strategies: “Big Bang” Versus Phased Coexistence
As with
most technology implementations, there are essentially two approaches
in regard to deployment: a quick “Big Bang” approach or a slower phased
coexistence approach. The Big Bang option involves the entire Windows
2000/2003 infrastructure being quickly replaced, often over the course
of a weekend, with the new Windows 2008 environment; whereas the phased
approach involves a slow, server-by-server replacement of Windows
2000/2003.
Each
approach has its particular advantages and disadvantages, and key
factors to Windows 2008 should be taken into account before a decision
is made. Few Windows 2008 components require a redesign of current
Windows 2000/2003 design elements. Because the arguments for the Big
Bang approach largely revolve around not maintaining two conflicting
systems for long periods of time, the similarities between Windows
2000/2003 and Windows 2008 make many of these arguments moot. Windows
2008 domain controllers can easily coexist with Windows 2003 and Windows
2000 domain controllers. With this point in mind, while coexistence of
mixed domain controllers is possible, the quicker the organization
migrates to a common platform, the less likelihood that domain
controller version differences will create problems in domain controller
replication and operations.