Windows Server 2008 R2 Unleashed (23 page)

needs to sign off on the results of the prototype phase to indicate that the goals were all

met and that the design agreed upon is ready to be created in the production environment?

ptg

Similar levels of information are included for the pilot phase and the all-important migra-

tion itself. Typically during the pilot phase, all the upgraded functionality needs to be

tested, including remote access, file encryption access, and access to shared folders. Be

aware that pilot testing might require external coordination. For example, if you are

testing remote access through a VPN connection, you might need to acquire an additional

external IP address and arrange to have an address record created in DNS to allow your

external testers to reach it without having to disturb your existing remote access systems.

The migration plan should also account for support tasks that need to occur after the

Windows Server 2008 R2 infrastructure is fully in place. If you are using an outside

consulting firm for assistance in the design and implementation, you should make sure

that they will leave staff onsite for a period of time immediately after the upgrade to be

available to support user issues or to troubleshoot any technical issues that crop up.

If documentation is specified as part of the support phase, such as Windows maintenance

documents, disaster recovery plans, or procedural guides, expectations for these documents

should be included to help the technical writers make sure the documents are satisfactory.

The Budget Section

With regard to the budget information, although a great amount of thought and planning

has gone into the design and migration documents, as well as the project plan, there are

still variables. No matter how detailed these documents are, the later phases of the project

might change based on the results of the earlier phases. For instance, the prototype testing

might go flawlessly, but during the pilot implementation, performing data migration

simply takes longer than anticipated; this extra time will require modifications to the

amount of time required and the associated costs. Note that changes in the opposite direc-

tion can happen as well, if tasks can occur more quickly than anticipated. Often, the

The Prototype Phase: Creating and Testing the Plan

73

implementation costs can be reduced by keeping an eye on ways to improve the process

during the prototype and pilot phases.

The Project Schedule Section

Whereas the project plan provides the high-level details of the steps, or tasks, required in

each phase, the approach sections of the migration document can go into more detail

2

about the details of each step of the project plan, as needed. Certain very complex tasks are

represented with one line on the project plan, such as “Configure Windows Server 2008 R2

#1” and might take several pages to describe in sufficient detail in the migration document.

Data availability testing and disaster recovery testing should be discussed. In the design

document, you might have decided that clustering will be used, as well as a particular tape

backup program, but the migration plan should outline exactly which scenarios should be

tested in the prototype lab environment.

Documents to be provided during the migration should be defined so that it is clear what

they will contain.

The Prototype Phase: Creating and Testing the Plan

ptg

The main goal of the prototype phase is to create a lab environment in which the key

elements of the design as defined in the design document can be configured and tested.

Based on the results of the prototype, you can determine whether any changes are needed

to the implementation and support phases as outlined in the migration document.

The prototype phase is also a training phase, in which the members of the deployment

team get a chance to get their hands dirty with the new hardware and software technolo-

gies to be implemented. If an external consulting firm is assisting with the prototype

testing, knowledge transfer should occur and be expected during this process. Even if the

deployment team has attended classroom training, the prototype process is an environ-

ment that will more closely reflect the end state of the network that needs to be

supported, and will involve technologies and processes not typically covered in classroom-

style training. The deployment team can also benefit from the real-world experience of

the consultants if they are assisting in this phase.

This environment should be isolated from the production network so that problems

created by or encountered in the process don’t affect the user community.

The design details of testing applications, confirming hardware performance, testing fault

tolerance failover, and the like should be verified in a safe lab environment. If changes are

needed to the design document, they should be made now.

How Do You Build the Lab?

Although the details of the project will determine the specifics of exactly what will be in

the prototype lab, certain common elements will be required. The migration document

should clearly outline the components of the lab and what applications and processes

74

CHAPTER 2

Planning, Prototyping, Migrating, and Deploying Windows Server 2008

R2 Best Practices

should be tested. A typical environment will consist of the primary Windows Server 2008

R2 server required for the implementation, as well as network switches, sample worksta-

tions, and printers from the production environment. Connectivity to the outside world

should be available for testing purposes.

A key decision to make is whether the lab will be implemented into the environment or

stay as a lab. Some companies will proceed from the prototype phase to the pilot phase with

the same equipment, whereas others prefer to keep a lab set up for future use. The advan-

tages of having a lab environment for a Windows Server 2008 R2 environment are many,

and include testing NOS and application updates, upgrades and patches, as well as having

hardware available for replacement of failed components in the production environment.

Real data and applications should be installed and tested. Data can be copied from live

production servers, or data from tape can be restored to the test server. Applications

should be installed on the servers according to a manufacturer’s installation instructions;

however, compatibility validation with Windows Server 2008 R2 should be conducted as

outlined in Chapter 17, “Compatibility Testing.”

After the software applications have been installed, representative users from the different

company departments could be brought into the lab to put the applications through their

paces. These users will be best able to do what they normally do in the lab environment

to ensure that their requirements will be met by the new configuration. Areas that don’t

ptg

meet their expectations should be recorded and identified as either “showstoppers” that

need to be addressed immediately or issues that won’t harm the implementation plan.

Results of the Lab Testing Environment

In addition to the valuable learning that takes place, a number of other things come out

of the lab testing process. If time permits, and there is room in the budget, a variety of

documents can be produced to facilitate the pilot and implementation process. Another

key result of the lab is hard evidence of the accuracy and completeness of the design and

migration documents.

Some of the documents that can be created will assist the deployment team during the

migration process. One key document is the “as built” document, which provides a snap-

shot of the key configuration details of the primary servers that have been configured and

tested. Whereas the design document outlines many of the key configuration details, the

“as built” document contains actual screenshots of the server configurations as well as the

output from the Windows Server 2008 R2 Computer Management administrative tool that

provides important details, such as physical and logical disk configuration, system

memory and processor information, services installed and in use on the system, and so on.

Another important document is the disaster recovery document (or DR document). This

document should outline exactly which types of failures were tested and the process for

rectifying these situations. Keep in mind that a complete disaster recovery plan should

include offsite data and application access, so the DR document that comes out of the

prototype phase will, in most cases, be more of a hardware failure document that discusses

how to replace failed components, such as hard drives or power supplies, and how to

restore the server configuration from tape backup or restore data sets.

The Pilot Phase: Validating the Plan to a Limited Number of Users

75

If you need to implement multiple servers in the pilot and implementation phases, you

can document checklists for the step-by-step processes in the prototype phase. Bear in

mind that creating step-by-step documents takes a great deal of time (and paper!), and a

change in process requires drastic changes to these documents. Typically, creating a step-

by-step “recipe” for server builds is not worth the time unless lower-level resources need to

build a large number in a short period of time.

2

When the testing is complete, the migration plan should be revisited to make sure that

the timeline and milestones are still accurate. Ideally, there should be no major surprises

during the prototype phase, but adjustments might be needed to the migration plan to

ensure the success of the project.

Depending on the time frame for the pilot and implementation phases, the hardware and

software that will be needed for the full implementation might be ordered at this point.

As the cost of server hardware has decreased over the past several years, many companies

“overspec” the hardware they think they need, and they might determine during the

prototype phase that lesser amounts of RAM or fewer processors will still exceed the needs

of the technologies to be implemented, so the hardware requirements might change.

The Pilot Phase: Validating the Plan to a Limited

ptg

Number of Users

Now that the prototype phase has been completed, the deployment team will be raring to

go and have hands-on experience with all the new technologies to be implemented. The

process documented in the migration document and migration plan will have been tested

in the lab environment as completely as practical, and documentation detailing the steps

to be followed during the pilot implementation will be at hand.

Although the pilot process will vary in complexity based on the extent of the changes to be

made to the network infrastructure, the process should be well documented at this point.

It is important to identify the first group of users who will be moved to the new Windows

Server 2008 R2 environment. Users with a higher tolerance for pain are a better choice

than the key stakeholders, for the most part.

NOTE

In many organizations, the CEO, CIO, VP of sales, or other key executives might want to

be part of the initial pilot rollout; however, we suggest not making these individuals

part of the initial rollout. These individuals typically have the most complex user config-

uration with the lowest tolerance for interruption of network services. Users in the pro-

duction environment with simpler needs can be used for the initial pilot. If necessary,

create a prepilot phase so that the senior executives can be part of the official pilot

phase, but don’t make the challenges of pilot testing more difficult by starting with

users who have the most complex needs.

76

CHAPTER 2

Planning, Prototyping, Migrating, and Deploying Windows Server 2008

R2 Best Practices

A rollback strategy should be clarified, just in case.

Test the disaster recovery and redundancy capabilities thoroughly at this point with live

data but a small user group to make sure everything works as advertised.

Migration processes can be fine-tuned during this process, and time estimates can be

nailed down.

The First Server in the Pilot

The pilot phase is begun when the first Windows Server 2008 R2 server accessed by users

is implemented in the production environment. Dependent on the scope of the migration

project, this first server might be a simple application server running Terminal Services or

Windows SharePoint Services, or the first server might be an Active Directory domain

controller.

Just as in the prototype phase, the testing to be conducted in the pilot phase is to verify

successful access to the server or application services the system provides. One of the best

ways to validate functionality is to take the test sequences used in the prototype phase

and repeat the test steps in the pilot production environment.

The major difference between the prototype and pilot phases is interconnectivity and

enterprisewide compatibility. In many lab-based prototype phases, the testing is isolated to

ptg

clean system configurations or homogeneous system configurations; however, in a pilot