Windows Server 2008 R2 Unleashed (100 page)

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.

Big Bang Migration

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