Planning

Article
03/05/2008

The Infrastructure Remediation feature team completes most of its work during the Planning Phase. It is also one of the first teams to be put in place during the project, because its deliverables—especially its deliverables from the Planning Phase—affect the Planning and Developing Phases of the computer deployment.

Information obtained during the Planning Phase helps other teams and role clusters create a test environment that most closely resembles the production environment. For this, the Infrastructure Remediation feature team will work closely with the Test feature team, because the Test feature team is responsible for all testing throughout the implementation of the solution. The most important aspect of testing is pilot testing, because it is the last stage of testing before the actual deployment. The pilot test duplicates the actual production deployment as closely as possible and is used to validate each and every portion of the overall solution before its operation in the production environment. To support the testing of the most crucial aspects of the solution, the pilot environment will ideally contain an actual portion of the production environment and include as many factors representing this environment as possible. For more information about a pilot test, see the Test Feature Team Guide.

Figure 3 illustrates the primary tasks that occur during the Planning Phase.

Figure 3. Planning to support deployment and operation

Roles and Responsibilities

Table 3 lists the focus areas for the different role clusters in creating the plan for supporting deployment and operation.

Table 3. Roles and Responsibilities During the Planning Phase

Role Cluster	Focus
Product Management	Business requirements analysis Communications plan
Program Management	Project plan Project schedule Budget
Development	Technology evaluation Logical and physical design Deployment plan and schedule Deployment estimates
User Experience	Usage scenarios and use cases User requirements Localization and accessibility requirements User documentation, training plan, and schedule for usability testing User documentation Training
Test	Design evaluation Test methodology Testing requirements Test plan and schedule
Release Management	Design evaluation Operations requirements Pilot test and deployment plan and schedule

Situation Analysis

The Planning Phase of any deployment project requires gathering information to help understand the existing environment and modify it as required to ensure a successful deployment. When undertaking a project of this size, the changes will have far-reaching effects for users. The goal is to minimize disruptions to business while completing the process as quickly as possible.

Answers to the following questions drive the Planning Phase:

How many computers (client and portable computers) are in the organization?
What is the ratio of computers to users? Are there more computers than users, or are there more users than computers?
Are there possibilities for rationalization or the reduction of resources—computers, applications, and software—in this project? Effective rationalization reduces the level of effort required for a successful deployment.
How many computers can be upgraded without requiring additional hardware? How many will require hardware upgrades? Will there be a volume purchase of new systems?
Of the existing application set used in the organization, how many will be upgraded to newer versions? For example, many organizations choose to implement a new version of office productivity software at the same time as the upgrade of an operating system.
How fast can the migration be completed using the existing infrastructure?
If changes to the existing infrastructure are required, where are the largest returns gained by investing in additional resources?
Can this information help other current or future projects?
Is this a one-time gathering of infrastructure information, or can this information be reused?

Gather Inventories

To answer the questions of the Planning Phase, the following information is necessary:

Structural description of the business. This information outlines the structure of the business, including a geographical map with the location of each of the business’ offices (if there is more than one) and the number of users in each office. In addition, this information should include an organizational chart of the business that outlines each functional area and the number of users it contains. It is also useful to include other organizational information, such as the vision and mission of the business. The latter is useful for bringing outside consultants rapidly up to date on the nature of the business for the organization.
Hardware and software inventories. This information should take the form of a diagram and should be as current as possible. It can begin with a geographic map outlining the number and function of computers per site. In addition, it should include specific information about each computer. Valid information includes:
- Computer make and model.
- CPU specifications.
- Amount of RAM.
- Disk partitions and amount of free disk space.
- Number of user profiles on the computer, with the size of each profile and information on when it was last accessed.
- List of the applications on the computer, with information about when they were last accessed and by whom.
- Additional information such as year of purchase, time remaining on the warranty, or the support plan.
- Multilingual requirements, if any.
  
  Note In environments in which this information is not readily available, it may take considerable time to obtain the information. This time factor should be included in the project plan, because it will affect the timeline of the project.
Network infrastructure diagram. This information should take the form of a network diagram and be as current as possible. This diagram often includes a geographical network map outlining local area network (LAN) and wide area network (WAN) links as well as speeds and available bandwidth. This diagram should also include remote access connections and the number of remote users and their location. If common traffic patterns, such as peak loads, are identifiable, they should also be included. Finally, this diagram should include the network’s addressing scheme.
Service infrastructure documentation. This information should take the form of a server diagram and be as current as possible. This diagram should include a description of each server located in any site and the server’s function and role in the overall network. In addition, it should include information about the following service types:
- Authentication and other security services
- Collaboration services, such as e-mail, team workspaces, and instant messaging
- File and print services, including server size and available disk space
- Replication services currently in use as much for authentication as for file services
Management infrastructure documentation. This information should take the form of a diagram outlining how network systems are managed within the organization and should be as current as possible. This should include specific information about the following:
- Client computer management, including portable and remote computers
- Management toolkit outlining the application names, the number of servers involved in this management toolkit, and their role and capacity for growth
- Technical support structure outlining the roles and responsibilities of the staff involved in computer management and computer support
- Standards and procedures currently in use for the management of computers, ideally including information such as existing current system builds and build methodology as well as the application portfolio management and usage practices
Application Compatibility Toolkit (ACT) database. This database will greatly assist in the preparation of the inventory necessary for performing the deployment. All information obtained when executing this tool is stored in a database. This database includes not only application-specific data but also basic information concerning the computer hardware. In addition, it provides useful information about the compatibility of applications with both Windows XP with Service Pack 2 (SP2) and Windows Vista. This database can double as an inventory tool if no other automated tool is in place. If readers must rely on this tool for inventory, see the Application Compatibility Feature Team Guide for specific examples of the types of queries to run against this database and information about the tool.
Help desk issues list. An existing list of the current issues related to operating systems and computer builds is also a valuable asset in the preparation of a deployment strategy for BDD 2007. Identifying these issues and repairing as many as possible during the preparation of the new operating system build will greatly assist in gaining the positive outlook the project will receive from users during the deployment.

Important Involving the help desk early in the process helps both the help desk and users during the deployment. Having the list of known issues communicated to the organization helps reduce the additional help desk costs associated with the computer deployment.

Without these current diagrams and documented information, it is impossible to understand how the various pieces of the BDD 2007 project interact and how they can affect the delivery of the solution. Several methods are available to collect this information. Ideally, an automated system management tool will be in place and will help gather this information. If not, the Infrastructure Remediation feature team must use other methods or estimate these values.

Note Estimated values will not support proper budgeting and final delivery estimates for the project. At some point in time, the project must have real data and real values; otherwise, it will not succeed.

Perform Initial Inventory Analysis

A budget and a project plan are often the first deliverables created during the Planning Phase of the desktop deployment. This delivery is the responsibility of the plan, build, and deploy teams, but it is the responsibility of the Infrastructure Remediation feature team to provide the best information available on the following:

The number of computers being deployed
The number of computers requiring upgrades to existing hardware
The number of computers that must be replaced before the new computer image is deployed

During deployment projects of this type, organizations often upgrade several systems and may even choose to replace some of the more obsolete computers. If such cases, the Infrastructure Remediation feature team might decide to replace hardware during the migration. While doing so can affect both the budget and the project plan timeline, it makes more sense to update at this time than to delay replacing a significant potion of computers, which will render the project incomplete.

Important When determining the minimum computer hardware requirements for the organization, start with the base image requirements plus any applications that will run concurrently on each computer. Then, factor in room for growth over the next three or four years, depending on the hardware life cycle.

When determining the computer requirements, be sure that all hardware is included on the HCL. (For information about the HCL, see the “Education and References” section of this guide.) Also, be sure to specify any additional network minimum requirements or configuration changes needed. This information includes additional server hardware to manage the images during the deployment and to store user information before and after the upgrade process.

It will also be important to review the application portfolio and determine which applications will be upgraded, which will be replaced, and which will be migrated in their existing version. Ideally, an application rationalization or reduction will also be performed to reduce the amount of effort required for the deployment. It may be that some of the applications within the portfolio will not be able to operate on the target operating system and will require other remediation solutions. The Application Compatibility feature team delivers this application inventory as well as the list of incompatible applications and remediation procedures (if any) for the applications to be redeployed. It is the Infrastructure Remediation feature team’s responsibility to deliver the existing portfolio inventory and the number of installed applications.

Milestone: Inventories Are Completed

At this milestone, the inventories are complete, and some initial reports have been created. Table 4 describes the deliverables for this milestone.

Table 4. Deliverables During the Planning Phase

Deliverable ID	Description
Core Inventories and Infrastructure Diagrams	These documents serve to outline the structure of the current infrastructure and how the deployment will affect it.

Proposed Infrastructure Modifications

Two key tasks must be performed after the initial inventories and infrastructure documentation have been collected. The first is defining the scope of the deployment. The second is determining the infrastructure requirements for support of the deployment. If existing network services can provide this infrastructure, then the Infrastructure Remediation feature team will be in good shape; if not, the team must perform remediation tasks.

Define the Scope of the Deployment

The scope of the deployment is determined by the number of computers to be migrated and their location within the network infrastructure. The first task to complete in this activity is to determine what the computer hardware baseline for the deployment will be. Several computer standards are listed in the Plan, Build, and Deploy Guide. Depending on the organization’s application and business requirements, the specifications may or may not be appropriate. However, it is important to create specifications for the standard computers in the organization. These specifications should cover client computers and the portable computers.

In addition, accurate counts of applications and computers are needed to determine this scope. At this stage, the Infrastructure Remediation feature team should have a general idea of the scope of the deployment and now can use the information gathered in this phase to refine it as well as the objectives of the deployment. This information helps establish the project’s timeline and budget. Discovering additional costs later in the project can lead to extended deliverable dates and can result in unexpected delays or work stoppages. It is best to determine the number of computers or allow for it to help prevent unanticipated problems from occurring during project execution.

Note Involving IT Operations early in the deployment can reduce problems with managing existing or additional computers after the deployment is complete. For example, IT Operations would be better prepared to maintain the deployment if the department knew the future disposition of servers used during the deployment and could plan for it.

The Infrastructure Remediation feature team can deliver this solution in several ways. For example, the team can stage all systems in a custom staging area. Although doing so provides the most stable deployment solution, it does require a computer rotation and additional resources for carting the computers to and from users’ desks. The team can also perform in-place stand-alone installations or deployments to systems while they remain at users’ desks. This approach requires special procedures to ensure that the installation works properly in each situation and will also require more bandwidth, because it uses the production network for deployment.

In most situations, the Infrastructure Remediation feature team will discover that a single technician can manage the deployment of at least 20 computers per day and maybe more, given the right set of circumstances. This deployment rate will be mitigated by factors such as the physical proximity of the computers to be deployed, the complexity of the application set to deploy to the computer, the deployment process—Stand-alone installation, Refresh, or Replacement—and the accuracy of the inventory information for that computer. The latter—the computer’s installation profile—will be a crucial component that the Deployment feature team requires when actually performing deployments.

To determine initial scope, use a metric based on the following information:

The number of available technicians during the deployment
The availability of deployment resources
The number of computers in each deployment location
The deployment strategy to be used
The complexity of the applications to be reinstalled
The number of computers requiring either replacement or component upgrades

Note Computers requiring replacement or upgrades will take longer, because they must be physically modified. Computers that are ready for the new operating system will be faster to migrate, because no physical work must be performed on them.

Other parameters must be assessed to determine complete project scope, but the Infrastructure Remediation feature team is only responsible for two factors: the scope of the actual deployment and the scope of the modifications required in the current computer infrastructure to support a deployment of this type. “Appendix A: Taking Inventory of the Network” describes the initial process used to determine the inventory information required in support of the definition of the scope of deployment.

Determine Required Infrastructure Modifications

The actual deployment relies on several technologies for proper operation. Most of these are in the form of a file share somewhere on the network. In fact, three of the four main deployment server roles are simple file shares:

Deployment Server Role. This role is used to store all deployment information and toolkits to be used during the migration. It also stores operating system image files, including the required Microsoft Windows Preinstallation Environment (Windows PE) images.
User State Migration Server Role. This role is used to store user profiles either temporarily or permanently, depending on the selected approach. As computers are being deployed, existing user profiles are captured to this server role, and then drawn from this server to be restored to the updated computer.
Application Installation Server Role. This role is used to store the prepackaged installation files for the applications to be redeployed after the operating system has been replaced.
Windows DS. This role is not necessarily a file server role but very much resembles it, because it stores not only operating installation images but images for use by Windows DS. As such, it resembles a file share, because it includes information that may have to be reproduced in several locations. For more information about Windows DS, see the “Education and References” section of this guide.

Because most of the deployment components are file shares, a replication technology will be required in the event that more than one site is included in the infrastructure. Several methods can be used for replication. For example, the Infrastructure Remediation feature team can simply place all components on a portable server or hard disk and ship it from one location to the next during the deployment. Or, if a computer management infrastructure is already in place, the team can rely on existing server roles and use a replication technology to copy information from one location to the next as required.

Windows Server 2003 R2 offers an excellent replication mechanism if no other mechanism is present. The DFS Replication Service supports byte-level replication from location to location in either push or pull mechanisms, which means that the Infrastructure Remediation feature team can create a single distribution point from which master files are copied to all remote distribution servers. In addition, the DFS Replication Service can be used to create a pull mechanism to retrieve both existing operating system image captures (backups) and user profiles for permanent storage during the project. For more information about the DFS Replication Service, see the “Education and References” section in this guide.

Figure 4 illustrates the replication relationship among the deployment server roles. The Windows DS infrastructure, with the Pre-Boot eXecution Environment (PXE) boot service, is shown deployed in four sites. The DFS Replication Service manages replication among the sites, ensuring that all data and user state migration data is kept consistent among sites. Refer to the Lite Touch Installation Guide for more information about these utilities and their relationships.

Figure 4. Replication requirements in geographically dispersed deployments

In summary, the Infrastructure Remediation feature team must provide the following information to the plan, build, and deploy teams for the Planning Phase of the project:

Determination of how fast the computer deployment could be completed, given the current environment
Decision on where investments can be made to speed the deployment and on which investments provide the organization with the greatest value
Help in designing and planning a system management tool rollout into the organization if none exists and the organization decides to acquire this valuable asset moving forward
Assistance to the organization in laying a basic foundation to help evaluate, plan, and diagnose required network, server, client, or even application changes

Note A change-management plan and other needed operational plans are covered in greater detail in the MOF. For more information about MOF, see the “Education and References” section of this guide.

“Appendix B: Performing Infrastructure Remediation” describes the process used to determine the tasks required for infrastructure remediation in support of the deployment.

Create the Deployment Plan

A variety of infrastructure information is needed to help further define the deployment plan for the computer deployment. Available network bandwidth, availability of distribution servers, user usage profiling, and support for wireless or other nonstandard deployment communications mechanisms all provide valuable information for the deployment plan. Obtaining this information requires the participation of other teams—including the Application Management feature team, the Application Compatibility feature team, and the User State Migration feature team—across the organization. For this reason, it is important to have contributions from these teams during the Planning Phase.

The Infrastructure Remediation feature team may also consider creating a deployment back-out plan. This second plan can help alleviate the risks incurred in proceeding with the deployment in the event of unforeseen situations.

Collecting and providing this information are not just a one-time exercise. The tasks will evolve during and after the deployment. For example, IT Operations and help desk personnel will use this information daily as the deployment proceeds.

Help Desk

Each organization’s help desk tracks the frequency of help desk support calls. Of particular interest to the Deployment feature team is the number of operating system–specific calls the help desk gets. The User Experience Role Cluster should watch this metric closely and try to reduce the number of support calls through tasks such as user-awareness campaigns.

For example, one component of the user-awareness campaigns could involve tracking and publishing all known issues. This would require establishing a list of known issues at the beginning of the Stabilizing Phase of desktop deployment. The help desk can work with the Development Role Cluster to discover and resolve issues to better support users who might encounter problems later on.

In terms of remediation, a special portion of the help desk should be devoted to the deployment, fielding issues that are directly related to the deployment and providing immediate resolution of problems. Usually, this high-response state should last for a period of one month after deployment and act as a sort of warranty for the newly deployed computer.

Risk Analysis

Table 5 itemizes the labels the Infrastructure Remediation feature team should use when preparing a risk management chart. Complete information about each risk benefits the Program Management Role Cluster as it assesses risks and develops contingency plans.

Table 5. Risk Management Chart Structure

Label	Description
Identification (ID)	Risk identifier
Risk Statement	Potential problem description (condition and consequence)
Probability	Probability that the risk will become a problem (on a scale of 1 to 5, low to high)
Loss	Relative loss potential (dollar value on a scale of 1 to 10, low to high)
Exposure	Risk exposure (product of Probability times Loss)
Mitigation Approach	Action planned to mitigate risk
Contingency Plan	Action planned in response to risk occurring or its trigger
Trigger	Event or value that compels contingency implementation
Who	Person responsible for the action
Date	Date by which to finish

Table 6 lists a sample of the most common risks that can occur in a deployment of this type. These risks may or may not be an issue for this particular deployment. When managing risks, completely describe the risk, assigning it a probability, a relative loss, an exposure calculation, and a mitigation or contingency plan. It is also important to assign it a trigger event or value to help determine when the contingency plan for this risk must be initiated. A key to mitigating the risk is to assign a person, not a group, to the action and a specific date by which the action should be completed.

Table 6. Common Risk Examples

ID	Risk statement	Risk statement	Mitigation approach	Contingency plan
	Condition	Consequence
1	If the computer connection speed is not fast enough ...	...then the deployment will be slowed by the capacity of the switch.	Verify that the capacity of the switch and the amount of data that can be moved under load will satisfy the deployment requirements.	Upgrade or obtain a larger switch or blade for the deployment.
2	If the deployment server does not have a high-speed connection...	...then the deployment will be slowed by the capacity of the server network connection.	Verify that the server is connected using a gigabit fiber connection.	Obtain a gigabit connection for the deployment server to use for the deployment.
3	If deployment servers do not have extremely fast disks...	...then the deployment will be slowed by the disk input/output.	Verify that the disk performance will handle the number of computers.	Obtain faster disks or even storage area network disks for the deployment.
4	If the deployment servers do not have the capability to deploy all computers in the time window...	...then the Deployment feature team will not be able to complete the upgrade in the given time frame.	Obtain additional deployment servers that will scale to handle the amount of computers and complete within the window.	Obtain a large deployment time frame.
5	If the deployment causes disruption to the client environment...	...then this directly affects the clients’ productivity and may result in work loss.	Work to help ensure that no data is lost during the deployment and that the process does not take longer than expected.	Implement the deployment back-out plan.
6	If the computer does not meet the minimal memory, CPU, or hard disk requirements for the deployment...	...then the computer cannot be upgraded.	Verify through the inventory database that the computers meet the minimum criteria.	Upgrade or replace the computers that do not meet the minimum criteria.
7	If the discovery tool cannot access parts of the network because of security, lack of permissions, or lack of connectivity...	...then the Deployment feature team will not have a complete understanding of the environment.	Work with the appropriate network group to verify that appropriate access is granted and that all computer locations are covered.	None
8	If personnel do not understand or cannot interpolate the diagrams to identify risks...	...then the deployment may encounter unknown risks.	Work to have the appropriate, experienced, and trained personnel as part of the Deployment and Release Management feature teams.	Bring in outside resources to verify the environment.
9	If hardware (such as the source server or computer) fails during the deployment...	...then the Deployment feature team will not be able to complete the upgrade in the given time frame.	Work to have access to a replacement or backup hardware.	Include a much larger safety factor when planning scalability of the source servers.
10	If the parallel execution of the deployment does not occur...	...then the Deployment feature team will not be able to complete the upgrade in the given time frame.	Verify that adequate resources are available to complete the deployment in parallel.	Bring in extra resources to function as backup personnel.
11	If catastrophic problems occur...	...then the deployment will have to be rolled back to the original configuration.	Verify that the rollback process can be completed, and define the point of no return during the deployment.	None
12	If the network environment is unstable, causing unknown and unpredictable errors...	...then the stability of the deployment is at risk.	Verify that the network is stable before beginning the deployment.	Bring in known, stable network hardware to act as a lab.
13	If operation policies and procedures do not exist...	...then the deployment and back-out plans are at risk of causing data loss.	Verify that operation policies and procedures exist and are currently used by all personnel.	Implement operation policies and procedures.
14	If change management does not exist...	...then the integrity of the current and planned environments is at risk of becoming unstable.	Verify that a change-management process exists and is used by all personnel.	Implement a change-management process.
15	If the Release Management Role Cluster is not motivated to meet the required standards...	...then the completeness and level of effort required are not at the level they should be.	Work to have a cohesive team that is willing to put in the effort to get the job done.	Find a cohesive team that is willing to get the job done regardless.

Important The common risks sample chart shows a sample of the types of risks that may be encountered during infrastructure deployments. This chart should be a subset of a separate chart, listing all identified risks for the deployment. For example, if 200 risks have been identified, it is extremely unlikely that the Infrastructure Remediation feature team will be able to review these risks daily or even weekly. When the team is unable to review each risk, the risk’s significance is greatly lowered. However, if the team can create a top 10 or even top 20 risks chart, it will have a manageable list that can be reviewed daily or weekly at the project status meetings. The chart containing all risks is still valuable, because it will contain all risks, even those with a very low exposure to the project.

Woodgrove Research Example

To better illustrate the task at hand, the following example uses data collected from a network preparing for deployment.

The Desktop Systems group at Woodgrove Bank, a fictitious enterprise, is concerned about the coming deployment, because past deployments have failed to completely meet project objectives. The team members believe that much of this failure was because they had a poor understanding of their existing environment before the project began. They do not want to repeat the same mistakes this time around. Therefore, they want to make sure their initial inventories are as complete as possible.

Is this possible? The Deployment feature team proposes using a series of tools to create an inventory that is as complete as possible. Their first step is to ensure it understands the structure of the network. One way to do this is to make a diagram of the Woodgrove enterprise network and understand how it supports the overall Woodgrove business process. Figure 5 is a sample diagram that could be produced using a network discovery tool, or it could be drawn manually.

Figure 5. Woodgrove Bank

Woodgrove has approximately 17,000 users. To ensure that the bank has a complete inventory, the team members must use a series of tools to collect the information. They must also make sure they know where portable computers and unconnected or isolated systems are located, especially if the systems are in transit, to include them in the data-collection exercise.

Woodgrove uses an enterprise system management tool so that its inventory of client computers is fairly accurate. Portable computer users are another matter, so the Infrastructure Remediation feature team has decided to use logon scripts to collect information from portable computers as these users log on. After all this data is collected, the team will collate and consolidate the data into a single report that will be provided to other teams.

At the same time, the team will verify each server location to ensure that distribution servers will have the necessary capacity for support of the deployment. This information will be part of the inventory that will support the infrastructure remediation efforts.

After this information was collected, the Deployment feature team produced a series of diagrams that supported the analysis and design of the deployment project. These diagrams provided valuable information in support of the core decisions of the project, in particular:

Determining how quickly the desktop deployment could be completed, given the current environment.
Deciding where investments could be made to speed the deployment and which investments give the organization the greatest value.

To make these decisions, the team used the processes outlined in the appendices of this guide.

Milestone: Deployment Plan Approved

At this milestone, the inventories are complete, and some initial reports have been created. Table 7 describes the deliverables for this milestone.

Table 7. Milestone Deliverables

Deliverable ID	Description
Initial Architecture and Deployment Strategy Defined	These documents outline how the current infrastructure must be modified in support of the selected deployment strategy. They also describe the selected deployment strategy.