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
technologies 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 environment
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 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 workstations, 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 advantages 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.
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 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 snapshot
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.
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.
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.
