Solution Architecture

Article
03/05/2008

The technical issues for the team can be summarized in one question: “How do we upgrade all the computers in Woodgrove to Windows and the 2007 Office system in a cost-effective manner without losing data and with minimum impact to the user?” Several issues must be addressed in assembling the correct teams and starting the project so that it focuses on answering that one key question.

To make the project succeed, the team must:

Document the project’s business case. The sample Woodgrove Business Case provides a starting point for writing a business case for the project.
Take an inventory of the existing production computers to determine the installed application base and the types of hardware currently deployed.
Determine which applications can be redeployed on new systems, and start a process for packaging or scripting those applications so that they can be reinstalled quickly and consistently without user intervention.
Define a strategy for addressing applications that cannot be supported on the new platform.
Determine which types of hardware will be reused as part of the new computer deployment and which types might need to be retired.
Create an imaging process to produce a standard enterprise image of the computer to aid in configuration management and to speed deployments.
Establish a process for capturing the user data, settings, and preferences on the currently deployed systems and for restoring them on the newly deployed systems.
Provide a method for backing up the current computer before the redeployment.
Establish a network map of the client computers, servers, and other networking equipment to assist in planning for the deployments.
Provide an end-to-end process for the actual deployment of the new computers.
Create a plan for training users for the updated software.

While these tasks could be and often are treated as separate team projects, they are also highly interrelated. This solution treats these tasks as one project with communication among all groups to reduce the risk of some tasks being omitted.

A brief description that sets a baseline for how this solution addresses each general task follows in this guide. Additional details are provided in feature team guides associated with each task. Management, monitoring, communication, education, and planning across all these areas help ensure timely resolution of any issues that may arise. The majority of this document is focused on addressing how the various technical requirements are met and, through the use of milestones, how issues are identified in a timely fashion.

Process Overview

Figure 2 provides a high-level overview of the tasks that will be involved during the deployment process.

Figure 2. Overview of the deployment process

Inventory

The team uses the Application Compatibility Toolkit (ACT) to query each production computer and consolidate data at a central location that can then be imported in to a database. The ACT contains a small collector program that team members run on each production computer. Team members can include this program in logon scripts, or they can launch it from a Web page or file share. The program produces an inventory cabinet (.cab) file that is then sent to a central repository server that can consolidate the information from all the computers and generate reports and queries. This data can be stored in Microsoft SQL Server™ 2005, SQL Server 2005 Express Edition, or SQL Server 2000. After collecting the data, this tool can generate reports that provide information about:

Computer application inventory.
Applications’ compatibility with Windows.
Simple computer hardware information (memory, CPU, hard disk).

Teams can use this information to plan the other core areas. For example, they can use it to:

Decide which applications will require compatibility remediation planning.
Assist in prioritizing the packaging of applications based on volume or location.
Provide information on hardware that may need to be upgraded or replaced.

Application Installation Automation

To enhance the configuration management capabilities of the organization, it is essential that all applications be installed and configured in a known, documented, and consistent manner. To do this, teams must automate all application installations and configurations by using unattended or silent installation options whenever possible.

Several ways exist to automate or script application installation. This component of BDD 2007 provides general guidance on the various approaches to installing and configuring applications in the Application Management Feature Team Guide.

Moving Toward Software State Restore

The extension of automated inventory and automated application installation can be termed software state restore. The goal of software state restore is the automated identification of existing applications on client systems and subsequent deployment of those applications during desktop deployment. For some applications, this means deploying a newer version of the application where a new version is available and planned as a part of the deployment. In other cases, an existing version of the application is reinstalled to target desktops.

The elemental goals of a fully automated software state restore mechanism are to accurately identify existing applications, map those applications to an established database of supported applications, provide reporting capability for planning and development, and automate the installations of the applications on specific target systems as needed.

Many of the elements of software state restore are present in BDD 2007. For example, the collector in the ACT provides inventory capabilities to identify existing applications, and those applications can be deployed automatically as part of overall desktop deployment through separate scripted actions or through customization of Windows Setup.

Additional components and tools will be added to upcoming releases of BDD, but the Deployment feature team can begin planning and implementing individual elements of software state restore to facilitate application deployment before the availability of these additional tools. These elements include:

Inventory. Successful application deployment as part of overall desktop deployment requires an accurate inventory of existing applications. An aspect of the inventory process should include identification of which applications will be reinstalled as-is, which will be upgraded with updates, and which will be replaced with newer versions.
Approval. Existence of an application on a given computer does not imply that the application should be allowed on the system, whether for security, licensing, suitability, or other reasons. The Deployment feature team should work closely with users to validate and approve applications, and then implement a mechanism for tracking application approval.
Availability. To facilitate automated installation across the enterprise, applications must be available on the network. A structured network share hosting the application source files is one method of making applications available, but as the number of applications grows, so does the need for better tools for managing the applications outside the actual Deploying Phase. A managed applications database can fill the need for tracking applications in the source pool and can include key data such as compatibility information, required post-installation steps, and other issues related to the deployment of each application.
Deployment. The deployment methods and requirements of each application must be identified early in the Planning Phase to allow sufficient time for scripting or other tasks to support installation of the application. Information about deployment requirements and methods should be stored in the managed applications database.
Sign-off. Deployment of applications to target systems is not the culmination of the application deployment process. Rather, final stakeholder approval of application mapping and installation should be considered the final step. The processes and practices that the Deployment feature team uses to accomplish software state restore should include reporting capabilities to enable the customer to sign off on the application transformation process.

Computer Imaging

BDD 2007 focuses on a clean installation of Windows rather than upgrading from previous versions. In this way, the project team, the help desk, and the organization can work from a known state. Every computer is configured this way, without unknown or unanticipated differences, which makes the computing environment easier to set up, more efficient to administer, and less expensive to support. This method is sometimes referred to as a wipe-and-load approach, because it wipes out the original system completely and loads a new image.

Note Although this guide focuses on clean installations, Lite Touch Installation (LTI) also supports upgrade, refresh, and replace scenarios. With this support, team members can deploy the operating system to computers that are not suitable for the wipe-and-load approach, perform in-place upgrades, and perform refresh operations for existing computers running Windows.

The idea of the image is to create a select number of computers in a lab environment that meet the business needs of the enterprise. Teams can use tools, applications, security configurations, and corporate branding to customize these computers so that all* *users in the enterprise can use the computers without further customization.

When these systems meet the needs of the enterprise, they are imaged (or copied) so that they can be reproduced easily during the deployment. This approach saves considerable time and complexity. The feature team installs, configures, and tests the systems once and can then reproduce them thousands of times with confidence that the configuration has not changed.

This component supports computer imaging for the Windows XP and Windows Vista operating systems:

Windows XP. BDD 2007 supports System Preparation Tool (Sysprep)–based images created using ImageX.
Windows Vista. BDD 2007 supports Windows Imaging Format (WIM) images created with ImageX.exe, a command-line tool for creating and applying .wim files. Sysprep has been updated to support image-based setup and modularization. Use these tools to create a single file image on one system and deploy it to many different systems. Non-Microsoft tools such as Norton Ghost and PQDI are not supported as an imaging technology for Windows Vista.

The imaging process is scalable and extensible. Teams use batch files and Microsoft Visual Basic® Scripting Edition (VBScript) files to customize the computer configuration.

Table 1 describes the Windows Vista upgrade and migration paths. As shown in the table, performing an in-place upgrade from Windows XP with Service Pack 2 (SP2) or later to Windows Vista is supported. Using Windows Easy Transfer to migrate user state data from Microsoft Windows 2000 with SP4 or later to Windows Vista is supported. However, upgrading or migrating user state data from Microsoft Windows 98 to Windows Vista is not supported.

Table 1. Upgrade and Migration Paths

From	Upgrade to Windows Vista	Migrate to Windows Vista by using Windows Easy Transfer	Migrate to Windows Vista by using Microsoft Windows User State Migration Tool (USMT)	Migrate to Windows XP with SP2 by using USMT
Microsoft Windows 95
Windows 98
Windows 98 Second Edition
Microsoft Windows NT® 4.0
Windows 2000 with SP4 or later
Windows XP with SP2 or later
Windows Vista	(higher SKU)

circle1 = not supported circle2 = supported

Note Teams cannot upgrade Windows XP x64 to Windows Vista x64.

Caution BDD 2007 provides out-of-the-box support for partitioning and formatting the entire hard disk in New Computer scenarios. While editing the ZTIdiskpart.txt script to create multiple partitions is possible, doing so has downstream consequences for which must be tested.

Data and Settings Retention

Users have data scattered across their systems as well as operating system and application settings and preferences that must be preserved when the system is rebuilt. BDD 2007 uses USMT to scan a system and copy the specified data files and application settings from computers to a local backup or to a deployment server. After a new computer is built, the process is reversed, and all the data is restored to the user’s computer.

USMT can migrate not only the user data but also preferences, such as screen savers, wallpaper, and application preferences such as Microsoft Office Word and Office Excel® settings. USMT can also support custom applications.

Some organizations want to do more than copy a computer’s data and preferences. They want to copy the entire computer to the server temporarily to ensure that no files are lost. To accomplish this, BDD 2007 can optionally image the entire computer locally or to a server by using imaging software in addition to or instead of using the USMT.

Network Analysis

BDD 2007 offers guidance on the benefits and use of network discovery tools and graphical network maps in planning for deployments. Teams can use this information in the planning process by correlating it with computer inventories. Doing so helps locate potential network bottlenecks.

For example, teams might want to deploy computers to the accounting department in one evening, but after reviewing the network discovery data, they see that all 200 computers are connected to the deployment server by the same network switch. Therefore, the anticipated volume of data would be beyond the switch’s capacity.

Based on this information, the organization can schedule the deployment to span several days. In this way, teams reduce the risk of overusing the switch, and the performance and likelihood of success on each computer increases.

Deployment Process

BDD 2007 describes how to implement the deployment process to perform the migration on the computer. By combining other processes, BDD 2007 can:

Execute a deployment wizard to orchestrate the deployment.
Run the USMT to capture user data and preferences.
Back up (image) the entire computer to a server (optional).
Wipe the existing computer’s hard disk (optional).
Restore the new image onto the computer.
Customize the new image for hardware-specific needs.
Install computer- and user-specific applications.
Restore the user’s data and preferences (USMT).

BDD 2007 supports taking user data and settings off one computer and restoring them onto either the same hardware (the Refresh scenario) or a different piece of equipment (the Replace scenario). A technician runs the deployment wizard, which controls how the deployment progresses. The wizard can specify user-specific applications that were previously automated to be included on the computer. In this way, teams can use a consistent base image while still providing users with all the applications they need.