Ensuring That the Required Infrastructure Exists

Article
03/05/2008

Before using BDD 2007 to deploy Windows, ensure that the infrastructure that BDD 2007 requires exists. For most production environments, the majority of the services required for deployment already exist, but verify that all the following infrastructure is in place before continuing the deployment process.

Identifying the Storage Requirements for Deployment Images
Reducing Storage Requirements for Deployment Images
Providing Sufficient Storage for User State Migration Data
Providing Sufficient Storage for Computer Backup
Providing Sufficient Storage for Application and Operating System Source Files
Using Windows DS Using Windows DS
Verifying an Adequate Target Computer Configuration
Providing Adequate Network Capacity

Identifying the Storage Requirements for Deployment Images

Ensure that sufficient storage is available for storing the target operating system images that Deployment Workbench creates. These images are stored on the deployment points that Deployment Workbench designates.

Determine the size of each image and the number of images required in the deployment. Create a unique image for:

Each unique hardware abstraction layer (HAL) required for the target computers when the target operating system is Windows XP.
The copy of Windows Vista to be deployed.
Each localized operating system language version required (such as Chinese simplified or Japanese).

For planning purposes, estimate the size of an image to be within the range of 500 megabytes (MB) to 4 gigabytes (GB), including applications. If there are five unique images, the total available disk storage on a deployment point is 20 GB (4 GB × 5). Ideally, each deployment point would have at least that much available disk storage.

Reducing Storage Requirements for Deployment Images

If the available disk space cannot be increased on the deployment points, reduce the storage requirements. Reduce the storage required for the deployment points by using any combination of the following methods:

Reduce the number of images. If a limited number of target computers have a specific HAL, consider another method of installing Windows XP on the target computers (such as deploying from a DVD-based image or on a removable hard disk).
Distribute the images to specific deployment points only. In some instances, the images may be specific to a geographic location. (This is especially true for language-specific images.) Distribute only those images for a specific geography to the deployment points in the corresponding geographic locations.
Deploy Multilingual User Interface (MUI) versions of Windows. When possible, deploy MUI versions of Windows to reduce the number of images required as a result of language differences. Avoid using the localized version of Windows.

Providing Sufficient Storage for User State Migration Data

Determine the amount of storage required for the user state migration data that the USMT saved during the deployment process. When the amount of storage required is known, designate local storage on the target computers or shared folders that can be used as a temporary store for user migration data.

Determining Storage Requirements for User State Migration Data

For planning purposes, estimate the user state migration storage requirements by:

Running Scanstate.exe in the USMT with the /p command option to estimate the size of the user state migration data. By using the /p command option, team members can estimate the disk space requirements without actually performing the migration. For more information, see Business Desktop Deployment User State Migration Feature Team Guide in the “Additional Resources” section of this guide.
Viewing the size of the contents of the folders in the user profile. Randomly sample targeted computers to determine an average amount of storage required to back up the user state migration. Keep in mind that there may be several profiles (user name folders) on each target computer, so include each profile to be migrated.
Also, team members must know how long the user state migration data must be stored. Store the user state migration data in the event that the deployment fails and team members must roll back the configuration. After verifying a successful deployment, the user state migration data can be deleted.

Calculate the storage requirements for user state migration data by multiplying the size of the user migration state by the number of simultaneous computers being upgraded (size of migration × number of simultaneous computers).

Determining Where to Store User State Migration Data

After determining the storage requirements for the user state migration data, determine where to store the user state migration data. Store user state migration data:

On the local computer to reduce the time to deploy Windows Vista or Windows XP and reduce network utilization (recommended).

Note Use this option only in the Refresh Computer scenario.
On a shared folder located on a local server to provide a consistent method of storing user state migration data or when local storage is not available.

If user state migration data will be stored locally on the target computers, designate a shared folder in which the deploy process can store the data. (By default, the process attempts to store user state data on the local hard disk for the Refresh Computer scenario. However, team members can override this behavior with configurations settings in CustomSettings.ini.) In the event that there is insufficient disk space for the user state and new image, the deployment scripts attempt to store the information in a shared folder. Providing the shared folder as an alternate storage location makes the deployment process more reliable. Place the shared folder such that there is a high-bandwidth connection between the shared folder and the target computers.

Providing Sufficient Storage for Deployment Logs

The deployment logs record the process for each target computer through the image-distribution process. Determine the amount of storage required for the deployment logs saved during the deployment process. When the amount of storage required is known, designate shared folders that can be used as temporary stores for deployment logs.

Determining Storage Requirements for Deployment Logs

For planning purposes, perform the following steps to estimate the deployment log storage requirements for a single target computer:

Run the upgrade process in the test lab to determine the size of the deployment logs.
Determine how long the deployment logs must be persisted.
Multiply the size of the deployment logs for one computer by the number of computers being deployed simultaneously.

Determining Where to Store Deployment Logs

After determining the storage requirements for the deployment logs, determine where to store the deployment logs. Store them in a shared folder that is connected to the target computers by a high-bandwidth connection.

Providing Sufficient Storage for Computer Backup

As an optional step in the deployment process for the Refresh Computer and Upgrade Computer scenarios, you can perform a backup of a target computer before deploying the target operating system. The purpose of this backup is for recovery of user state migration data.

You can perform the backup to:

Local drives on the target computer.
Network shared folders.

The backup process in BDD 2007 is performed by using the Imagex.exe tool. The backup process creates an image of the disk volume where the user state migration data is stored.

For planning purposes, you can estimate the computer backup storage requirements for a single computer by performing the following steps:

Run the Refresh Computer and Upgrade Computer scenario processes in the test lab to determine the size of the backup file.
Determine how long the backup file needs to be persisted.
Multiply the size of the backup file for one computer times the number of computers being deployed simultaneously by using the Refresh Computer and Upgrade Computer scenarios.

Providing Sufficient Storage for Application and Operating System Source Files

Each deployment point in your environment needs access to the application and operating system source files to be used in your deployment process. You can provide access to these source files by creating a copy of the source files on:

A common network shared folder that is accessible to all servers hosting the deployment points. The advantage of this method is that you need to provide storage for only one copy of the source files. The disadvantage is that the distribution points must access the source files over the network, which increases network utilization and is slower than accessing the source files locally.
Each server hosting the deployment points. The advantage of this method is that accessing the source files is faster than from a network shared folder. The disadvantage is that you need to provide sufficient storage for the source files on each server hosting the distribution points.

For planning purposes, you can estimate the application and operating system source file requirements for a single deployment point (or common shared folder) by performing the following steps:

Create a copy of each application and operating system source file on a shared folder.
Determine how much disk storage all the application and operating system source files require.

If you are:

Using one common network shared folder to be accessed by all distribution points, select a server with sufficient available disk storage for the source files.
Providing a local copy to each distribution point, ensure that each server hosting one or more distribution points has sufficient available disk storage for the source files.

Using Windows DS

Use Windows DS to deploy Windows Vista or Windows PE to the target computers. Deploy Windows PE to target computers first to help prepare the target computer for deployment and to initiate the balance of the deployment.

Use Deployment Workbench to create customized Windows Vista or Windows PE images. These images can be stored on the deployment point or on the Windows DS server.

Use Windows DS to automate the deployment of Windows Vista or Windows PE:

For computers that have a high-speed, consistent connection to a Windows DS server.
In the New Computer, Upgrade Computer, and Replace Computer scenarios.

Note Install Windows Vista or Windows PE to prepare the target computers by using Windows DS or by using a Windows PE CD locally on the computers. These methods provide the same functionality. Use the CD method when Windows DS is unavailable, such as when target computers have low-bandwidth connections to the Windows DS servers.

Verifying an Adequate Target Computer Configuration

Before deploying images to a target computer, ensure that the computer has the correct configuration. To deploy an image to a target computer, first:

Verify that the target computer has the correct versions of necessary software.
Verify that the target computer has adequate system resources.
Identify the differences in 64-bit and 32-bit deployments.

Verifying Correct Target Computer Software Versions

Before running the rest of the BDD 2007 scripts, first run ZTIPrereq.vbs to ensure that the 64-bit target computer meets the requirements for running the remaining scripts. These script prerequisites include:

Microsoft Windows 2000 Professional SP4, Windows XP SP2, or a later Windows operating system.
Windows Script Host (WSH) version 5.6 or later is installed and running.
Microsoft Core Extensible Markup Language (MSXML) Services version 3.0 (any service pack level) is installed and running.
Microsoft Data Access Components (MDAC) version 2.0 or later is installed and running.

Note The version of MSXML must be 3.0. MSXML versions 4.0 and 6.0 are not compatible with the BDD 2007 scripts.

Verifying Adequate Target Computer Resources

After ZTIPrereq.wsf determines that the 64-bit computer meets the requirements for running the remaining scripts, ZTIValidate.wsf determines whether the target computer has the appropriate resources to deploy the target operating system. These requirements include:

The target computer is a desktop or laptop computer (not a server).
The OSInstall property, if defined, must be set to YES for the deployment to continue.
The target computer must have at least 512 MB of RAM total (448 MB for the operating system and 64 MB of shared video memory).
The target computer processor must run faster than 990 megahertz (MHz). (Most computer vendors market these systems as 1 gigahertz [GHz], but the methods of measuring processor speed are not consistent from vendor to vendor.)
The target computer must have sufficient available disk space for the image being deployed to the target computer.
The current operating system on the target computer must be running on the C: partition (Refresh Computer scenario only).
Drive C must be the first partition on the first disk of the target computer (Refresh Computer scenario only).
Additional available disk space is required when user state migration data and deployment logs are stored locally on the target computer.
The target computer must have sufficient free disk space to hold Windows PE log files (approximately 150 MB).
The target computer must have sufficient total disk space to hold Windows PE and the image (expanded image size plus 150 MB).
The target computer must have a direct network connection to Windows DS servers and deployment points. (Unsupported network connections include Virtual Private Network [VPN] and wireless connections.)

Note Target computers that attempt to install an image over a VPN or wireless connection will not be able to connect to a deployment point after restarting in Windows PE, causing the deployment process to fail.

Use SMS (or another software inventory tool) to help determine whether any existing computers have inadequate system resources. Upgrade the system resources on these target computers prior to deploying Windows, if necessary.

If team members determine that some computer system resources are inadequate for deploying Windows, they can perform one of the following actions:

Upgrade the system resources on the existing computers.
Replace the existing computers with new computers.
Eliminate the existing computers from being part of the upgrade.

Identifying Differences in 64-bit and 32-bit Deployment

In most instances, deploying 64-bit versions of Windows is the same as deploying 32-bit versions of Windows. However, there are differences that affect how 64-bit versions of Windows are deployed and how BDD 2007 detects that the target computer has a 64-bit processor.

Note BDD 2007 supports only Intel EM64T–enabled processors and the AMD64 family of processors. The Intel Itanium and ia64 family of processors is not supported in BDD 2007.

Most of the functions and features found in 32-bit versions of Windows are the same in 64-bit versions of Windows. However, the following differences must be taken into consideration when deploying 64-bit versions of Windows:

The version of Windows PE must match the version of Windows being deployed. If team members are deploying a 64-bit version of Windows Vista, they must use a 64-bit version of Windows PE. Conversely, if they are deploying a deploying a 32-bit version of Windows Vista, they must use a 32-bit version of Windows PE.
Applications are installed in separate Program Files folders. On 64-bit versions of Windows, 64-bit applications are installed in the Program Files folder, and 32-bit applications are installed in the Program Files (x86) folder. Check the appropriate folder structure when looking for previously installed applications.
Processor architecture discovery in Windows DS may need to be forced for 64-bit computers. Not all 64-bit computers properly report the processor type; therefore, BDD 2007 may not properly detect that the processor is a 64-bit processor. Force Windows DS to deploy 64-bit versions by using the following command:
```
WDSUTIL /set-server /architecturediscovery:yes
```
For more information, see the Windows DS Help files.
64-bit versions of Windows PE 2.0 do not run 32-bit applications. Ensure that any compiled applications used by a 64-bit version of Windows PE are 64-bit versions.
64-bit versions of Windows require 64-bit device drivers. 32-bit device drivers cannot be used in 64-bit versions of Windows.

Providing Adequate Network Capacity

Because of the size of the images being distributed to the target computers (500 MB–4 GB), computers must have a high-speed, persistent connection to the servers used in the deployment process. These servers include:

Windows DS servers.
Servers hosting shared folders used to store deployment images (that is, deployment points).
Servers hosting shared folders used to store user state migration data.
Servers hosting shared folders used to store deployment logs.

These servers should be on adjacent subnets to the target computers to ensure high-speed connectivity to the computers. If the organization cannot provide sufficient network capacity to deploy the BDD 2007 solution to computers, perform one of the following actions:

Temporarily place the appropriate servers (for example, servers hosting the various shared folders or Windows DS server) closer to the target computers for the duration of the migration.
Temporarily move the target computers to a staging area where the computers can be deployed, and then returned to their original location.
Store user state migration data locally on the target computers.
Perform automated deployments locally by using a combination of a Windows Vista or Windows PE image CD.
In addition, when deploying computers through a firewall, ensure that the appropriate TCP and UDP ports are open on firewalls.