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 the deployment already exist, but verify that all the following components are in place before continuing the deployment process.

Sufficient SMS 2003 Infrastructure Sufficient SMS 2003 Infrastructure
Providing Sufficient Storage for User State Migration Data
Providing Sufficient Storage for Deployment Logs
Providing Sufficient Storage for Computer Backup
Providing Sufficient Storage for Application and Operating System Source Files
Using Windows Deployment Services or Remote Installation Services
Verifying an Adequate Target Computer Configuration
Providing Adequate Network Capacity

Sufficient SMS 2003 Infrastructure

BDD 2007 requires that the infrastructure includes SMS 2003, so ensure that all servers running SMS within the organization are running that version. In addition, BDD 2007 has the following requirements specific to SMS 2003:

SMS 2003 with SP2. SMS 2003 with SP2 is required on all SMS site servers within the infrastructure before beginning deployment. For more information about upgrading the infrastructure to SMS 2003 with SP2, see System Management Server 2003 Service Pack 2 Overview in the* *“Education and References” section of this guide.
SMS 2003 OSD Feature Pack. Install the SMS 2003 OSD Feature Pack on one or more site servers within the organization. The SMS 2003 OSD Feature Pack is an add-on to SMS 2003 that provides the ability to capture, distribute, and install images to target computers and servers. For more information about the SMS 2003 OSD Feature Pack, see Microsoft Systems Management Server 2003 Operating System Deployment Feature Pack Users Guide in the “Education and References” section of this guide.

Identifying the Storage Requirements for Distribution Points and Deployment Points

When the server is running SMS 2003 with SP2 and the team has installed the SMS 2003 OSD Feature Pack, it must ensure that sufficient storage is available on the:

SMS distribution points for the images that the SMS 2003 OSD Feature Pack creates.
Deployment server distribution point for the images used to create the SMS OSD Feature Pack images.
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 the team has five unique images, the total available disk storage on a distribution point is 20 GB (4 GB × 5). Ideally, each distribution point would have at least that much available disk storage.

Reducing Storage Requirements for Distribution Points and Deployment Points

If the team cannot increase the available disk space on the distribution and deployment points, the team must reduce the storage requirements. To reduce the available storage required for the distribution and deployment points, use 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 them (such as the LTI deployment).
Distribute the images to specific distribution 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 distribution points in the corresponding geographic locations.
Deploy Multilingual User Interface (MUI) versions of Windows. When possible, deploy MUI versions of Windows Vista or Windows XP to reduce the number of images required as a result of language differences. Avoid using the localized version of Windows Vista or Windows XP.

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 team knows the amount of storage required, designate local storage on the target computers or shared folders that can be use as a temporary store for user migration data.

Determining Storage Requirements for User State Migration Data

For planning purposes, the team can 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. The /p command option allows team members to 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 “Education and References” section of this guide.
Viewing the size of the contents of the folders in the user profile. Team members can randomly sample targeted computers to determine an average amount of storage required to back up the user state migration. Keep in mind that there could be several profiles (user name folders) on each target computer, so the team must include each profile it plans to migrate.

The team must also know how long the user state migration data must be stored. Store the user state migration data in the event that the upgrade fails and the team must roll back the configuration. After verifying a successful upgrade, the team can delete the user state migration data.

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 migration data. Store user state migration data:

On the local target 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 the team elects to store user migration data on the local target computer, it must designate a shared folder in which the ZTI process can store user state migration data. (By default, the process attempts to store user state data on the local hard disk for Refresh Computer scenarios. However, the team 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 ZTI process attempts 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 computer.

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 team knows the amount of storage required, designate shared folders that can be used as temporary stores for deployment logs.

Determining Storage Requirements for Deployment Logs

For planning purposes, the team can estimate the deployment log storage requirements for a single computer by performing the following steps:

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

Determining Where to Store Deployment Logs

After determining the storage requirements for the deployment logs, determine where to store the deployment logs. Store deployment logs 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 scenario, 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 back up 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 scenario process 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 scenario.

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 then 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 on 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, then ensure that each server hosting one or more distribution points has sufficient available disk storage for the source files.

Using Windows Deployment Services or Remote Installation Services

Use Windows DS to deploy Windows PE to prepare the target computer for deployment. Use Windows DS when:

SMS does not manage the computer.
A computer is not running the SMS Advanced Client.
A computer has no operating system.

Windows DS performs the same functions as RIS in SMS OSD Feature Pack-based deployments. The SMS OSD Feature Pack is required by ZTI. SMS OSD Feature Pack is only compatible with RIS methods of deployment. To use Windows DS, run Windows DS in Legacy mode or Mixed mode, which is compatible with RIS methods of deployments.

Using the SMS 2003 OSD Feature Pack, team members can create a custom Windows PE image that allow installation Windows Vista or Windows XP from the nearest SMS distribution point.

Note Windows DS support is only required to deploy Windows PE for SMS OSD Feature Pack support.

Use Windows DS to automate the deployment of Windows PE:

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

Install Windows PE to prepare the target computers by using Windows DS, or by using a Windows PE CD locally on the target 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.

Note Any references in this document to RIS configuration or RIS configuration files are to support Windows DS running in Legacy or Mixed mode. The configuration process and tools used for Windows DS in Legacy or Mixed modes are the same as for RIS.

Verifying an Adequate Target Computer Configuration

Before deploying an SMS 2003 OSD Feature Pack image to a target computer, ensure that the computer has the correct configuration. To deploy an image to a target computer, first:

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

Verifying Correct Target Computer Software Versions

Before the rest of the BDD 2007 scripts are run, ZTIPrereq.vbs is run first to ensure 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.
SMS Advanced Client for SMS 2003 SP2.
Windows Script Host (WSH) version 5.6 or later is installed and running.
Microsoft Core Extensible Markup Language (MSXML) Services version 3.0 or later (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 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 portable 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 drive 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 distribution 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 distribution point after rebooting into 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 by using SMS queries and reports. The team can upgrade these computers prior to deploying Windows Vista or Windows XP.

If the team determines that some computers system resources are inadequate for deploying Windows Vista or Windows XP, team members 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 the team deploys 64-bit versions of Windows and how BDD 2007 detects that the target computer has a 64-bit processor.

Note BDD 2007 only supports Intel EM64T-enabled processors and the AMD64 family of processors. The Intel Itanium and ia64 family of processors are 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 need to 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 the team is deploying a 64-bit version of Windows Vista, a 64-bit version of Windows PE is required. Conversely, if the team is deploying a deploying a 32-bit version of Windows Vista, a 32-bit version of Windows PE is required.
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, and 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 SMS 2003 OSD Feature Pack images being distributed to the target computers (500 MB–4 GB), the target computers need to have a high-speed, persistent connection to the servers used in the deployment process. These servers include:

SMS site servers.
SMS distribution points.
Windows DS servers.
Servers hosting shared folders used to store user migration state data and 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 to a computer, perform one of the following actions:

Temporarily place the appropriate servers (for example, SMS distribution point or Windows DS server) closer to the computer for the duration of the migration.
Temporarily move the computers to a staging area where the target computers can be deployed and then returned to their original location.
Store user state migration data locally on the computer.
Perform automated deployments locally by using a combination of a Windows PE CD or an SMS 2003 OSD Feature Pack image CD.

In addition, to deploy to target computers through a firewall, the team must ensure that the appropriate TCP and UDP ports are opened on firewalls. For more information, see:

“Ports that SMS 2003 uses to communicate through a firewall or through a proxy server” in “Education and References” in this guide.