Windows Server 2008 R2 Unleashed (24 page)

production environment, the new technology is integrated with old technology. It is the

validation that the new setup works with existing users, servers, and systems, and software

that is the added focus of the production pilot phase.

Rolling Out the Pilot Phase

The pilot phase is usually rolled out in subphases, with each subphase growing in number

of users affected, uses of system technology by the pilot users, and the distribution of

users throughout the organization.

Quantity of Pilot Users

The whole purpose of the pilot phase is to slowly roll out users throughout the organiza-

tion to validate that prototype and test assumptions were accurate and that they can be

successful in the production environment. An initial group of 5 to 10 pilot users (typically

members of the IT department overseeing and managing the migration) are first to be

migrated. These users test basic functionality.

After successful basic testing, the pilot users group can grow to 1%, then to 3%, on to 5%,

and finally to 10% of the user base in the organization. This phased rollout will help the

migration team test compatibility, connectivity, and communications with existing

systems, while working with a manageable group of users that won’t overwhelm the help

desk services in place during the pilot and migration process.

The pilot phase is also a time when help desk and migration support personnel build the

knowledge base of problems that occur during the migration process so that if or when

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

77

problems occur again (possibly in the full rollout phase of the product), lessons have been

learned and workarounds already created to resolve stumbling blocks.

Application Complexity of Pilot Users

In addition to expanding the scope of the pilot phase by sheer quantity, selecting users

who have different application usage requirements can provide a level of complexity

2

across software platforms. Application compatibility and operation are critical to the end-

user experience during the migration process. Often, users won’t mind if something runs a

little slower during the migration process or that a new process takes a while to learn;

however, users will get upset if the applications they require and depend on each day to

get their job done lock up while they use the application, data is lost due to system insta-

bility, or the application just won’t work. So testing applications is critical in the early

pilot phase of the project.

Role Complexity of Pilot Users

Pilot users should also be drawn from various roles throughout an organization. In many

migrations, all pilot users are tested from a single department using just a single set of

applications, and it isn’t until the full migration process that a feature or function that is

critical to everyone in the organization (except the pilot group users’ department) doesn’t

ptg

work. An example might be a specific financial trading application, a proprietary health-

care tracking application, or a critical sales force automation remote access tool that causes

the entire project to come to a halt far into the full rollout phase.

Geographical Diversity of Pilot Users

The pilot group should eventually include members geographically distributed throughout

the organization. It is important to start the pilot phase with a set of users who are local

to the IT or help desk operation so that initial pilot support can be done in person or

directly with the initial pilot group. Before the pilot is considered complete, however,

users from remote sites should be tested to ensure their user experience to the new

networking environment hasn’t been negatively affected.

Fixing Problems in the Pilot Phase

No matter how much planning and testing are conducted in the earlier phases of the

project, problems always crop up in the pilot phase of the project. It is important to have

the prototype lab still intact so that any outstanding problems can be re-created in the

lab, tested, and resolved to be tested in the pilot production phase again.

Documenting the Results of the Pilot

After the pilot, it is important to document the results. Even with the extensive discovery

and design work, as well as the prototype lab testing and pilot phases that have taken

place, problems might reoccur in the postpilot phases, and any documented information

on how problems were resolved or configurations made to resolve problems in the pilot

78

CHAPTER 2

Planning, Prototyping, Migrating, and Deploying Windows Server 2008

R2 Best Practices

phase will help simplify the resolution in future phases. If you take some extra time to

give attention to the pilot users, you can fine-tune the solution to make sure the full

implementation is a success.

The Migration/Implementation Phase: Conducting

the Migration or Installation

By this point in the project, more than 10% of the organization’s users should have been

rolled out and tested in the pilot phase, applications thoroughly tested, help desk and

support personnel trained, and common problem resolution clearly documented so that

the organization can proceed with the migration and installation throughout the rest of

the organization.

Verifying End-User Satisfaction

A critical task that can be conducted at this point in the project is to conduct a check-

point for end-user satisfaction, making sure that users are getting their systems, applica-

tions, or functionality upgraded; questions are answered; problems are resolved; and,

most important, users are being made aware of the benefits and improvements of the

new environment.

ptg

Not only does this phase of the project focus on the sheer rollout of the technology, but it

is also the key public relations and communications phase of the project. Make sure the

user community gets the training and support it needs throughout the process.

Plan on issues arising that will need support for several days after each department or user

group is upgraded.

Don’t forget the special users with unique requirements and remote users because they

will require additional support.

Supporting the New Windows Server 2008 R2 Environment

Before the last users are rolled into the new networking environment, besides planning

the project completion party, you need to allocate time to ensure the ongoing support and

maintenance of the new environment is being conducted. This step not only includes

doing regular backups of the new servers (covered in detail in Chapter 30, “Backing Up the

Windows Server 2008 R2 Environment”), but also includes planning for regular mainte-

nance (Chapter 20, “Windows Server 2008 R2 Management and Maintenance Practices”),

monitoring (Chapter 23, “Integrating System Center Operations Manager 2007 R2 with

Windows Server 2008 R2”), and tuning and optimization (Chapter 34, “Capacity Analysis

and Performance Optimization”) of the new Windows Server 2008 R2 environment.

Now is the time to begin planning for some of the wish-list items that didn’t make sense

to include in the initial migration—for example, a new antiviral solution, knowledge-

management solutions, enhanced security, and so on.

If you have a lab still in place, use it for testing patches and software updates.

Summary

79

Summary

One analogy used in this chapter is that of building a house. Although this analogy

doesn’t stand up to intense scrutiny, the similarities are helpful. When an organization is

planning a Windows Server 2008 R2 implementation, it is important to first understand

the goals for the implementation, and not only the “50,000-foot” high-level goals, but

2

also the “10,000-foot” departmental and “1,000-foot” IT staff goals. Then, it is important

to more fully understand the environment that will serve as the foundation for the

upgrade. Whether this work is performed by external resources or by internal resources, a

great deal will be learned about what is really in place, and where there might be areas of

risk or exposure. Collaboration sessions with experienced and effective leadership can

then educate the stakeholders and deployment resources about the technologies to be

implemented as well as guide the group through the key decisions that need to be made.

Now all this information needs to be documented in the design document so that the

details are clear, and some initial estimates for the resources required, timeline, and budget

can be set. This document serves as a blueprint of sorts, and defines in detail what the

“house” will look like when it is built. When all the stakeholders agree that this is exactly

what they want to see, and the timeline and budget are in line, the migration document

can be produced.

The migration document includes a detailed project plan that provides the tasks that need

ptg

to take place to produce the results detailed in the design document. The project plan

should not go into step-by-step detail describing how to build each server, but should stick

to summary tasks from four hours to a day or more in duration. The migration document

then provides a narrative of the project plan and supplies additional information pertain-

ing to goals, resources, risks, and deliverables, as well as budgetary information accurate in

the 10% to 20% range.

Based on these documents, the organization can now proceed with building the solution

in a lab environment and testing the proposed design with actual company data and

resources involved. The results of the testing might require modifications to the migration

document, and will prepare the deployment team for live implementation. Ideally, a pilot

phase with a limited, noncritical group of users will occur to fine-tune the live implemen-

tation process and put in place key technologies and Windows Server 2008 R2. Now the

remainder of the implementation process should proceed with a minimum of surprises,

and the result will meet the expectations set in the design phase and verified during the

prototype and pilot phases.

Even the support phase has been considered, and during this phase, the “icing on the

cake” can be applied as appropriate.

Although this process might seem complex, it can be molded to fit all different sizes of

projects and will yield better results.

80

CHAPTER 2

Planning, Prototyping, Migrating, and Deploying Windows Server 2008

R2 Best Practices

Best Practices

The following are best practices from this chapter:

. Use a migration methodology consisting of discovery, design, testing, and imple-

mentation phases to meet the needs of your organization.

. Fully understand the business and technical goals and objectives of the upgrade and

the breadth and scope of benefits the implementation will provide before imple-

menting a new application or upgrade.

. Create a scope of work detailing the Windows Server 2008 R2 network functionality,

data management, information access, and application hosting.

. Define high-level organizational goals.

. Define departmental goals.

. Determine which components and capabilities of the network are most important

and how they contribute to or hinder the goals expressed by the different units.

. Clearly define the technical goals of the project on different levels (“50,000-foot,”

“10,000-foot,” “1,000-foot,” and so on).

ptg

The Discovery Phase

. Review and evaluate the existing environment to make sure the network foundation

in place will support the new Windows Server 2008 R2 environment.

. Make sure the existing environment is configured the way you think it is, and iden-

tify existing areas of exposure or weakness in the network.

. Define the current network stability and performance measurements and operation.

. Use external partners to produce more thorough results due to their extensive expe-

rience with network reviews and analysis and predict the problems that can emerge

midway through a project and become “showstoppers.”

. Start the discovery process with onsite interviews.

. Review and evaluate every affected device and application to help determine its role

in the new environment.

. Maintain and protect database information that is critical to an organization on a

regular basis.

. Determine where data resides, what file stores and databases are out there, how the

data is maintained, and whether it is safe.

Best Practices

81

The Design Phase

. Create a design document including the salient points of the discussion, the reasons

the project is being invested in, the scope of the project, and the details of what the

results will look like.

. Create a migration document providing the road map showing how the end state

2

will be reached.

. Use a consultant with hands-on experience designing and implementing Windows

Server 2008 R2 to provide leadership through this process.

. Determine what hardware and software will be needed for the migration.

. Determine how many server software licenses will be required to more accurately