Read Windows Server 2008 R2 Unleashed Online
Authors: Noel Morimoto
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
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
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
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