ptg6432687 60 2 Best Practices at Planning, Prototyping, Migrating, and Deploying Windows Server 2008 Hyper-V . Documentation Required from Prototype . Pilot Phase(s) Detailed . Migration/Upgrade Detailed . Support Phase Detailed . Support Documentation Detailed 9. Budget Estimate . Labor Costs for Prototype Phase . Labor Costs for Pilot Phase . Labor Costs for Migration/Upgrade Phase . Labor Costs for Support Phase . Costs for Training 10. Project Schedule The Executive Summary Section The executive summary should set the stage and prepare the audience for what the docu- ment will contain, and it should be concise. It should outline, at the highest level, the scope of the work. Ideally, the executive summary also positions the document in the decision-making process and clarifies that approvals of the design are required to move forward. The Goals and Objectives Section The goals and objectives section might seem redundant because the design documents documented the objectives in great detail, but it is important to consider which specific goals and objectives are important to the success of the migration project that might not have been included in the design document. For example, although the design document outlined what the final server configuration will look like, it might not have outlined the tools needed to migrate key user data or the order that physical servers will be migrated to virtual servers. So, the goals and objectives in the migration document will be very process specific. The Background Section A summary of the migration-specific decisions should be provided to answer questions such as “Why are we doing it that way?” because there is always a variety of ways to convert a physical server to a virtual server session, such as using tools provided by Microsoft, using third-party tools, or rebuilding a server from scratch in a virtual environ- ment. Because a number of conversations will have taken place during the planning phase to compare the merits of one method versus another, it is worth summarizing them early in the document for anyone who wasn’t involved in those conversations. Download at www.wowebook.com ptg6432687 61 The Migration Planning Phase: Documenting the Process for Migration The Risks and Assumptions Section Risks pertaining to the phases of the migration should be detailed, and typically are more specific than in the design document. For example, a risk of the prototype phase might be that the hardware available won’t perform adequately and needs to be upgraded. Monitoring, virus protection, or backup software might not meet the requirements of the design document and therefore need upgrading. Custom-designed applications or applica- tions that may direct calls to hardware devices might turn out not to work properly in a virtual environment. The Roles and Responsibilities Section In the roles and responsibilities section, the teams that will do the work should be identi- fied in detail. If an outside company will be performing portions of the work, you should document which tasks it will be responsible for and which ones internal resources will take ownership of. The Timeline and Milestones Section Specific target dates can be listed, and should be available directly from the project sched- ule already created. This summary can prove very helpful to executives and managers, whereas the Gantt chart contains too much information. Constraints that were identified in the discovery process need to be kept in mind here because there might be important dates (such as the end of the fiscal year), seasonal demands on the company that black out certain date ranges, and key company events or holidays. Again, be aware of other large projects going on in your environment that might impact your timeline. There’s no point trying to deploy new servers on the same weekend that the data center will be powered off for facility upgrades. The Training Plan Section It is useful during the planning of any upgrade to examine the skill sets of the people who will be performing the upgrade and managing the new environment to see whether any gaps need to be filled with training. Often, training will happen during the prototype testing process in a hands-on fashion for the project team with the alternate choice being classroom-style training, often provided by an outside company. Also ask yourself whether the end users will require training to use new client-side tools being installed during a parallel application upgrade process. Also pay attention to how the new environment will integrate into existing systems such as backup or monitoring. Determine whether those groups will need any training specific to interacting with the new virtual servers. The Migration Process Section The project schedule Gantt chart line items should be included and expanded upon so that it is clear to the resources doing the work what is expected of them. The information does not need to be on the level of step-by-step instructions, but it should clarify the process and results expected from each task. For example, the Gantt chart might indicate that a Windows 2008 server needs to be configured; and in the migration document, information would be added about how the hard drives are to be configured, how virtual network segments are to be connected to physical segments, and which additional appli- cations (virus protection, tape backup, network management) need to be installed. 2 Download at www.wowebook.com ptg6432687 62 2 Best Practices at Planning, Prototyping, Migrating, and Deploying Windows Server 2008 Hyper-V If the Gantt chart lists a task of, for example, “Configure and web services access,” the migration document gives a similar level of detail: Which image should be used to config- ure the base system configuration, which additional applications should be loaded, how is the system to be locked down, and what testing process should be followed (is it scripted or will an administrator perform the testing)? Documentation also should be described in more detail. The Gantt chart might simply list “Create as-built documents,” with as built defined as “document containing key server configuration information and screenshots so that a knowledgeable resource can rebuild the system from scratch.” Sign-off conditions for the prototype phase are important and should be included. Who 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? 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 Hyper-V infrastructure is fully in place. If you are using an outside consulting firm for assistance in the design and implementation, 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 docu- ments should be included to help the technical writers make sure the documents are satis- factory. 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, and 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, too, if tasks can occur more quickly than anticipated. Often, the imple- mentation costs can be reduced by keeping an eye on ways to improve the process during the prototype and pilot phases. Download at www.wowebook.com ptg6432687 63 The Prototype Phase: Creating and Testing the Plan The Project Plan 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 about each step of the project plan, as needed. Certain very complex tasks are represented with one line on the project plan, such as “Configure Hyper-V Host #1,” but 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 will 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 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, make them 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 2 Download at www.wowebook.com ptg6432687 64 2 Best Practices at Planning, Prototyping, Migrating, and Deploying Windows Server 2008 Hyper-V should clearly outline the components of the lab and which applications and processes should be tested. A typical environment will consist of an initial Windows 2008 host server required for the implementation, network switches, and sample physical servers that will be converted 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 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 2008 Hyper-V environment are many, and include testing application updates, upgrades, and patches and having hardware avail- able 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 a test server. Applications should be installed on the servers according to a manufacturer’s installation instructions; in addi- tion, however, compatibility validation with Hyper-V virtualization 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 docu- ments 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 and contains the output from the Hyper-V Administration tool, which 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 Download at www.wowebook.com ptg6432687 65 The Pilot Phase: Validating the Plan on an Initial Set of Servers discusses how to replace failed components, such as hard drives and 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 task-focused resources need to build a large number in a short period of time. When the testing is complete, revisit the migration plan to confirm that the timeline and milestones are still accurate. Ideally, there should be no major surprises during the proto- type 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. Because the cost of server hardware has decreased over the past several years, many companies “over-spec” 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 on an Initial Set of Servers Now that the prototype phase has been completed, the deployment team is raring to go and gain hands-on experience migrating servers to virtual sessions. The process docu- mented 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 on 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 servers that will be moved to the new Windows 2008 Hyper-V environment. Systems that have redundancy throughout the environment (domain controllers, DNS servers) are a better choice for initial migration than highly critical business application servers that have no existing failover or redun- dancy configurations. 2 Download at www.wowebook.com ptg6432687 66 2 Best Practices at Planning, Prototyping, Migrating, and Deploying Windows Server 2008 Hyper-V NOTE In many virtualization projects, a critical business application may be a good opera- tional candidate to be virtualized if the hardware the system is running on is having problems and evacuating the physical hardware to a virtual system can alleviate exist- ing physical system problems. However, be ver y careful in migrating a critical applica- tion first. Consider migrating a couple of simple servers to a virtualized state, so that you can get familiar with managing, monitoring, and administering the simple server configurations first. Then schedule the migration of the critical application server. A rollback strategy should be clarified, just in case. Test the disaster-recovery and redundancy capabilities thoroughly at this point with live data but on a limited number of servers to make sure everything works as expected. 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 begins when the first physical server is migrated to a virtual guest session on Windows 2008 Hyper-V and users access the application on the virtual server in the production environment. Depending on the scope of the migration project, this first server might be a simple web server or a SharePoint site, 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 virtual session 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 clean system configurations or homogeneous system configurations. In a pilot production environment, however, the virtual server session is live in a full production environment. It is the validation that the new setup works with existing users, servers, and systems. Rolling Out the Pilot Phase The pilot phase is usually rolled out in subphases, with each subphase growing in number of servers migrated and the distribution of host servers throughout the organization. Number of Migrated Servers The whole purpose of the pilot phase is to migrate servers one by one from physical to virtual guest sessions to validate that prototype and test assumptions were accurate and that they can be successful in the production environment. An initial three to five servers are first to be migrated. These servers test basic migration processes and Hyper-V configu- rations. Download at www.wowebook.com ptg6432687 67 The Pilot Phase: Validating the Plan on an Initial Set of Servers After successful basic testing, the pilot server group can grow to 5%, then to 10%, and on to 20% of the servers planned for migration. This phased rollout will help the migration team test compatibility, connectivity, and communications with existing systems, while working with a manageable group of systems that won’t overwhelm the administrators during the pilot and migration process. The pilot phase is also a time when administrators build the knowledge base of problems that occur during the migration process. Thus, if or when problems occur again (possibly in the full rollout phase), lessons have been learned and workarounds already created to resolve stumbling blocks. Application Complexity of Pilot Migrations In addition to expanding the scope of the pilot phase by sheer number, selecting servers that have different application-usage requirements can provide a level of complexity across server configuration. Application compatibility and operation are critical to the administrator’s experience during the migration process. Often, administrators won’t mind if something runs a little slower during the migration process or that a new process takes a while to learn. However, end users will get upset if the applications they require and depend on each day to get their job done are offline, data is lost due to system instability, or the application just won’t work. So, testing applications is critical in the early pilot phase of the project. Geographical Diversity of Pilot Servers The pilot server group should eventually include servers geographically distributed throughout the organization. It is important to start the pilot phase with servers that 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 of systems. Before the pilot is considered complete, however, servers in remote sites should be migrated and tested to ensure remote users or branch office users still have access to migrated servers in the new virtualized networking environment. Fixing Problems in the Pilot Phase No matter how much planning and testing is 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, and even though the prototype lab testing and pilot phases have taken place, problems might recur in the postpilot phases, and any documented information about how problems were resolved or configurations made to resolve problems in the pilot 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 succeeds. 2 Download at www.wowebook.com ptg6432687 68 2 Best Practices at Planning, Prototyping, Migrating, and Deploying Windows Server 2008 Hyper-V The Migration/Implementation Phase: Conducting the Migration or Installation By this point in the project, more than 20% of the servers flagged for migration should have been converted and tested in the pilot phase, applications thoroughly tested, admin- istrators and support personnel trained, and common problem resolution clearly docu- mented so that the organization can proceed with the migration of the balance of the servers identified for virtualization. Verifying End-User Satisfaction A critical task you can complete at this point in the project a check of end-user satisfac- tion. You want to make sure that users are not experiencing any problems access their applications and that server performance hasn’t diminished. You also want to confirm that accessibility is not limited, questions are answered, problems are resolved, and most important, users are being made aware that IT is interested in their feedback during the backend migration of server systems. Of course, this backend migration should not nega- tively impact the users at all, but it’s worth checking to make sure. Not only does this phase of the project focus on the sheer rollout of the technology, it is also the key public relations and communications phase of the project. Make sure the user community gets to input their experiences in the process. Supporting the New Virtualized Environment Before the last servers are rolled into the new virtualized environment, besides planning the project-completion party you need to allocate time to verify the ongoing support and maintenance of the new environment. This step not only includes doing regular backups of the new servers, but also performing regular maintenance of the virtual host server and guest sessions (see Chapter 6, “Managing, Administering, and Maintaining Hyper-V Host Services”). Disaster recovery and failover should be implemented because there are now fewer servers hosting multiple application systems (covered in detail in Chapter 12, “Application-Level Failover and Disaster Recovery in a Hyper-V Environment”). You also want to tune and optimize the new Hyper-V environment (see Chapter 7, “Optimizing the Hyper-V Host Server and Guest Sessions”). 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, implementing new stretched clusters across a WAN, adding disk-to-disk-to-tape backup and recovery procedures, and the like. If you have a lab still in place, use it to test these additional services. 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 Download at www.wowebook.com ptg6432687 69 Best Practices planning a server virtualization implementation, it is important to first understand the goals for the implementation, and not only the 50,000-foot high-level goals, but 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 and can guide the group through key decision-making areas. Now all this information needs to be documented in the design document so that the details are clear, and some initial esti- mates 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 time- line 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 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 4 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 Hyper-V. 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. 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. 2 Download at www.wowebook.com . First Server in the Pilot The pilot phase begins when the first physical server is migrated to a virtual guest session on Windows 2008 Hyper -V and users access the application on the virtual server. Windows 2008 Hyper -V environment are many, and include testing application updates, upgrades, and patches and having hardware avail- able for replacement of failed components in the production environment. Real. ptg6432687 60 2 Best Practices at Planning, Prototyping, Migrating, and Deploying Windows Server 2008 Hyper -V . Documentation Required from Prototype . Pilot Phase(s) Detailed . Migration/Upgrade