Additional Component Summary

BDD 2007 combines many different technologies into a single, integrated solution for computer deployments. Each technology may require software and hardware obtained from different locations. The following sections summarize the feature teams and help them collect all the required resources. This information is consolidated from all feature team guides. For detailed information, see the corresponding feature team guide. To save time in the Planning and Developing Phases of the project, Microsoft recommends reviewing these additional requirements and collecting the necessary components while the project team is getting organized.

Most feature teams need a lab environment. Although each team could construct separate labs, most organizations create a single lab that shares facilities such as servers, networks, system backup, and data repositories (such as Microsoft Visual SourceSafe®) with separate workspaces (computers and network shares) for each feature team. With this setup, the teams can work separately when necessary and jointly when appropriate. It also enables minimization of the number of computers and servers required. For more information about building a test lab, see the Test Feature Team Guide and the Infrastructure Remediation Feature Team Guide.

On This Page

Application Compatibility Feature Team Application Compatibility Feature Team
Application Management Feature Team Application Management Feature Team
Computer Imaging System Feature Team Computer Imaging System Feature Team
Deployment Feature Team Deployment Feature Team
Infrastructure Remediation Feature Team Infrastructure Remediation Feature Team
Operations Readiness Feature Team Operations Readiness Feature Team
Security Feature Team Security Feature Team
User State Migration Feature Team User State Migration Feature Team

Application Compatibility Feature Team

SE_GetStart03.gif

Before moving from the current version of the Windows operating system to Windows XP or Windows Vista, test applications to ensure that they are compatible with the new operating system. The organization may have up to several thousand applications installed across distributed networks. Compatibility problems with one or many of these applications can mean costly work stoppages. Testing applications and solving compatibility problems saves time and money for the organization.

Although most applications developed for earlier versions of Windows will probably perform well on the new versions, some applications may behave differently because of new technologies within the new versions. The applications to test to ensure compatibility include:

  • Core applications that are part of the standard desktop configurations, such as office productivity suites.

  • Line-of-business (LOB) applications, such as Enterprise Resource Planning (ERP) suites.

  • Administrative tools, such as antivirus, compression, backup, and remote-control applications.

  • Custom tools, such as logon scripts.

Personnel

The developers require access to subject matter experts (SMEs) for all applications to be tested. They are typically the same SMEs used as resources for the USMT and application-packaging tasks.

Lab

The lab requires target computers. These are computers that have the target Windows-based image installed to test the application’s Windows compatibility.

Software

The Application Compatibility feature team requires the following applications:

  • Application Compatibility Toolkit. For more information on the ACT, see the Application Compatibility Feature Team Guide. Download the most current version of the ACT by using the Deployment Workbench.

  • SQL Server. The ACT stores the application inventory using Microsoft SQL Server™, which is available on volume-licensed media.

For each application to be tested, the developers must have a copy of the application’s installation media and any configuration documentation. The IT department or the SME should be able to provide this.

Hardware

The team must have a Windows-based computer to host the ACT and database.

Other

The team must have a deployment mechanism for the ACT. This mechanism could be a logon script, a Web site, or another deployment mechanism.

Application Management Feature Team

SE_GetStart04.gif

Hundreds or thousands of applications may reside on the organization’s computers. Often, each application was installed differently on each computer, depending on who performed the installation. This inconsistency across computers leads to usability and support issues.

If an application is packaged, it can be installed on a client computer without user intervention. The person doing the packaging has decided where to install the application and has selected settings or options. The result is an executable file that is consistent across the organization and simple to install. Double-clicking or typing one line of information is all that is required to launch and run the complete installation. This component describes some of the approaches to packaging applications for use with the solution.

This module also covers how to set up the 2007 Office system for deployment as part of the base client computer image. Microsoft Office is often a corporate-standard application suite. Therefore, many organizations consider it an integral part of computer deployment.

Personnel

The developers must have access to SMEs for all applications to be packaged. These SMEs are typically the same as those used in USMT and application-compatibility testing.

Lab

The lab must have:

  • Target computers. Computers with the target Windows image installed to test the application’s Windows packages

  • Network shares. Shares that hold the original installation media software and the completed application packages

Software

The Application Management feature team must have:

  • Supplemental application software. (Examples include InstallShield and Wise for Windows Installer.)

  • Application installation source media. (For each application to be tested, the developers must have a copy of the application’s installation media and any configuration documentation. The IT department or the SME should provide this.)

  • Microsoft Office volume-licensed media (required).

  • 2007 ORK.

Computer Imaging System Feature Team

SE_GetStart05.gif

Team members are probably familiar with imaging tools such as ImageX, but they may not know how they can use them to support desktop deployment. Using them effectively is a big challenge. A specific solution is recommended for imaging the operating systems and the core applications that are part of a standard desktop. The solution is modular; it allows team members to separately manage each system component. The advantage is that when changes occur—and they will—team members do not have to re-engineer the entire process. The solution also provides the tools and scripts to install, configure, and customize the Windows platforms and incorporate device drivers and updates. The process is a robust starting point for building systems that are easily and broadly extensible.

The Computer Imaging System process includes the following steps:

  • Create a build server.

  • Configure a distribution share.

  • Create and customize builds.

  • Create Windows PE–bootable images.

  • Build initial operating system images.

Lab

Configure the test lab with at least the items described in the “Lab Requirements” section of the Computer Imaging System Feature Team Guide. And, to the extent possible, configure the lab to fully represent the production environment. The lab should have the following hardware:

  • Build server. A server or client computer that hosts BDD 2007, including Deployment Workbench. The team will develop, capture, and store images on this computer.

  • Client computers. Duplicate in the lab any unique type of computer configuration that will be found in production. Doing so allows for testing each hardware configuration.

Software

The team must have the installation media for each version of Windows it is deploying, including volume license keys. The team must also download additional components required for destination computers. Additional components include device drivers, hardware-specific applications, and updates for the destination computers to which the team is deploying Windows. For a complete list of additional components necessary for the destination computers at Woodgrove National Bank, see the Client Build Requirements job aid.

Deployment Feature Team

SE_GetStart06.gif

In large organizations, deployment is a resource-intensive and time-consuming process. This solution details planning steps that streamline the up-front work. It also describes specific deployment steps that greatly simplify installing client computers. Deployment planning and pilot testing should be part of any internally developed process. Processes will differ primarily in the technologies used for the deployment.

The deployment process consists of the following four phases:

  • Plan server placement.

  • Evaluate server and network capacity.

  • Install the distribution shares and tools.

  • Deploy the client computers.

Lab

The Deployment feature team must have:

  • A replica of the base production environment to unit-test the combined efforts of all the other feature teams.

  • Two types of network server shares: one for the distribution share and a second for the data server share. These shares could be all on the same physical server or on separate servers to support performance objectives.

  • Source computers with user data loaded (the same as required for the User State Migration feature team). These computers are used for the unit-test deployment.

Software

The team must have the download file (.msi file) that contains the BDD 2007 components. See the Deployment Feature Team Guide for additional components for each scenario.

Infrastructure Remediation Feature Team

SE_GetStart07.gif

Understanding the network environment is critical for any project that introduces changes. To plan and prepare to incorporate these changes, first understand the current status of the organization's environment, identify other sources of change that may affect this project, perform a risk-mitigation approach to the changes, and then incorporate the proposed changes. It has been demonstrated that organizations can solve and possibly avoid most networking problems by creating and maintaining adequate network documentation. Using a networking tool, the team can:

  • Gather all the information necessary to help understand a network as it exists today.

  • Plan for growth.

  • Diagnose problems when they occur.

  • Update the information with network changes—either in real-time or scheduled.

  • Work with the information to manage network assets. (Often, an apparently simple configuration change can result in an unexpected outage.)

  • Present information visually so that the network structure appears in as much detail as necessary for each task.

Software

The Infrastructure Remediation feature team must have SQL Server, which is available on volume-licensed media. The team uses SQL Server to create hardware inventory reports against the application-compatibility database. This could be the same installation that the Application Compatibility feature team uses.

Other

The team must have access to current network topology diagrams and network device inventory information.

Operations Readiness Feature Team

SE_GetStart08.gif

The Operations Readiness feature team is responsible for a smooth and successful handoff of the deployed solution to the in-place IT Operations staff. This aspect of the overall project is important because the success of the handoff directly reflects on the success of the deployment project. To ensure this success, the activities of the feature teams must be integrated with the ongoing management and operating functions of the IT Operations staff.

The Operations Readiness feature team can facilitate deployment by completing the following tasks:

  • Confirm that the workstation roles identified in the functional specification are still valid.

  • Analyze and evaluate the management tools currently in use.

  • Assess the current maturity of the operations environment in key operational areas.

  • Establish effective management processes and tools in deficient key areas.

  • Develop a training program for operations and support staff.

  • Prepare the operations staff for the pilot.

The Operations Readiness feature team does not initially require any additional personnel, lab, or software resources for this project.

Security Feature Team

SE_GetStart09.gif

The Security feature team has an important role in the overall success of the deployment project. Security is a primary concern in all organizations, and the goal of the Security feature team is to secure the organization’s data. Inadequate security in an organization can result in lost or corrupted data, network downtime, lost productivity, frustrated employees, overworked IT employees, and possibly stolen proprietary information that results in lost revenue.

To ensure that adequate security measures are in place, the Security feature team should:

  • Analyze and determine the existing security level of the organization.

  • Identify vulnerabilities caused by software upgrades and update network security specifications accordingly.

  • Ensure that security measures are current.

The Security feature team does not initially require any additional personnel, lab, or software resources for this project.

User State Migration Feature Team

SE_GetStart10.gif

One of the most tedious and time-consuming tasks during deployment is identifying data files and settings on users’ current computers, saving them, and then restoring them. The team could easily dismiss this task as unnecessary. However, Microsoft’s experience shows that users spend significant amounts of time restoring items such as wallpaper, screen savers, and other customizable features. In addition, most users do not remember how to reapply these settings. Migrating these items can increase user productivity and satisfaction. To address this task, this solution proposes a step-by-step process called User State Migration.

The following list outlines the User State Migration development process:

  • Inventory existing production client computer applications.

  • Identify applications with data or preference migration requirements.

  • Prioritize the application list to be addressed.

  • Identify SMEs for each application.

  • Identify data file requirements for each application.

Personnel

The developers must have access to SMEs for all application data and settings to be migrated. These SMEs are typically the same as those used in application-compatibility testing and in automating installations (application packaging).

Lab

The lab should have the following elements:

  • Source computers. Representative computers to use for testing the configuration files (Images of production computers may be the best way to do this.)

  • Intermediate store. A network share on which the User State Migration feature team can place the user data files and settings (If the team is deploying Windows Vista, team members can optionally store state data on each destination computer.)

  • Target computers. Computers with the target Windows image installed to test the restoration of the data files and settings

Software

The User State Migration feature team must have the USMT executables and configuration files. Download the USMT files by using Deployment Workbench.

Download

Get the Microsoft Solution Accelerator for Business Desktop Deployment 2007

Update Notifications

Sign up to learn about updates and new releases

Feedback

Send us your comments or suggestions