Read Windows Server 2008 R2 Unleashed Online
Authors: Noel Morimoto
upgraded to Windows Server 2008 R2 in advance of the migration of all other criti-
cal 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 previ-
ously mentioned, this process can be performed quickly or slowly over time, depend-
ing 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
ptg
increased productivity and reduced administration that the OS can bring to the envi-
ronment. Consequently, it is important to include a Training portion into a migra-
16
tion project so that the design objectives can be fully realized.
For more detailed information on the project plan phases of a Windows Server 2008 R2
migration, refer to Chapter 2, “Planning, Prototyping, Migrating, and Deploying Windows
Server 2008 R2 Best Practices.”
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 envi-
ronments 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 condi-
tion of the current hardware environment. If Windows Server 2003/2008 is taxing the
486
CHAPTER 16
Migrating from Windows Server 2003/2008 to Windows Server
2008 R2
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 particu-
larly 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.
ptg
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 replace-
ment 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 migra-
tions 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.
Big Bang Migration
487
In this chapter, 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.
The remainder of this chapter walks through each of these scenarios step-by-step.
ptg
The Big Bang approach to migrate from Windows Server 2008 to Windows Server 2008 R2
16
is the most straightforward approach to migration. An upgrade simply takes any and all
settings on the domain controllers and upgrades them to Windows Server 2008 R2. If a
Windows Server 2008 server handles Windows Internet Naming Service (WINS), domain
name system (DNS), and Dynamic Host Configuration Protocol (DHCP), the upgrade
process will upgrade all WINS, DNS, and DHCP components, as well as the base operating
system. This makes this type of migration very tempting, and it can be extremely effec-
tive, as long as all prerequisites described in the following sections are satisfied.
The prerequisites are as follows:
. The operating system on the domain controllers is Windows Server 2003 SP2 or higher.
. The domain controller hardware exceeds the Windows Server 2008 R2 requirements
and all software is compatible with Windows Server 2008 R2, including antivirus
software and drivers.
. There is enough disk space free to perform the operating system and Active
Directory upgrade. Specifically, verify that your free space is at least twice the size of
your Active Directory database plus the minimum 32GB needed to install the operat-
ing system.
. The current domain functional level is Windows 2000 Native or Windows Server
2003. You cannot upgrade directly from Windows NT 4.0, Windows 2000 Mixed, or
Windows Server 2003 interim domain functional levels.
488
CHAPTER 16
Migrating from Windows Server 2003/2008 to Windows Server
2008 R2
Often, upgrading any given server can be a project in itself. The standalone member
servers in an environment are often the workhorses of the network, loaded with a myriad
of different applications and critical tools. Performing an upgrade on these servers would
be simple if they were used only for file or print duties and if their hardware systems were
all up to date. Because this is not always the case, it is important to detail the specifics of
each server that is marked for migration.
Verifying Hardware Compatibility
It is critical to test the hardware compatibility of any server that will be directly upgraded
to Windows Server 2008 R2. The middle of the installation process is not the most ideal
time to be notified of problems with compatibility between older system components and
the drivers required for Windows Server 2008 R2. Subsequently, the hardware in a server
should be verified for Windows Server 2008 R2 on the manufacturer’s website or on
Microsoft’s Hardware Compatibility List (HCL), currently located at http://www.microsoft.
com/whdc/hcl/default.mspx.
Microsoft suggests minimum hardware levels on which Windows Server 2008 R2 will run,
but it is highly recommended that you install the OS on systems of a much higher caliber
because these recommendations do not take into account any application loads, domain
ptg
controller duties, and so on. The following is a list of Microsoft’s minimum hardware
levels for Windows Server 2008 R2:
. 1.4GHz 64-bit processor
. 512MB of RAM
. 32GB free disk space
That said, it cannot be stressed enough that it is almost always recommended that you
exceed these levels to provide for a robust computing environment. See Chapter 3,
“Installing Windows Server 2008 R2 and Server Core,” for additional details on hardware
requirements.
NOTE
One of the most important features that mission-critical servers can have is redundan-
cy. Putting the operating system on a mirrored array of disks, for example, is a simple
yet effective way of increasing redundancy in an environment.
Verifying Application Readiness
Nothing ruins a migration process like discovering a mission-critical application that is
installed on the current Windows Server 2003 server will not work in the new environ-
ment. Subsequently, it is very important to identify and list all applications on a server
that will be required in the new environment. Applications that will not be used or whose
Big Bang Migration
489
functionality is replaced in Windows Server 2008 R2 can be retired and removed from
consideration. Likewise, applications that have been verified for Windows Server 2008 R2
can be designated as safe for upgrade. For any other applications that might not be
compatible but are necessary, you either need to move them to another Windows Server
2003 server or delay the upgrade of that specific server.
In addition to the applications, the version of the operating system that will be upgraded
is an important consideration in the process. A Windows Server 2003 SP2 or R2, Standard
Edition domain controller can be upgraded to either Windows Server 2008 R2, Standard
Edition or Windows Server 2008 R2, Enterprise Edition. However, a Windows Server 2003
SP2 or R2, Enterprise Edition installation can only be upgraded to Windows Server 2008
R2, Enterprise Edition.
Backing Up and Creating a Recovery Process
It is critical that a migration does not cause more harm than good to an environment.
Subsequently, we cannot stress enough that a good backup system is essential for quick
recovery in the event of upgrade failure. Often, especially with the in-place upgrade
scenario, a full system backup might be the only way to recover; consequently, it is very
important to detail fallback steps in the event of problems. The backup should include the
boot and system partitions as well as the System State.
ptg
Virtual Domain Controller Rollback Option
16
It is always good to have several fallback options, in case one of the options is unsuccess-
ful. Another option to consider, in addition to a full backup, is to create a virtual domain
controller. Using a virtual server platform such as Hyper-V or VMware Server, you can
create a domain controller for little or no cost.
A virtual machine is created on the host, which can be an existing installation or even on
a desktop with Virtual PC or VMware Workstation. This virtual machine is then joined to
the domain and promoted to be a domain controller.
Prior to the upgrade, the virtual domain controller is shut down. Backup copies of the
virtual domain controller files can even be made for safekeeping.
In the event of a major failure in the upgrade process, the virtual domain controller can
be used to rebuild the domain from scratch. If the upgrade is successful, the virtual