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.
