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 Windows Server 2003/2008 infrastructure, popping in
that Windows Server 2008 R2 DVD and upgrading 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.
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 a good idea. If, however, no critical need exists, it
might be wise to wait until the next iteration of Windows or a future
service pack for Windows Server 2008 R2.
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 Windows Server 2008 R2
Active Directory is not dramatically different from Windows Server 2003
or 2008, 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 Windows Server 2003/2008 to Windows Server 2008 R2. For
Active Directory, this means creating a production domain controller
(DC) and then isolating it in the lab and seizing the Flexible Single
Master Operations (FSMO) roles with a 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 noncritical server could be upgraded to Windows Server 2008
R2 in advance of the migration of all other critical network servers. In
a slow, phased migration, the Pilot phase would essentially transition
into Implementation, as upgrades 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 Windows Server 2008 R2 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
Due to the changes in
Windows Server 2008 R2, the in-place upgrade path is limited to servers
using the 64-bit version of Windows Server 2003 and Windows Server 2008.
Depending on the type of hardware currently in use in a Windows Server
2003/2008 network, this type of migration strategy might be 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
Because Windows Server 2008 R2 is
a 64-bit only operating system, upgrades from 32-bit versions of older
operating systems are not supported. Upgrades from Windows 2000 Server
are also not supported.
Determining which migration
strategy to use depends on one additional factor: the condition of the
current hardware environment. If Windows Server 2003/2008 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 Server 2003/2008 servers. This is particularly
true if the existing servers are veterans of previous upgrades, maybe
transitioning from Windows 2000 Server to Windows Server 2003 to Windows
Server 2008. If, however, the hardware in use for Windows Server
2003/2008 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, 32-bit systems, or
Windows Server 2003 domain controllers are replaced by new hardware
running Windows Server 2008 R2. Newer Windows Server 2008 64-bit systems
are instead upgraded in place to Windows Server 2008 R2. 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 Server
2003/2008 infrastructure being quickly replaced, often over the course
of a weekend, with the new Windows Server 2008 R2 environment; whereas
the phased approach involves a slow, server-by-server replacement of
Windows Server 2003/2008.
Each approach has its
particular advantages and disadvantages, and key factors to Windows
Server 2008 R2 should be taken into account before a decision is made.
Few Windows Server 2008 R2 components require a redesign of current
Windows Server 2003/2008 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
Server 2003/2008 and Windows Server 2008 R2 make many of these arguments
moot. Windows Server 2008 R2 domain controllers can easily coexist with
Windows Server 2003/2008 domain controllers. With this point in mind,
it is more likely that most organizations will choose to ease into
Windows Server 2008 R2, opting for the phased coexistence approach to
the upgrade. Because Windows Server 2008 R2 readily fits into a Windows
Server 2003/2008 environment, and vice versa, this option is easily
supported.
Exploring Migration
Options
As previously mentioned,
the Windows Server 2008 R2 and Windows Server 2003/2008 Active
Directory domain controllers coexist together very well. The added
advantage to this fact is that there is greater flexibility for
different migration options. Unlike migrations from NT 4.0 or
non-Microsoft environments such as Novell NDS/eDirectory, the migration
path between these two systems is not rigid, and different approaches
can be used successfully to achieve the final objectives desired.
In
this article, three Windows Server 2008 R2 migration scenarios are
explored:
Big Bang
migration— This scenario
upgrades all domain controllers in a short span of time. This is
typically suitable only for single domain and small organizations.
Phased migration— This scenario takes a phased coexistence
approach and upgrades the domain controllers in phases over an extended
period of time. During this time, there is coexistence between the
existing versions of Active Directory and the new Windows Server 2008 R2
Active Directory Domain Services. This is typically the approach used
when there are multiple domains or for large organizations.
Multiple domain
consolidation migration— A
variation on the phased upgrade, the multiple domain consolidation
migrates the existing domains to a new Windows Server 2008 R2 Active
Directory domain. This is the typical approach when there are problems
with the existing domains, too many domains, or when merging
organizations.