Planning Deployment : Preparing for Development

Whether your organization uses BDD 2007 or not, it will likely require multiple feature teams to develop high-volume deployment projects. Most feature teams need a lab environment. Although each feature team can construct a separate lab, most organizations create a single lab that shares facilities such as servers, networks, system backup, and source control with separate workspaces (computers and network shares) for each feature team. With this environment, feature teams can work separately when necessary and jointly when appropriate. It also helps minimize the number of computers and servers required.

The Planning Phase is the best time to begin preparing the development environment, however. The process includes installing BDD 2007, stocking the lab environment with the files necessary to perform each feature team’s job, locating application media, and so on. The following sections describe steps to complete during the Planning Phase to expedite the development process.

Application Compatibility

Before migrating from your current version of Windows to Windows Vista, test applications to ensure that they are compatible with Windows Vista. You might have several thousand applications installed across distributed networks. Compatibility problems with one or many of these applications can disrupt productivity and damage the user experience and satisfaction with the project. Testing applications and solving compatibility problems saves time and money for the organization. It also prevents roadblocks to future deployment projects based on perceived pain.

Although most applications developed for earlier versions of Windows will probably perform well on Windows Vista, some applications might behave differently because of new technologies within the new operating system. Test the following applications to ensure compatibility:

• Custom tools, such as logon scripts

• 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

The following list describes steps you can take during the Planning Phase to begin building the lab environment for application compatibility:

• Installation media For each application that you test, you must have a copy of the application’s installation media, any configuration documentation, and product keys. If your IT department doesn’t have the media or other information, check with the subject matter expert for each application.

• Destination computers Within the lab, the Application Compatibility feature team requires destination computers that resemble computers found in the production environment. Each destination computer should have Windows Vista installed on it to test applications’ compatibility with the operating system.

• Application Compatibility Toolkit For more information on the Application Compatibility Toolkit (ACT). BDD 2007 provides a user interface for downloading the most recent version of the ACT.

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

• Host computer You must have a computer on which to install the ACT and SQL Server.

• Deployment mechanism The Application Compatibility feature team requires a mechanism for deploying ACT packages. This can be through logon scripts, a local website, or another deployment mechanism.

Application Management

The Application Management feature team is responsible for repackaging applications or automating their installation and configuration. Organizations can have hundreds or thousands of applications. Often, users install each application differently on each computer, leading to inconsistency across computers and resulting in support and management issues.

Repackaging or automating an application’s installation has many benefits. Most obviously, it allows applications to install without user intervention, which is especially desirable when deploying applications as part of a disk image or during disk image deployment. In addition, repackaging or automating leads to consistency that lowers deployment and ownership costs by reducing support issues and enhancing management.

The Application Management feature team can use the following checklist to begin preparing the lab:

• Installation media For each application you repackage or automate, you must have a copy of the application’s installation media, any configuration documentation, and product keys. If your IT department doesn’t have the media or other information, check with the subject matter expert (SME) for each application.

• Destination computers Within the lab, the Application Management feature team requires destination computers on which to test application installations. Each destination computer should have Windows Vista installed on it to test application installations on the destination operating system.

• Host computer with network shares You must have a computer on which to host the application installations. Shares on this computer hold the original installation sources and completed packages.

• Application packaging software The Application Management feature team needs software with which to repackage applications. 

• Deployment mechanism The Application Management feature team requires a mechanism for deploying ACT packages. This can be through logon scripts, a local website, or another deployment mechanism.

Computer Imaging System

You’re probably already familiar with disk imaging tools, such as Symantec Ghost or ImageX (the Windows Vista imaging tool). Using imaging tools effectively is a significant challenge, however, and this challenge is the reason that Microsoft developed BDD 2007. With BDD 2007, you do not have to engineer the entire imaging process; the framework provides most of the code for you already. All that’s left is for you to customize it to suit your organization’s requirements. Using BDD 2007 to build Windows Vista images involves the following steps:

• Create a build server The build server is the host for BDD 2007 and its distribution share.

• Configure a distribution share The distribution share contains the source files (Windows Vista, applications, device drivers, and so on) from which you build operating system images.

• Create and customize builds After stocking the distribution share, you create builds. Builds associate source files from the distribution share with the settings necessary to install and configure it. These settings include an answer file (Unattend.xml) and a task sequence. 

• Create deployment points Deployment points are copies of the distribution share that are ready to deploy. For each deployment point, BDD 2007 provides a Windows PE boot image that you can use to connect to the deployment point and install builds from it.

• Build initial operating system images With BDD 2007, building a custom Windows Vista image is as simple as installing the operating system from a deployment using the Windows Deployment Wizard. This is a Lite Touch installation (LTI) process that requires minimal user interaction and automatically captures a Windows Vista image and stores it back in the distribution share.

In preparation for the development process, you can begin building the lab during the Planning Phase, as the following list describes:

• Windows Vista media You will need media and volume license keys for Windows Vista.

• Destination computers

• Build computer for BDD 2007 You must have a computer on which to host BDD 2007 and the distribution share. The lab server should have a DVD-RW drive and be networked with the destination computers. You can install BDD 2007 on a desktop or server computer.

• Windows Deployment Services The lab environment should contain a server running Windows Deployment Services (Windows DS). Using Windows DS to boot destination computers is much faster than burning DVDs and starting computers with them.

• Additional source files Early in the Planning Phase, the Computer Imaging System feature team can begin assembling the source files required to stock the distribution share. Source files include device drivers and hardware-specific applications for each computer in the production environment. Additionally, the team should begin assembling any security updates and operating system packages that must be added to the distribution share.

Deployment

Deployment is an intense, time-consuming process during any high-volume deployment. BDD 2007 provides planning guidance and tools that help streamline the following processes:

• Planning server placement

• Evaluating server and network capacity

• Installing the distribution shares and tools

• Deploying the client computers

During the Planning Phase, the Deployment feature team should begin preparing the lab environment as described in the following list:

• Production replica The Deployment feature team needs a replica of the production environment to unit-test the combined efforts of all the other feature teams. Destination computers should be running the versions of Windows found in the production environment with user data loaded. These computers are used for the unit-test deployment, including user state migration.

• Network shares on a host computer Two types of network shares are required: one for the BDD 2007 distribution share and a second for the data server share. These shares could be all on the same physical server or on separate servers. Also, it’s useful to store images of the production computers on the host computer to restore them quickly and easily after each test pass.

• Windows Deployment Services The lab environment should contain a server running Windows Deployment Services (Windows DS). Using Windows DS to boot destination computers is much faster than burning DVDs and starting computers with them. The Deployment feature team can use the same Windows DS server as the Computer Imaging System feature team.

Infrastructure Remediation

Understanding the network environment is critical with 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. Organizations can solve and possibly avoid most networking problems by creating and maintaining adequate network documentation. Using a networking tool, the team can:

• Gather 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.

The Infrastructure Remediation feature team must have access to SQL Server. 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. The team must also have access to current network topology diagrams and network device inventory information.

Operations Readiness

The Operations Readiness feature team is responsible for a smooth and successful handoff of the deployed solution to the Operations staff. This aspect of the overall project is important because the success of the handoff directly reflects the success of the deployment project. To ensure success, the activities of the feature teams must be integrated with the ongoing management and operating functions of the 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 valid.

• Analyze and evaluate the management tools currently in use.

• Assess the 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 have any additional lab requirements.

Security

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 have any additional lab requirements. 

User State Migration

One of the most tedious and time-consuming tasks during deployment is identifying data files and settings on users’ current computers (known as user state), saving them, and then restoring them. Users spend significant time restoring items such as wallpaper, screen savers, and other customizable features. And most users don’t remember how to restore these settings. Migrating user state can increase user productivity and satisfaction. In BDD 2007, the User State Migration feature team performs the following tasks:

• 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.

The User State Migration feature team completes these tasks in cooperation with the Application Compatibility and Application Management feature teams. Therefore, the User State Migration feature team can and should share a lab environment with the other two teams.

• Installation media For each application containing settings to migrate, you must have a copy of the application’s installation media, any configuration documentation, and product keys. If your IT department doesn’t have the media or other information, check with the subject matter expert (SME) for each application.

• Destination computers The User State Migration feature team requires computers in the lab on which to test user state migration solutions. Destination computers should be running the versions of Windows found in the production environment with applications and user data loaded. These computers are used for the unit-test user state migration.

• Host computer You must have a computer on which to host application source files and migration solutions. It’s useful to store images of the destination computers on the host computer to restore them quickly and easily after each test pass.

• Data store The data store is a network share on which you can put user state data during testing. You can create the data store on the host computer, or you can optionally create the data store on each destination computer.

• User State Migration Tool BDD 2007 uses the User State Migration Tool (USMT) to migrate user state. The functionality is already built in to the BDD 2007 framework.