zero touch installation deployment feature team guide

Zero Touch Installation Deployment Feature Team Guide

Business Desktop DeploymentSOLUTION ACCELERATOR

ENTERPRISE EDITION

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), but only for the purposes provided in the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, email address, logo, person, place, or event is intended or should be inferred.

2004 Microsoft Corporation. All rights reserved.

Microsoft, Active Directory, the Office logo, SharePoint, SQL Server, Windows, the Windows logo, Windows NT, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Zero Touch Installation Deployment Feature Team Guide iii

Contents

Using This Guide.........................................................................................7

Setting Up the Team..................................................................................................7

Communication...................................................................................................7

Additional Guidance on Team Models..................................................................7

Introduction................................................................................................7

Background...............................................................................................................8

Prerequisites..............................................................................................................9

Determining When Lite Touch Deployment Is Appropriate........................................9

ZTI Deployment Process Overview.............................................................10

Identifying the Project Milestones............................................................................10

Envisioning...............................................................................................12

Planning...................................................................................................12

Roles and Responsibilities.......................................................................................14

Milestones and Deliverables in the Planning Phase.................................................14

Selecting the Appropriate Deployment Scenario.....................................................14

Refresh Computer Scenario..............................................................................15

New Computer Scenario...................................................................................16

Replace Computer Scenario..............................................................................17

Ensuring That the Required Infrastructure Exists....................................................20

Sufficient SMS 2003 Infrastructure....................................................................20

Providing Sufficient Storage for User State Migration Data...............................21

Providing Sufficient Storage for Deployment Logs............................................22

Using Remote Installation Services...................................................................22

Verifying Adequate Workstation Configuration..................................................23

Providing Adequate Network Capacity..............................................................24

Determining the Appropriate ZTI Processing Rules.................................................24

Identifying How ZTI Processing Rules Are Used................................................24

Identifying the Required ZTI Configuration Settings.........................................26

Prioritizing the ZTI Processing Rules.................................................................26

Determining the Group-Based ZTI Processing Rules.........................................29

Determining Workstation-Based ZTI Processing Rules......................................31

Including Custom Exit Functions.......................................................................36

Including Custom-Stored Procedures................................................................36

Training Team Members...........................................................................................37

Obtaining Consensus for Deployment Plans............................................................38

Developing...............................................................................................38


Milestones in the Developing Phase........................................................................40

iv Solution Accelerator for Business Desktop Deployment

Preparing the RIS Server.........................................................................................41

Disabling Creation of the Windows PE Computer Account in Active Directory. .42

Disabling Windows PE Logging on the RIS Server.............................................42

Automating the RIS Client Installation Wizard...................................................43

Installing Solution Accelerator for BDD...................................................................46

Installing the SMS 2003 OSD Feature Pack.......................................................46

Installing ZTI Files.............................................................................................47

Installing USMT 2.6...........................................................................................48

Installing the AdminDB Console........................................................................49

Configuring the Appropriate Resource Access.........................................................50

Configuring Client Access Accounts..................................................................51

Creating Additional Shared Folders...................................................................53

Configuring Shared Folder Permissions.............................................................54

Configuring Access for Deployment Phases......................................................54

Configuring the ZTI Operating System Image.........................................................57

Configuring the Validation Phase Actions..........................................................57

Configuring the State Capture Phase Actions...................................................58

Configuring the Preinstall Phase Actions...........................................................60

Configuring the Postinstall Phase Actions.........................................................61

Configuring the State Restore Phase Actions....................................................61

Creating the ZTI OS Image Installation CD..............................................................63

Configuring ZTI Processing Rules............................................................................64

Configuring Group-Based Rules in Customsettings.ini......................................64

Modifying the AdminDB Database Schema.......................................................65

Configure Workstation-Based Rules..................................................................67

Updating ZTI Processing Rules in the SMS OSD Feature Pack Image................69

Preparing the Windows PE CDs and Images............................................................69

Adding Support to Windows PE for Additional Network Adapters......................70

Adding WMI Support to Windows PE.................................................................70

Creating A Customized Windows PE Image.......................................................70

Transferring Windows PE CD Images to the RIS Servers...................................71

Adding Support to the RIS Image for Additional Network Adapters..................72

Stabilizing................................................................................................72

Identifying Roles and Responsibilities.....................................................................73

Identifying Milestones in the Stabilizing Phase........................................................73

Performing Lab Tests and Pilot Deployments...........................................................74

Preparing Deployment Teams..................................................................................75

Deploying.................................................................................................75


Zero Touch Installation Deployment Feature Team Guide v

Milestones in the Deploying Phase..........................................................................77

Running the Deployment Wizard.............................................................................77

Transitioning to Operations.......................................................................77


Milestones in the Transition to Operations..............................................................78

Preparing for the Transition.....................................................................................78

Communicating the Current Deployment Status.....................................................78

Additional Resources.................................................................................79

Appendix A: Sample Customsettings.ini Files.............................................80

Settings in Customsettings.ini Only.........................................................................80

Workstation Settings in AdminDB Database Only...................................................81

Workstation Settings in AdminDB Database and Customsettings.ini......................83

Appendix B: Customsettings.ini Reference.................................................85

Configuring the [Settings] Section..........................................................................85

Priority...............................................................................................................86

CustomKeysUserData........................................................................................86

CustomKeysSysprep..........................................................................................87

OSDVariableKeys...............................................................................................87

ScanStateArgs...................................................................................................88

LoadStateArgs...................................................................................................88

UserExit.............................................................................................................88

Example:...........................................................................................................89

Configuring the [SysprepInfMapping] Section.........................................................89

Configuring the [DefaultGateway] Section..............................................................89

Configuring Custom Sections..................................................................................90

Configuring Database Section.................................................................................91

Appendix D: AdminDB Database Schema....................................................94

Appendix E: AdminDB .csv File Format Reference.......................................96

Appendix F: ZTI Scenario Process Flowcharts.............................................98

Appendix G: Sample User Exit Function....................................................101

Appendix H: Training Resources...............................................................103

Appendix I: Resolving Common ZTI Deployment Problems.........................105

Troubleshooting General Deployment Problems.............................................105

Troubleshooting PXE Boot Related Issues in RIS..............................................105

Troubleshooting Failed New Computer Scenario DeploymentFailure to Copy Log Files to Shared Folders....................................................................................106

Identifying Error Codes Returned by Zerotouchinstallation.vbs......................107

Appendix J: Deploying Windows XP Using Windows Product Activation......108

Appendix K: Sample Stored Procedure Calls................................................................109

vi Solution Accelerator for Business Desktop Deployment

Using This GuideThis guide is intended to be used as a part of Microsoft® Solution Accelerator for Business Desktop Deployment (BDD) and is designed to guide a specialist team through Solution Accelerator for BDD deployment tasks and checkpoints. The goal is to ensure that the deployment is managed as a specific initiative of the specialist team within the scope of a larger deployment project. This approach is used to make certain that the decisions taken within this initiative align with the overall project goals and that the deliverables are well integrated into the total migration project.

Setting Up the TeamThe specialist team responsible for ensuring the success of this initiative is the Deployment feature team. A feature team is a cross-organizational team responsible for solving a defined problem. Within the Solution Accelerator for BDD project, the Deployment feature team is one of several feature teams that work with a lead team.

Feature teams are an important component of the Microsoft® Solutions Framework (MSF) Team Model. The ability to split a large and complex project into smaller sets of related tasks allows work to be performed on many tasks in parallel, with the application of specialized expertise where needed. A great advantage of this approach is an enhanced ability to manage large projects with many simultaneous tasks.

For the approach to work, however, it is vitally important that the teams synchronize their efforts and maintain active communications among the feature teams and with the project management team. Such communication is particularly important in complex projects, where a feature team may focus on its portion of the project to the unintentional and undesirable exclusion of the role that team members play in the overall project.

CommunicationKey to successful project implementation is each feature team member’s ability to cooperate and communicate internally, on the one hand, and with other feature or function teams within the project and project stakeholders on the other. Within the team, each role has equal importance, even though the roles may vary. Important team decisions are characterized by joint decision-making.

Across teams and from individual feature teams to the project management team (defined as the lead team in this document), the process is more formal, with well-defined pathways of communication. This formality does not prevent informal communication between the teams, which is encouraged, but does ensure that significant communications are well documented, occur at the appropriate level, and are directed to the appropriate team members.

An important consideration for feature teams is communicating with the project stakeholders, which typically include various entities within the customer organization. To avoid confusion, incomplete or conflicting messages, or misunderstood expectations, the lead team must act as the official project voice to the stakeholders. In this way, management is always aware of the state of the customer relationship, and customer satisfaction during the deployment process is enhanced.

Additional Guidance on Team ModelsFor additional guidance on team models, see MSF Team Model in the Additional Resources section of this guide.

IntroductionThis guide contains detailed information about how to deploy Microsoft® Windows® XP Professional, Windows XP Tablet PC Edition, and Office 2003 Editions using Solution Accelerator for BDD. The document shows how the automated deployment process should be run to successfully replace previous Windows operating systems with Windows XP.

This process takes advantage of and combines the results of the other processes in the Solution Accelerator for BDD solution to accomplish the following tasks:

Collect hardware and software inventory information by using Microsoft® Systems Management Server (SMS) 2003 with Service Pack 1 (SP1).

Migrate existing user profile information by using the Microsoft® Windows® User State Migration Tool (USMT) version 2.6.

Installing a Windows XP Professional or Windows XP Tablet PC Edition operating system image on workstations automatically by using the SMS Operating System Deployment (OSD) Feature Pack, the Zero Touch Installation (ZTI) scripts, and the ZTI Administration Database (Admin DB).

Monitor the deployment process by using Microsoft® Operations Manager (MOM) 2005 and Solution Accelerator for BDD Reporting.

Optionally, copy existing user data and preferences from the workstation to a network deployment server.

Optionally, create a backup image of the user workstation to a network deployment server.

Re-partition and format the existing primary hard drive.

Install a Windows XP Professional or Windows XP Tablet PC Edition operating-system image that includes enterprise applications such as Office 2003 Editions.

Dynamically install applications that are specific to the workstation model, such as DVD software.

Automatically install previously packaged software specific to the user of the workstation.

Optionally, restore the user data and preferences that were previously stored on the network deployment server.

In addition, this process provides guidance on deciding where to place deployment servers and other planning information.

BackgroundThe work described in this guide typically starts in the MSF Planning phase after a commitment to plan the deployment has been established. The work will continue through the Deploying phase, where the workstations are actually re-deployed using the new Windows images.

The MSF Release Management Role Cluster is the primary consumer of the work, because most of this document focuses on the actual deployment in the production environment. The Release Management feature team will need to work closely with all the other feature teams to ensure a timely and successful deployment.

Zero Touch Installation Deployment Feature Team Guide 9

PrerequisitesInstalling, configuring, and using this process for deploying Windows XP operating systems require personnel who understand and meet certain prerequisites. Those who execute this deployment process should be familiar with the following concepts:

USMT 2.6

SMS 2003 with SP1

SMS OSD Feature Pack

MOM 2005

Remote Installation Services (RIS)

Microsoft® Windows® Preinstallation Environment (Windows PE) supplied with the SMS OSD Feature Pack

Application Compatibility Toolkit (ACT)

CD image creation

Network infrastructure, including routers, switches, and firewalls

Networking services infrastructure, including Domain Name System (DNS), Dynamic Host Configuration Protocol (DHCP), Windows Internet Naming Service (WINS), and remote access

Active Directory® directory service infrastructure, including logical and physical design of infrastructure

Server capacity planning

Workstation image creation

Automated application installation

The Release Management feature team will rely heavily on the development teams that created the workstation images, USMT process, application packages, network analysis, application remediation strategies, and hardware inventories to act as escalation contacts for troubleshooting and resolving problems that arise during the deployment.

Determining When Lite Touch Deployment Is AppropriateThe Solution Accelerator for BDD ZTI deployment process may be inappropriate for deploying certain desktops within your environment. For scenarios in which ZTI deployment is inappropriate, use the ”lite touch” deployment process, instead. These scenarios include:

Workstations are not managed by SMS or no SMS infrastructure exists.

Network capacity is nonexistent or insufficient for ZTI.

Security policies prohibit automatic software installation.

Clients are remote from image distribution point services.

Firewalls prohibit communication.

For more information about lite touch deployment, see the Lite Touch Deployment Feature Team Guide, Enterprise Edition in the Additional Resources section of this guide.

10 Solution Accelerator for Business Desktop Deployment

ZTI Deployment Process OverviewBefore you begin your deployment process, you need to identify the high-level steps in the Solution Accelerator for BDD ZTI deployment process. Figure 1 illustrates the Solution Accelerator for BDD ZTI deployment process.

Figure 1. The Solution Accelerator for BDD ZTI deployment process

The steps within the Solution Accelerator for BDD ZTI deployment process are grouped by the corresponding MSF phases in your project. Based on your MSF role, you may need to read only portions of this documentation. However, in most instances, you should read all the sections in this guide.

Identifying the Project MilestonesAs a part of the Solution Accelerator for BDD ZTI deployment process, you need to identify the project milestones that must be completed for a successful deployment. Table 1 lists the high-level project milestones included in a Solution Accelerator for BDD ZTI deployment by MSF phase and a description of each milestone. Each high-level project milestone is covered in a section later in this guide and has subordinate milestones that are discussed in the corresponding section.


Table 1. High-Level Project Milestones and Their Descriptions

High-Level Milestone Description

Planning

Appropriate deployment scenario selected

The appropriate combination of scenarios (new computer installation, computer refresh, or computer replacement) is identified.

Required infrastructure exists Prerequisite technologies and infrastructure to support the deployment exist.

Monitoring plan completed The list of servers, services, and system resources to be monitored is created. The frequency of monitoring is also decided.

Operations and Deployment feature teams trained

Any training required by the Operations and Deployment feature teams occurs to ensure that both teams are ready by the time deployment occurs.

Consensus for deployment plan obtained

All stakeholders in the Solution Accelerator for BDD project provide consensus for acting on the deployment plan and future project milestones.

Developing

Solution Accelerator for BDD installed

Solution Accelerator for BDD is installed on the appropriate servers.

Appropriate resource access assigned

Shared resources (such as shared folders for user migration data) are configured to allow access to the appropriate service accounts.

SMS OSD Feature Pack packages and programs configured

Each phase of the SMS 2003 OSD Feature Pack deployment (Validation, State Capture, Preinstall, Postinstall, State Restore) is configured to used the ZTI script.

ZTI processing rules configured Rules for processing the ZTI installation are configured and stored in the appropriate location for deployment.

Reference Computer Images created Images that the SMS 2003 OSD Feature Pack uses for deploying the operating system are created (also known as golden images or master images).

Windows PE CDs prepared CD images used to create boot CDs or that are applied to RIS servers are created.

Stabilizing

Lab tests and pilot deployments completed

The deployment process is validated in test labs. Further validation occurs during one or more pilot deployments. Any modifications to the deployment process are incorporated prior to production deployment.

Deployment teams prepared Deployment teams are debriefed on the outcome of the lab tests and pilot deployments. Any common deployment issues, troubleshooting tools, and remedies are communicated to the team.


Deploying

SMS 2003 OSD Feature Pack Deployment Wizard run

Deployment of images to workstations is initiated.

Transitioning to Operations

Transition preparations completed Notification of the transition date is established, and users are notified of the change in support (Deployment feature team to Operations feature team).

Current status of deployment communicated

The current list of migrated workstations, workstations that were unable to migrate, and current processes for resolving deployment issues is communicated from the Deployment feature team to the Operations feature team.

EnvisioningThe assumption of this guide is that the Envisioning phase of your deployment project is complete. This guide assumes that you have already chosen to use Solution Accelerator for BDD in your workstation deployment.

PlanningFigure 2 illustrates the primary activities that occur during the Planning phase. While other teams are developing images, project plans, and so on, the Release Management feature team is starting to focus on the existing production environment to decide how to approach the deployment. The team must look at all the locations and departments whose workstations will be upgraded and must decide in what order the upgrades will occur.


Figure 2. Activities during the Planning phase

The following sections describe the planning process:

Roles and Responsibilities

Milestones and Deliverables in the Planning Phase

Selecting the Appropriate Deployment Scenario

Ensuring That the Required Infrastructure Exists

Planning How To Monitor the Deployment

Determining the Appropriate ZTI Processing Rules

Training Team Members

Obtaining Consensus for Deployment Plans


Roles and ResponsibilitiesAll six role clusters from the MSF Team Model play a role in the Planning phase of the initiative. Table 2 lists those roles and defines the focus areas for each role cluster relative to the deployment process in the Planning phase.

Note For more information about MSF team role clusters, see MSF Team Model in the Additional Resources section of this guide.

Table 2. Team Roles and Responsibilities in the Planning Phase

Role Focus

Product management

Business requirements analysis; communications plan

Program management

Master project plan and master project schedule; budget

Development Technology evaluations; logical and physical design; development plan and schedule; establishing the lab

User experience Usage scenarios/use cases; user requirements; localization/accessibility requirements; user documentation; training plans; schedules

Test Testing requirements definition; test plan and schedule

Release management

Operations requirements; pilot and deployment plan/schedule; network discovery; application and hardware inventory; interfacing with operations and security feature teams

Milestones and Deliverables in the Planning PhaseTable 3 lists the project milestones and deliverables that you need to complete during the Planning phase. The project plan you create needs to include these milestones, the resources required for each milestone, and the length of time to complete each milestone.

Table 3. Planning Phase Project Milestones and Deliverable Description

Planning Phase Milestone

Deliverable Description Owner

Appropriate deployment scenario selected

The appropriate combination of scenarios (new computer installation, in-place upgrade, or side-by-side upgrade) is identified.

Development

Required infrastructure exists

Perquisite technologies and infrastructure exists for performing the deployment.

Development

Monitoring plan complete

The list of servers, services, and system resources to be monitored is created. The frequency of monitoring is also decided.

Development

Teams trained Any training required by the Operations and Deployment feature teams occurs to ensure that both teams are ready by the time deployment occurs.

Program management

Consensus for deployment plan obtained

All stakeholders in the Solution Accelerator for BDD project provide consensus for acting on the deployment plan and future project milestones.

Product Management


Selecting the Appropriate Deployment ScenarioAs the first step in the Planning phase, choose the appropriate deployment scenario. Table 4 lists the deployment scenarios and provides a brief description of each scenario.

Table 4. Deployment Scenarios and Description

Scenario Description

Refresh Computer A computer currently running a supported Windows operating system is refreshed to Windows XP. This scenario includes Windows XP systems that need to be re-imaged for company image standardization or to address a problem. This scenario assumes that you are preserving the existing user data and profile on the computer.

New computer A new installation of Windows XP is deployed to a new computer This scenario assumes that there is no user data or profile to preserve.

Replace Computer A new installation of Windows XP is deployed to a new computer based on the user data and profile on an existing computer. This scenario assumes that you are migrating the existing user data and profile to the new computer.

Based on your existing environment, you can select any combination of these scenarios in your deployment. For example, if your organization is only upgrading existing workstation, you need only the Refresh Computer scenario. If your organization is deploying new workstations for some the users and upgrading the remaining workstations, you need to use the New Computer and Refresh Computer scenarios.

Refresh Computer ScenarioIn this scenario, you replace an existing Windows operating system on an existing workstation with a new Windows operating system image. You must preserve the user data and profile during the process. To perform this method of installation, ensure that sufficient available disk space exists, either locally or on a network drive, to back up the user data and profile. For more information about determining workstation requirements, see Verifying Adequate Workstation Configuration later in this guide.

Note For performance reasons, back up the user data and profile locally whenever possible.

Figure 3 illustrates the steps in the Refresh Computer scenario.


Figure 3. Refresh Computer deployment process

New Computer ScenarioIn this scenario, you install a new copy of Windows XP on a new workstation. To perform this method of installation, complete one of the following procedures:

If the target workstation does not have an operating system, you can install Windows XP by starting Windows PE (from RIS or from a local CD).

If the target workstation has an operating system that SMS does not manage, you can install Windows XP by starting Windows PE (from RIS or from a local CD).

If the target workstation has an operating system that SMS manages, you can install Windows XP by using the same process described in the Refresh Computer scenario. However, you can skip the steps that relate to migrating the user data and profiles.

Figure 4 illustrates the steps in the New Computer installation scenario.


Figure 4. New Computer deployment process

Replace Computer ScenarioIn this scenario, you install Windows XP on a new computer. However, you also need to migrate the user data and profile from an existing workstation. To perform this method of installation, ensure that sufficient available disk space exists on a network drive to back up the user data and profile. For more information about determining workstation requirements, see Verifying Adequate Workstation Configuration later in this guide.

Figure 5 illustrates the steps in the Replace Computer scenario.


Figure 5. Replace Computer Deployment Process

To perform a Replace Computer scenario, follow these steps:

Capture the user state information.

Deploy the new computer with user state information.

Capturing the User State InformationDuring this part of the Replace Computer scenario, an SMS package is sent to the workstation that captures the users state information on that computer.

Note The operating system package and program cannot be used to capture user state information from the old computer. For more information about SMS OSD Feature Pack phases, see Configuring the ZTI Operating System Image later in this guide.

To capture the user state information, perform the following steps:

1. Create the SMS package that captures user state migration information.

2. Create the SMS program that captures user state migration information.

3. Run the SMS package on the workstations.


Creating the SMS Package That Captures User State Migration Information

To create the SMS package that captures user state migration information, perform the following steps:

1. Copy the files required for creating the SMS package, which are listed in Table 5, to \\servername\Packages\OldComputer (where servername is the computer name of the server hosting the shared folder).

The package sent to the workstation must include the files listed in Table 5. These files are required to capture the user state information. Table 5 also lists where these files reside (where servername is the name of the server hosting the shared folder). Copy these files into a folder that you will use to create the package.

Table 5. Files Required for Creating the SMS Package To Capture User State Information

Files Location

Zerotouchinstallation.vbs \\servername\ZTI

Customsettings.ini \\servername\ZTI

All USMT files \\servername\USMT\*.*

Updateuser.inf \\servername\ZTI

Note By default USMT is installed into the C:\USMT\Bin directory, so be sure to point your USMT share to the Bin folder to be able to access the source files. The ZTI shared folder is created by sharing the folder were you installed ZTI.

2. In the SMS Administrator Console, navigate to the Packages node.

3. Right-click the Packages node, click New, and then click Package.

4. Complete the Package Property dialog box by using the information in Table 6, and then click OK.

Table 6. Information Required To Complete the Package Property Dialog Box

On This Tab Do This

General In the Name text box, type Zero Touch Installation – Old Computer.

Data Source Select the This package contains source files check box.

In the Source directory area, click Set.

In the Source Set Directory dialog box, in the Source directory text box, type \\servername\Packages\OldComputer (where servername is the name of the server hosting the shared folder and OldComputer is the name of the folder containing the package source), and then click OK.

Note The Packages shared folder contains the all of the source files used to create the OSD packages. You need to create a folder beneath Packages for each package that you need to deploy.

Creating the SMS Program That Captures User State Migration Information

To create the SMS program that captures user state migration information, perform the following steps:

1. In the SMS Administrator Console, navigate to Package (where Package is the package you created in the previous procedure).

2. Expand Package (where Package is the package you created in the previous procedure), right-click Programs, click New, and then click Program.


3. Complete the Program Property dialog box by using the information in Table 7, and then click OK.

Table 7. Information Required To Complete the Program Property Dialog Box

On This Tab Do This

General In the Name text box, type OldComputer.

In the Command line text box, type Wscript.exe //b Zerotouchinstallation.vbs /phase:OldComputer.

Environment In the Program can run text box, select Whether or not a user is logged on.

Select the Allow users to interact with this program check box.

Running the SMS Package on the Workstations

After you have created the SMS package and program, you need to distribute them to and run them on the workstations. To distribute the SMS package, perform the following steps:

1. Distribute the package to all distribution points.

2. Create an SMS collection of workstations that need the package.

3. Create an advertisement to the SMS collection to distribute the package to the workstations.

Note For more information about how to complete these tasks, see SMS 2003 Administrator Help topics in the SMS Administrator Console.

Deploying the New Computer with User State InformationThe remainder of the Replace Computer scenario is similar to the New Computer scenario except that the user state information collected is restored to the new computer.

Ensuring That the Required Infrastructure ExistsBefore you can use Solution Accelerator for BDD to deploy Windows XP, you must ensure that the infrastructure that Solution Accelerator for BDD requires exists. For most production environments, the majority of the services required for your deployment already exists, but verify that all the following components are in place before you continue the deployment process.

Sufficient SMS 2003 InfrastructureSolution Accelerator for BDD requires that your infrastructure includes SMS 2003, so ensure that all servers running SMS within your organization are running that version. In addition, Solution Accelerator for BDD has the following requirements specific to SMS 2003:

SMS 2003 with SP1. SMS 2003 with SP1 is required on all SMS site servers within your infrastructure before you begin deployment. For more information about upgrading your infrastructure to SMS 2003 with SP1, see SMS 2003 SP1 Product Overview in the Additional Resources section of this guide.

SMS 2003 OSD Feature Pack. You must install the SMS 2003 OSD Feature Pack on one or more site servers within your 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 workstations 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 Additional Resources section of this guide.


Identifying the Storage Requirements for Distribution PointsWhen your server is running SMS 2003 with SP1 and you have installed the SMS 2003 OSD Feature Pack, you need to ensure you have sufficient available storage on your distribution points for the images that the SMS 2003 OSD Feature Pack creates. Determine the size of each image and the number of images required in your deployment.

Create a unique image for:

Each unique Hardware Abstraction Layer (HAL) required in the workstations targeted for deployment

Each localized operating system language version required (such as Chinese simplified or Japanese)

For planning purposes, you can estimate the size of an image to be within the range of 500 MB to 4 GB, including applications. If you have 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 PointsIf you are not able to increase the available disk space on your distribution points, you need to reduce the storage requirements for those distribution points. You can reduce the available storage requires for the distribution points by using any combination of the following methods:

Reduce the number of images. If a limited number of workstations have a specific HAL, consider another method of installing Windows XP on them (such as the Lite Touch 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 XP. When possible, deploy MUI versions of Windows XP to reduce the number of images required as a result of language differences. Avoid using the localized version of Windows XP.

Providing Sufficient Storage for User State Migration DataDetermine the amount of storage required for the user state migration data that the USMT saved during the deployment process. When you know the amount of storage required, designate local storage on the workstation or shared folders that can be use as a temporary store for user migration data.

Determining Storage Requirements for User State Migration DataFor planning purposes, you can estimate the user state migration storage requirements by:

Running Scanstate.exe in the USMT with the /p command switch to estimate the size of the user state migration data. The /p command switch allows you to estimate the disk space requirements without actually performing the migration. You must also specify /compress- when using the /p switch. For more information, refer to the 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 \Documents and Settings\username folders. You can randomly sample targeted workstations to determine an average amount of storage required to back up the user state migration. Keep in mind that there could be several


profiles (username folders) on each workstation, so you will need to include each profile you plan to migrate.

You also need to know how long the user state migration data must be persisted. You need to persist the user state migration data in the event that the upgrade fails and you must roll back the configuration. After you have verified a successful upgrade, you 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 workstations being upgraded (size of migration × number of simultaneous workstations).

Determining Where To Store User State Migration DataAfter you have determined 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 workstation to reduce the time to deploy Windows XP and network utilization (recommended).

Note You can 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 you elect to store user migration data on the local workstation, you need to 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.) 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 workstations.

Providing Sufficient Storage for Deployment LogsThe deployment logs record the process for each workstation through the image-distribution process. Determine the amount of storage required for the deployment logs saved during the deployment process. When you know the amount of storage required, designate shared folders that can be used as temporary stores for deployment logs.

Determining Storage Requirements for Deployment LogsFor planning purposes, you can estimate the deployment log storage requirements for a single workstation by performing the following steps:

1. Run the upgrade process in your test lab to determine the size of the deployment logs.

2. Determine how long the deployment logs need to be persisted.

3. Multiply the size of the deployment logs for one workstation times the number of workstations being upgraded simultaneously.

Determining Where To Store Deployment LogsAfter you have determined 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 workstations by a high-bandwidth connection.


Using Remote Installation ServicesYou can use RIS to deploy Windows PE to prepare the workstation for deployment. Do so when SMS does not manage the workstation, when a workstation is not running the SMS Advanced Client, or when a workstation has no operating system. Using the SMS 2003 OSD Feature Pack, you can create a custom Windows PE image that allows you to install Windows XP from the nearest SMS distribution point.

You can use RIS to automate the deployment of Windows PE:

For workstations that have a high-speed, consistent connection to a RIS server

In the New Computer and Replace Computer scenarios

Note You can install Windows PE to prepare the workstations by using RIS or by using a Windows PE CD locally on the workstations. These methods provide the same functionality. Use the CD method when RIS is unavailable, such as when workstations have low-bandwidth connections to the RIS servers.

Verifying Adequate Workstation ConfigurationBefore you can deploy an SMS 2003 OSD Feature Pack image to a workstation, you need to ensure that the workstation has the correct configuration. To deploy an image to a workstation, you must first:

Verify that the workstation has the correct versions of workstation software.

Verify that the workstation has adequate system resources.

Verifying Correct Workstation Software VersionsThe ZTI deployment process requires that your target workstations meet the following minimum software requirements for Refresh Computer and Replace Computer scenarios:

Workstations are running Microsoft® Windows® 98 Second Edition, Windows NT® 4.0 Service Pack 6a (SP6a), or a newer Windows operating system.

Workstations running Microsoft® Windows® 2000 Professional or a newer operating system have the SMS Advanced Client installed.

Workstations running Windows NT 4.0 SP6a or Windows 98 Second Edition have the SMS Legacy Client installed.

Workstations must be running Windows Script Host (WSH) version 5.6 or later.

Workstations must be running Microsoft Data Access Components (MDAC) version 2.0 or later.

Verifying Adequate Workstation ResourcesPrior to deploying Windows XP, ensure that the workstations targeted for deployment have adequate system resources. The following resources must be available on the workstations:

Minimal processor, memory, and available disk space required by Windows XP

Additional available disk space when user migration state data and deployment logs are stored locally on the workstation

Enough free disk space to hold Windows PE and SMS OSD Feature Pack log files (approximately 150 MB)

Enough total disk space to hold Windows PE, SMS OSD Feature Pack log files, and the image (expanded image size plus 150 MB)


Direct network connection to RIS servers, SMS site servers, and SMS distribution points (Unsupported network connections include virtual private network (VPN) and wireless connections.)

Note Workstations that attempt to run an SMS 2003 OSD Feature Pack package 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.

You can use SMS to help determine whether any existing workstations have inadequate system resources by using SMS queries and reports. You can upgrade these workstations prior to deploying Windows XP.

If you determine that some workstation system resources are inadequate for deploying Windows XP, you can perform one of the following actions:

Upgrade the system resources on the existing workstations.

Replace the existing workstations with new workstations.

Eliminate the existing workstations from being part of the upgrade.

Providing Adequate Network CapacityBecause of the size of the SMS 2003 OSD Feature Pack images being distributed to the workstations (500 MB–4 GB), your workstations 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

RIS servers

Servers hosting shared folders used to store user migration state data and deployment logs

These servers should be on adjacent subnets to the workstations to ensure high-speed connectivity to the workstations. If you are unable to provide sufficient network capacity to deploy to a workstation, perform one of the following actions:

Temporarily place the appropriate servers (for example, SMS distribution point, RIS server) closer to the workstation for the duration of the migration.

Temporarily move the workstations to a staging area where the workstations can be deployed and then returned to their original location.

Store user state migration data locally on the workstation.

Perform automated deployments locally by using a combination of a Windows PE CD or an SMS 2003 OSD Feature Pack image CD.

Determining the Appropriate ZTI Processing RulesThe ZTI deployment process uses rules to configure your workstations. You need to determine the appropriate ZTI processing rules based on your environment. You configure the ZTI processing rules by modifying the Customsettings.ini file and by creating entries in the ZTI Admin DB. During the MSF Developing phase, you will configure the ZTI processing rules. For more information about configuring the ZTI processing rules, see Configuring ZTI Processing Rules, later in this guide.

To determine the appropriate ZTI processing rules, perform the following steps:

1. Identify how ZTI processing rules are used to configure workstations.

2. Identify the required ZTI configuration settings.

3. Prioritize the ZTI processing rules.


4. Determine the group-based ZTI processing rules.

5. Determine the workstation-based ZTI processing rules.

6. Include any custom exit functions required to complete additional processing.

7. Include any custom stored procedures required to complete additional processing.

Identifying How ZTI Processing Rules Are UsedThe ZTI script (Zerotouchinstallation.vbs) uses the ZTI processing rules to automate workstation configuration. Figure 6 illustrates how ZTI processing rules are used.

Figure 6. Overview of how ZTI processing rules are used

The Zerotouchinstallation.vbs script applies the configuration settings to the target client computer. The script is deployed within the SMS OSD Feature Pack image to the client computer though an SMS distribution point.


The client computer follows this process to receive configuration information from the ZTI process:

1. The SMS 2003 site server distributes the SMS OSD Feature Pack image, including the Zerotouchinstallation.vbs script and the Customsettings.ini file, to the SMS 2003 distribution point.

2. The target client computer downloads the image and initiates the Zerotouchinstallation.vbs script.

3. The script examines the Customsettings.ini file included in the image and determines where to retrieve configurations settings.

4. If configuration settings are stored in ZTI Admin DB, the script retrieves the settings from both the Customsettings.ini file and from the database. Otherwise, only Customsettings.ini is used.

5. The target computer receives all the necessary configuration settings to complete an unattended installation

Rules known as group-based rules are applied to groupings of client computers. Other rules, known as client-based rules are applied to specific client computers. In most environments, you will need to specify group-based and client-based rules to provide all the necessary configuration parameters for ZTI.

The group-based rules are stored in the Customsettings.ini file, which is deployed with the ZTI script in the SMS OSD Feature Pack image to workstations. The client-based rules can be stored in a Microsoft® SQL Server™ database or in the Customsettings.ini file.

Note Throughout this section, you will see examples of how Woodgrove Bank determined the appropriate ZTI processing rules.

Identifying the Required ZTI Configuration SettingsYou need to determine which configuration settings, or parameters, you need to provide to the Zerotouchinstallation.vbs script. The Customsettings.ini file, as illustrated in the excerpt in Listing 1, defines the parameters you need in the following properties:

CustomKeysUserData

CustomKeysSysPrep

OSDVariableKeys

Priority= MACADDRESS, DefaultGateway, DefaultCustomKeysUserData=UDShare,UDDir,UDProfiles,SLShare,OSInstall,JoinDomainCustomKeysSysprep=ComputerName,TimeZone,JoinDomain,MachineObjectOUOSDVariableKeys=OSDINSTALLSILENT,OSDINSTALLPACKAGE,OSDINSTALLPROGRAM,OSDNEWMACHINENAME

.

.

.

Listing 1. Example of Configuration Settings Specified in the Customsettings.ini File

Ensure that you provide all the configuration settings in either group-based settings or workstation-based settings.

Note For the workstation to be deployed properly, all the configuration settings specified on the CustomKeysUserData, CustomKeySysPrep, and OSDVariableKeys properties must be defined in the Customsettings.ini file or in the ZTI Admin DB.


Prioritizing the ZTI Processing RulesYou can customize the order in which ZTI processing rules are processed. The priority you assign to group-based settings or workstation-based settings determines the ZTI processing rule order. The Priority attribute in the Customsettings.ini file, as illustrated in Listing 2, determines the order in which ZTI processing rules are processed.

There are two possible approaches to prioritizing ZTI processing rules. These approaches are:

Allow group-based configuration settings to take priority, and allow client-based configurations to provide any additional settings.

Allow client-based configuration settings to take priority, and allow group-based configuration settings to provide any additional settings.

Prioritizing Client-Based Configuration SettingsListing 2 illustrates an excerpt from a Customsettings.ini file in which the client-based configuration settings take precedence (that is, have the highest priority). In that example, MACADDRESS refers to later sections that correspond to a workstation Media Access Control (MAC) address. Any configuration settings found in the client-specific sections are used, and all subsequent instances in the priority list are ignored.

For example, if ComputerName were located in the client-specific section, Zerotouchinstallation.vbs will use that value and ignore any subsequent entries for ComputerName in the DefaultGateway and Default sections.

Priority= MACADDRESS, DefaultGateway, DefaultCustomKeysUserData=UDShare,UDDir,UDProfiles,SLShare,OSInstall,JoinDomainCustomKeysSysprep=ComputerName,TimeZone,JoinDomain,MachineObjectOUOSDVariableKeys=OSDINSTALLSILENT,OSDINSTALLPACKAGE,OSDINSTALLPROGRAM,OSDNEWMACHINENAME

.

.

.

Listing 2. Example in Which Client-Based Settings Take Precedence

Prioritizing Group-Based Configuration SettingsListing 3 provides an excerpt from a Customsettings.ini file in which the group-based configuration settings take precedence (that is, have the highest priority). In this example, DefaultGateway refers to later sections that correspond to a group of workstations that have the same default gateway. Any configuration settings found in the group-specific sections are used, and all subsequent instances in the priority list are ignored.

For example, if UDShare was located in one of the DefaultGateways sections, Zerotouchinstallation.vbs will use that value and ignore any subsequent entries for UDShare in the SQL and Default sections.


Priority= DefaultGateway, SQL, DefaultCustomKeysUserData=UDShare,UDDir,UDProfiles,SLShare,OSInstall,JoinDomainCustomKeysSysprep=ComputerName,TimeZone,JoinDomain,MachineObjectOUOSDVariableKeys=OSDINSTALLSILENT,OSDINSTALLPACKAGE,OSDINSTALLPROGRAM,OSDNEWMACHINENAME

.

.

.

Listing 3. Example in Which Group-Based Settings Take Precedence

Prioritizing Default Configuration SettingsThe default section is useful to specify default values for any variable not assigned a value by any preceding sections. The inclusion of a [Default] section is a best practice to ensure all required variables are set for a target computer. The configuration settings referenced by the Default keyword apply to all client computers.

You can use the default configuration settings to supply one of the following:

Global configuration settings that apply to all workstations.

When configurations settings are not supplied by group-based or workstation-based configuration settings, the Default configuration settings are applied to define the remaining settings.

Supplying Global Configuration Settings

There are instances in which you want to apply configuration settings to all workstations. To do so, place the Default section at the beginning of the Priority attribute list, as Listing 4 shows.

Priority= Default, DefaultGateway, SQL ...

Listing 4. Example of How To Use Default To Apply Global Configuration Settings

By placing the Default keyword at the beginning of the Priority attribute list, the configuration settings in the [Default] section override the same configuration settings in the [DefaultGateway] sections and configuration settings stored in ZTI Admin DB (as designated by the SQL keyword in Listing 4).

Supplying Default Configuration Settings

Another way you can use the Default settings is when you want to supply default configuration settings. You would do so when a workstation is unable to find all the configuration settings in the existing group-based and workstation-based configuration settings. To use the settings in this way, place the Default keyword at the end of the Priority attribute list, as Listing 5 shows.

Priority= DefaultGateway, SQL, Default...

Listing 5. Example of How To Use Default To Apply Default Configuration Settings

By placing the Default keyword at the end of the Priority attribute list, the configuration settings in the [Default] section are used only if the configuration settings were not found in the


[DefaultGateway] sections or in the configuration settings stored in ZTI Admin DB (as designated by the SQL keyword in Listing 5).

Determining the Group-Based ZTI Processing RulesWhenever possible, use group-based rules for the majority of your workstation configuration settings. Group-based rules allow you to apply the same configuration settings to a group of workstations. After you apply group-based rules, you can apply workstation-specific configuration settings through workstation-based rules.

Determine the appropriate group-based ZTI processing rules to include by:

Identifying the appropriate workstation groupings

Identifying the group-based configuration settings

Identifying the Appropriate Workstation GroupingsYou can group your workstations based on different criteria. Table 8 lists the predefined workstation groupings. In addition to these groupings, you can create custom workstation groupings.

Table 8. Methods for Grouping Workstations, How Computers Are Grouped, and What the Grouping Determines

Method Groups Computers Determines the

[DefaultGateway] Geographically Resources (distribution points, file shares, etc.) that are on adjacent subnets to the workstation

[Make], [Model], [AssetTag], [SerialNumber], [UUID]

According to hardware configuration

Specific hardware attributes (such as HAL types) to select the appropriate images for deployment

Existing operating system

According to existing software

Appropriate images to deploy and potential configuration settings to migrate

[Default] In absence of other groupings

Configuration settings in the event the workstation falls outside all other groupings

Configuration settings to be applied to the entire organization

In most instances, the workstation groupings can be nested. For example, the [DefaultGateway] key can be used to designate the Internet Protocol (IP) subnets on which a computer resides within a geographic location. You can define location by using the settings beneath [DefaultGateway]. In Listing 6

Note When grouping computers by hardware configuration, you can use a variety of different methods and the script will search for the substituted value. For instance if you specify Priority=Make, the script would substitute the Make value it determines through a WMI call and look for the corresponding section, for instance [Dell Computer Corporation].

Example: Workstation Groupings Selected by Woodgrove

Listing 6 shows an example of how [DefaultGateway] can be used to designate the configuration settings for a specific location. Three subnets (172.16.0.3, 172.16.1.3, and 172.16.2.3) reside within the NYC location. A separate section, [NYC], includes the configuration settings that are specific to the NYC location. Similar sections exist for the DALLAS and WASHINGTON locations. This is a special case allowing multiple default gateways to point to the same section. In many


environments, you might expect a one-to-one mapping between default gateway and a corresponding section.

[DefaultGateway]172.16.0.3=NYC172.16.1.3=NYC172.16.2.3=NYC172.16.111.3=DALLAS172.16.112.3=DALLAS172.16.116.3=WASHINGTON172.16.117.3=WASHINGTON

[NYC]UDShare=\\NYC-AM-FIL-01\MigDataSLShare=\\NYC-AM-FIL-01\LogsPackages1=NYC00010-InstallPackages2=NYC00011-InstallAdministrator1=WOODGROVEBANK\NYC Help Desk Staff

[DALLAS]UDShare=\\DAL-AM-FIL-01\MigDataSLShare=\\DAL-AM-FIL-01\LogsAdministrator1=WOODGROVEBANK\DAL Help Desk Staff

Listing 6. How [DefaultGateway] Can Be Used To Designate Location-Specific Configuration Settings

Note The complete source to the Customsettings.ini file used in these examples can be found in Settings in Customsettings.ini Only in Appendix A, Sample Customsettings.ini Files, of this guide.

Identifying the Group-Based Configuration SettingsAfter you have identified the ways you want to group configuration settings, you need to determine which settings you will apply to each group. Table 9 lists the common group-based configuration settings and the purpose of those settings. A configuration setting may appear under one or more groups. However, the first configuration setting instance is the one used to configure the workstation. Subsequent instances are ignored.

Table 9. Common Group-Based Configuration Settings and Their Description

Setting Description

UDShare Universal Naming Convention (UNC) path to the shared folder in which the USMT will save user migration data

SLShare UNC path to the shared folder in which the ZTI scripts will store log files

Packagesx Packages to be deployed to workstations in that group, for example Packages1 or Packages2.

In addition to the dynamic list of packages that you can install through Packagesx, you can install a static list of packages by using the Run SWD Program action in the State Restore Phase. These methods of installing packages differ as follows:

Using the Packagesx setting in Customsettings.ini allows you to dynamically control the packages deployed to workstations, so that you can determine which combination of applications is installed on a workstation.

When you use the Run SWD Program, every user who installs a package installs the same list of applications within that package. As a result, you need to create a new program for each different combination of applications you want to deploy.


When you use either method of installing the packages, you must ensure that the SMS package programs:

Are enabled

Require no user intervention

Can run unattended from a UNC path

Have source files

Note An additional requirement for dynamically installed packages is that they cannot initiate a reboot. For more information about the configuration settings available in Customsettings.ini, see Appendix B, Customsettings.ini Reference, later in this guide.

Example: Group-based Configuration Settings Selected by Woodgrove

Listing 6 shows an example in which Woodgrove Bank selected group-based configuration settings:

In the NYC and DALLAS locations, UDShare, SLShare, and Administrator1 are specified for each location.

The servers referenced by UDShare and SLSShare (NYC-AM-FIL-01 and DAL-AM-FIL-01) are located within each respective location.

The administrator accounts referenced by Administrator1 (WOODGROVEBANK\NYC Help Desk Staff and WOODGROVEBANK\DAL Help Desk Staff) are unique to each respective location.

In NYC, location-specific packages are designated by Packages1 and Packages2.

In DALLAS, SQLDefault specifies the default SQL Server computer for that location (DB_DAL).

Determining Workstation-Based ZTI Processing RulesAfter you have determined the group-based processing rules and configuration settings, you need to determine the workstation-based ZTI processing rules. The workstation-based rules allow you to override or augment group-based processing rules based on the priority of the workstation-based rules. For more information about determining the priority of ZTI processing rules, see Prioritizing the ZTI Processing Rules later in this guide.

Whenever possible, use group-based rules for the majority of your workstation configuration settings. Group-based rules allow you to apply the same configuration settings to a group of workstations. After you apply group-based rules, you can apply workstation-specific configuration settings through workstation-based rules.

Determine the appropriate group-based ZTI processing rules to include by:

Identifying the workstations that require workstation-based rules

Identifying the workstation-based configuration settings

Determining where to store workstation-based configuration settings

Identifying Workstations That Require Workstation-Based RulesMost workstations within your organization will require workstation-based rules because they require unique configuration information, such as computer name or IP address. However, in other instances, your workstations may be configured with automatically generated computer names (such as NYC-XP-xxxx, where xxxx is automatically generated for each computer by setup) or may use DHCP to assign IP addresses.


For workstations that:

Can be configured without workstation-specific settings, use group-based rules only.

Must be configured with workstation-specific settings, use a combination of group-based and workstation-based rules.

You need to specify a method of uniquely identifying the workstation and the configuration settings that you want to apply to the workstation. Table 10 lists some of the methods for identifying individual workstations and why you would use those methods. In addition, you can define a custom method for identifying workstations. For a complete list of methods for identifying workstations, see Appendix B, Customsettings.ini Reference, later in this guide.

Table 10. Methods for Identifying Individual Workstations and What the Grouping Determines

Method Use This Method When You Want To Identify Workstations by the

[MacAddress] MAC address of the primary network interface in the workstation. The format for MACAddress is xx:xx:xx:xx:xx:xx, where xx is any hexadecimal number (for example 00:03:FF:BB:FE:C1).

[AssetTag] Asset tag number associated with the workstation. The format for asset tag numbers is undefined.

[SerialNumber] Serial number of the workstation. The format for serial numbers is undefined.

[Make] Manufacturer of the workstation.

[Model] Model number of the workstation.

[Product] Field provided by the workstation manufacturer and returned by SMBIOS.

[UUID] Universal Unique Identifier (or GUID) of the workstation.

Example: Workstation Identification Method Selected by Woodgrove

Listing 7 shows an example of how Woodgrove Bank identified workstation-based configuration settings. In this instance, Woodgrove used the MAC address of the workstation to identify the corresponding configuration settings for the workstation (for example 00:03:FF:CB:4E:C2 and 00:0F:20:35:DE:AC). The configuration settings for each workstation are listed immediately after the section that corresponds to the workstation’s MAC address.

[00:03:FF:CB:4E:C2]OSDNEWMACHINENAME=WasW2K

[00:0F:20:35:DE:AC]OSDNEWMACHINENAME=HPD530-1OSDINSTALLPACKAGE=DAL00342OSDINSTALLPROGRAM=CustomXP

[00:03:FF:FE:FF:FF]OSDNEWMACHINENAME=BVMXPOSDINSTALLPACKAGE=NYC00002OSDINSTALLPROGRAM=SpecialXP

Listing 7. How Woodgrove Identified Workstations


Identifying the Workstation-Based Configuration SettingsAfter you have identified the methods you want use for identifying workstations, you need to determine which settings you will apply to the workstation. Table 11 lists the common workstation-based configuration settings and the purpose of those settings.

Table 11. Common Workstation-Based Configuration Settings and Their Description

Setting Description

OSDNEWMACHINENAME

Name to assign to the computer when the new operating system is installed. This variable is used in the new computer and replace computer installation scenarios when running the OS Image Installation CD or from RIS. In a refresh computer scenario, ZTI can rename the machine by including the “ComputerName=%OSDNEWMACHINENAME% line in the default section.

OSDINSTALLPACKAGE Unique ID of the OS Deployment package that the OS Image Installation CD or RIS should install. This is set by the custom program or script specified in the Operating System Image Installation CD Wizard

OSDINSTALLPROGRAM

Name of the OS Deployment Program that the OS Image Installation CD or RIS should install. This is set by the custom program or script specified in the Operating System Image Installation CD Wizard

Note For more information on Operating System Image Installation CD Wizard, see the Creating the ZTI OS Image Installation CD section later in this document. For more information about the configuration settings available in Customsettings.ini, see Appendix B, Customsettings.ini Reference, later in this guide.

A workstation-based configuration setting typically appears under only one workstation because the configuration setting is unique to that workstation. In instances in which a configuration setting is being applied to several workstations, use group-based processing rules, instead.

Remember that if a group-based setting has a higher priority and the configuration setting was found in that group, the workstation-specific settings are ignored. For more information about ZTI processing rule priority, see Prioritizing ZTI Processing Rules later in this guide.

Example: Group-Based Configuration Settings Selected by Woodgrove

Listing 7 above shows the workstation-based configuration settings that Woodgrove Bank selected. Table 12 lists the workstation-specific configuration settings applied to each workstation.

Table 12. Woodgrove Workstations and the Corresponding Configuration Settings

Setting Description

[00:03:FF:CB:4E:C2]

OSDNEWMACHINENAME is the computer name of the workstation after deployment (WasW2K).

[00:0F:20:35:DE:AC]

OSDNEWMACHINENAME is the computer name of the workstation after deployment (HPD530-1).

OSDINSTALLPACKAGE is the name of the workstation-specific package to be deployed to the workstation (DAL00342).

OSDINSTALLPROGRAM is the name of the workstation-specific SMS OSD program to run on the workstation (CustomXP).

[00:03:FF:FE:FF:FF]

OSDNEWMACHINENAME is the computer name of the workstation after deployment (BVMXP).

OSDINSTALLPACKAGE is the name of the workstation-specific


package to be deployed to the workstation (NYC00002).

OSDINSTALLPROGRAM is the name of the workstation-specific SMS OSD program to run on the workstation (SpecialXP).

Determining Where To Store Workstation-Based Configuration SettingsYou can store the workstation-based configuration settings in a SQL Server database that is administered by using the ZTI AdminDB database or in the Customsettings.ini file. Table 13 lists each method and the advantages and disadvantages of each method.

Table 13. Advantages and Disadvantages of Methods for Storing Workstation Configuration Settings

Method Advantages Disadvantages

ZTI AdminDB database

Provides centralized management of workstation-based configuration settings

Requires connectivity to the SQL Server machine managing the ZTI AdminDB database

Customsettings.ini Can be used for workstations that are unable to connect to the ZTI AdminDB database

Because the Customsettings.ini file is stored in the SMS OSD Feature Pack image, any update requires updates to the SMS OSD Feature Pack image.

Store workstation-based configuration settings in the:

ZTI AdminDB database by using the SQL keyword in the Priority attribute in the Customsettings.ini

Customsettings.ini file by creating a workstation-specific section for each corresponding workstation with unique configuration settings

Example: Configuration Setting Storage Selected by Woodgrove

Listing 8 illustrates excerpts from a Woodgrove Bank Customsettings.ini file in which the workstation configuration settings are stored. In this example, the workstation-based configuration settings take priority over any group-based configuration settings because MACADDRESS is the first entry in the Priority attribute.

For each workstation that requires unique configuration settings, a corresponding section exists (designated by the MAC address of the workstation’s primary network adapter). In the excerpt in Listing 8 three distinct workstations are being configured (MAC address 00:03:FF:CB:4E:C2, 00:0F:20:35:DE:AC, and 00:03:FF:FE:FF:FF).

Priority= MACADDRESS, DefaultGateway, Default...

[00:03:FF:CB:4E:C2]OSDNEWMACHINENAME=WasW2K

[00:0F:20:35:DE:AC]OSDNEWMACHINENAME=HPD530-1OSDINSTALLPACKAGE=DAL00342OSDINSTALLPROGRAM=CustomXP


[00:03:FF:FE:FF:FF]OSDNEWMACHINENAME=BVMXPOSDINSTALLPACKAGE=NYC00002OSDINSTALLPROGRAM=SpecialXP

Listing 8. Workstation Configuration Settings in Customsettings.ini

Listing 9 illustrates excerpts from a Woodgrove Bank Customsettings.ini file in which the workstation-configuration settings are stored in the ZTI AdminDB database. In this example, the workstation-based configuration settings are applied after group-based configuration settings because SQL is the second entry in the Priority attribute (immediately behind DefaultGateway).

Priority= DefaultGateway, SQL, Default...

[DefaultGateway]172.16.0.3=NYC172.16.111.3=DALLAS172.16.116.3=WASHINGTON

.

.

.

[NYC]SQLDefault=DB_NYC

[DALLAS]SQLDefault=DB_DAL

[WASHINGTON]SQLDefaul=DB_WSG

[DB_NYC]SQLServer=NYC-AM-SMS-01Database=BDDAdminDBTable=BDDAdminCoreParameters=MacAddress

[DB_DAL]SQLServer=DAL-AM-FIL-01Database=BDDAdminDBTable=BDDAdminCoreParameters=MacAddress

[DB_WSG]SQLServer=WSG-AM-DC-01Database=BDDAdminDBTable=BDDAdminCoreParameters=MacAddress

Listing 9. Workstation Configuration Settings in the ZTI AdminDB Database


The example in Listing 9 shows that each location has unique SQL configuration settings to connect to the ZTI AdminDB database. For example, at the NYC location, the configuration settings point to the local SQL Server machine on which the ZTIAdminDB database is stored (NYC-AM-SMS-01). The database name (BDDAdminDB), the table in the database (BDDAdminCore), and the query parameter used to locate the workstation (MacAddress) is also listed.

Note If you want to locate workstations by asset tags, change the MacAddress value to AssetTag or any other method of uniquely identifying the workstation.

Including Custom Exit FunctionsYou can call scripts, or other executable code, from within Zerotouchinstallation.vbs, called custom exit functions. You define the custom exit functions within Customsettings.ini. Listing 10 shows an example of a Customsettings.ini that calls a custom exit function defined in the [Settings] section.

[Settings]Priority= DefaultGateway, MACADDRESS, SQL, DefaultCustomKeysUserData=UDShare,UDDir,UDProfiles,SLShare,OSInstall,JoinDomainCustomKeysSysprep=ComputerName,TimeZone,JoinDomain,MachineObjectOUOSDVariableKeys=OSDINSTALLSILENT,OSDINSTALLPACKAGE,OSDINSTALLPROGRAM,OSDNEWMACHINENAMEScanStateArgs=/i:miguser.inf /i:migapp.inf /i:migsys.inf /i:sysfiles.inf /i:updateuser.inf /v:7 /x /s /f /o /cLoadStateArgs=/v:7 /cUserExit=ZTIUserExit.vbs

Listing 10. Defining Custom Exit Function in the [Settings] Section

Example: Custom Exit Function Selected by Woodgrove

The custom exit function in this example, ZTIUserExit.vbs, allows you to easily extend the functionality of Zerotouchtinstallation.vbs. When Zerotouchinstallation.vbs calls the exit script, it also passes key environment information so that you can tell where in the deployment process you are and execute specific functionality appropriate to that step. Each time ZeroTouchInstallation.vbs is run, you have two opportunities to call the exit script, the first <BEFORE> is just after environment variables are processed and the other <AFTER> is at the end of the script. In the <BEFORE> case you have the option of returning to the script and continue normal processing or returning to the script and skip to the end bypassing normal processing.

Listing 10 shows an example of how Woodgrove Bank included a custom exit function in its Customsettings.ini file. The UserExit value points to a VBScript called ZTIUserExit.vbs. ZTIUserExit.vbs is used to call DiskPart. You can see the complete source code to Woodgrove’s ZTIUserExit.vbs in Appendix G: Sample User Exit Function later in this guide.

For more information about DiskPart.exe, see DiskPart in Additional Resources later in this guide.

In the example, ZTIUserExit.vbs feeds parameters to DiskPart.exe by reading the parameters from a file called ZTIDiskPart.txt. Woodgrove required this custom exit function because OSD only formats the primary drive and then exits. If any other volumes require creation or formatting, ZTIUserExit.vbs partitions and formats those drives.

Note A sample ZTIDiskpart.txt and the ZTIUserExit.vbs listed in Appendix G: Sample User Exit Function are included as a part of the BDD downloads


Including Custom-Stored ProceduresIn your deployment, you may want to provide call stored procedures to provide additional functionality during the workstation deployment. For example, you might want to provide a method of automatically generating a computer name, gathering other information, and then storing that information in the AdminDB database. Then other sections in Customsettings.ini can reference the information by accessing the workstation-specific settings you stored in the AdminDB database.

To call a stored procedure from within Zerotouchinstalltaion.vbs, you need to configure Customsettings.ini as follows:

1. Add a value to the Priority setting, IdentifyComputer, which references a section that defines the stored procedure as illustrated in Listing 11.

2. Create a section,[IdentifyComputer], that defines a subsection, [DB_IdentifyComputer], which contains all the configuration settings for the SQL connection to the stored procedure as illustrated in Listing 11.

3. Complete the section, [DB_IdentifyComputer], which contains all the necessary information to call the stored procedure as illustrated in Listing 11.

Notice that the stored procedure in Listing 11, IdentifyComputer, is called with the following parameters:

MacAddress

Make

Model

[Settings]Priority= DefaultGateway, IdentifyComputer, SQL, Default

.

.

. [IdentifyComputer]

SQLDefault=DB_IdentifyComputer

[DB_IdentifyComputer]

SQLServer=SERVER1

Database=BDDAdminDB

StoredProcedure=IdentifyComputer

Parameters=MacAddress, Make, Model

Listing 11. Defining Custom Stored Procedure Function in the [Settings] Ssection

Example: Custom-Stored Procedure Selected by Woodgrove

Listing 11 shows an example of how Woodgrove Bank included a custom-stored procedure in its Customsettings.ini file. The StoredProcedure value points to a stored procedure called IdentifyComputer in the BDDAdminDB database. MacAddress, Make and Model as passed as parameters to the stored procedure .

You can see the complete source code to Woodgrove’s Customsettings.ini, IdentifyComptuer stored procedure, and a setup script in Appendix K: Sample Stored Procedure Calls later in this guide.

Training Team MembersBefore you begin the deployment, you need to ensure all your team members are properly trained to deploy, manage, operate, troubleshoot, and support the deployment process and deployed workstations. The training should be customized for each team.


Train your team members by completing the following steps:

Identify the training requirements for your organization. Each team will have different training requirements. At a minimum, all team members need to be able to describe the high-level steps in the ZTI deployment process. Other team members will require detailed knowledge of the technologies and processes involved in ZTI.

Determine budgeting requirements for training. Include training as a part of your budgetary estimates. In addition to the cost of training, include any estimated travel expense and human resource costs.

Include training in the project plan. Ensure that you allocate resources to allow training attendance in your project plan. While team members are attending training, they will be unavailable for other tasks in the project.

Schedule team members’ training prior to their involvement in the project. The training should occur before the team members engage in the project. Ensure that you provide the training early enough in the process to allow team members adequate time to become familiar with the technologies and processes.

Note For more information about the training courses and options available, see Appendix H, Training Resources, later in this guide.

Obtaining Consensus for Deployment PlansAs the final task in the Planning phase, you need to obtain consensus for the deployment plans. As the program manager, you are responsible for obtaining consensus. The details for obtaining consensus may be unique in your organization. However, the following high-level tasks are common in most organizations:

Hold a meeting with project stake holders. Ensure that you include all project stake holders in the consensus process. Doing so ensures that your deployment plan addresses all the requirements of the team.

Present the current deployment plan. Make the project stakeholders aware that lab testing and pilot deployments occur later in the process, so the current deployment plan is likely to change. The goal of this milestone is to ensure that the entire team agrees with the current plan. Subsequent meetings should be held each time the deployment plan is changed.

Modify deployment plans until all project stakeholders’ requirements are satisfied. During the meeting, incorporate any changes to the deployment plan that mitigate blocking issues. Upon completion of the meeting, all stakeholders should agree with the deployment plan approach.

Obtain formal approval for continuing with deployment plans. Make this a formal process to ensure that project stakeholders realize that their consensus is their approval to continue. Obtaining formal approval helps ensure that stakeholders carefully review the deployment plan for any potential blocking issues.

Note For more information about obtaining consensus for the deployment plan and the responsibilities of the program manager, see the Computer Imaging System Feature Team Guide, Enterprise Edition in the Additional Resources section of this guide.

DevelopingFigure 7 shows the activities that occur during the Developing phase. Most of these activities involve preparation of the servers used to install applications and migrate existing user data. These tasks may be repetitive depending on your deployment strategy. Some deployments may require that the following sequence of server installation, stabilization, and deployment be repeated several times, either serially or in parallel, to complete an organization-wide deployment.


Figure 7. Activities during the Developing Phase


The following sections describe the steps necessary to prepare the deployment process:

Roles and Responsibilities

Milestones in the Developing Phase

Preparing the RIS Server

Installing Solution Accelerator for BDD

Configuring the Appropriate Resource Access

Configuring the ZTI Operating System Image

Creating the ZTI Operating System Image Installation CD

Configuring the ZTI Processing Rules

Preparing the Windows PE CDs and Images

Roles and ResponsibilitiesIn addition to the tasks defined in the process description that follows, take note of the following responsibilities allocated to the role clusters. Table 14 defines these focus areas for the different role clusters during this phase.

Table 14. Team Roles and Responsibilities in the Developing Phase

Role Focus

Product management Managing customer expectations

Program management Managing the functional specification; project management; updating plans

Development Code creation; infrastructure development; documentation; image creation

User experience Training; usability testing

Test Functional testing; issues identification; documentation review

Release management Creating the deployment servers, deployment checklists, and updated pilot plans; site preparation checklists; operations plans

Milestones in the Developing PhaseTable 16 lists the project milestones and deliverables that you need to complete during the Developing phase. The project plan you create needs to include these milestones, the resources required for each milestone, and the length of time to complete each milestone.

Table 15. Developing Phase Project Milestones and Deliverable Description

Developing Phase Milestone


RIS server prepared The existing servers running RIS are configured and ready to deploy Windows PE images to workstations.

Development

Solution Accelerator for BDD installed

All the Solution Accelerator for BDD components are installed and ready for operating system image deployment.

Development

Appropriate resource Appropriate SMS client access accounts Development


access configured are created, and the corresponding shared folder permissions are assigned to the accounts.

ZTI operating system image configured

Appropriate ZTI operating system images are configured for all SMS OSD Feature Pack phases (Validation, State Capture, Preinstall, Postinstall, and State Restore).

Development

ZTI operating system image installation CD created

CD used for deployment of the operating system image to workstations is created. The ZTI script and corresponding Customsettings.ini file are included in the image.

Development

ZTI processing rules configured

The processing rules, configured in Customsettings.ini, are created. When appropriate, additional settings are stored in a SQL Server database.

Development

Windows PE CDs and images prepared

Images and CDs used to deploy Windows PE on workstations—either through RIS or directly through CDs—are prepared.

Development

Preparing the RIS ServerWhen deploying to workstations that are not managed by SMS, you can initiate the image installation process through RIS. In the ZTI deployment process, your RIS servers are responsible for installing Windows PE on the workstations. You boot Windows PE from RIS to prepare the workstation for operating system image deployment.

Ensure that the RIS servers have the:

Appropriate flat file image structures

Copies of the Windows PE images when they become available from the development team that creates them. These images may not be ready until the end of the Developing phase.

Note For more information about setting up and configuring your RIS server, see Deploying the OS Deployment Package Using RIS in the Microsoft Systems Management Server 2003 Operating System Deployment Feature Pack Users Guide in the Additional Resources section of this guide.

Note For more information about adding additional network drivers to your RIS image, see Preparing the RIS Server in the Computer Imaging System Feature Team Guide, Enterprise Edition.


You need to perform additional RIS configuration that is specific to using Windows PE in the ZTI deployment process. To configure the RIS server to support Windows PE in the ZTI deployment process, perform the following steps:

1. Disable the creation of the Windows PE computer account in Active Directory.

2. Disable Windows PE logging on the RIS server.

3. Automate the RIS Client Installation Wizard.

Disabling Creation of the Windows PE Computer Account in Active DirectoryDuring the ZTI deployment process, Windows PE will create a computer account in Active Directory by default. The computer name that Windows PE uses is temporary and unnecessary after Windows PE has prepared the workstation for Windows XP deployment.

To modify the Ristnrd.sif file to disable the creation of computer accounts in Active Directory, perform the following steps:

1. On the RIS server, start Notepad.

2. In Notepad, open RISTemplatePath\Ristndrd.sif (where RISTemplatePath is the path to the Template folder of the Windows PE image that you want to modify (for example, \RemoteInstall\Setup\English\Images\RIS\I386\Templates).

3. Modify the ImageType entry in the [OSChooser] section to ImageType=WinPE, as illustrated in Listing 12.

[OSChooser]Description ="Build 3608"Help ="SMS 2003 SP1 Build 3174.1017, OSD Build 3608, WinPE Source"LaunchFile = "%INSTALLPATH%\%MACHINETYPE%\templates\startrom.com"ImageType =FlatVersion="5.1 (0)"

Listing 12. Ristndrd.sif Prior to the Modification of ImageType To Use Windows PE

4. After modification, the [OSChooser] section should resemble Listing 13.

[OSChooser]Description ="WinPE 1.5"Help ="Windows PE 1.5 Source"LaunchFile = "%INSTALLPATH%\%MACHINETYPE%\templates\startrom.com"ImageType =WinPEVersion="5.1 (0)"

Listing 13. Ristndrd.sif After the Modification of ImageType To Use Windows PE

5. Save the file, and then close Notepad.

Note In addition to completing these steps, you also need to enable only Tools in the Choice Option Dialog. For more information, see Enabling Only Tools in the Choice Options Dialog Box later in this guide.

Disabling Windows PE Logging on the RIS ServerBy default, Windows PE writes startup information to the Setupapi.log log file. When several workstations simultaneously boot the same Windows PE image, those workstations attempt to write to the same Setupapi.log file, which can cause slow performance because each workstation must wait to gain write access to the file. In the ZTI deployment process, RIS status logging is not required for Windows PE.

Note The file Setupapi.log is not generated until a client boots into Windows PE.


To disable Windows PE logging on the RIS server, perform the following steps:

1. Modify the registry settings in the Windows PE image on the RIS server.

2. Set read-only access on the Setupapi.log file in the Windows PE image on the RIS server.

Modifying the Registry Settings in the Windows PE ImageTo modify the registry settings in the Windows PE image on the RIS server, perform the following steps:

1. On the RIS server, click Start, click Run, and then type RegEdt32.exe in the Open text box.

2. Click the HKEY_LOCAL_MACHINE registry subtree.

3. On the File menu, click Load Hive.

4. Navigate to WinPEConfigPath (where WinPEConfigPath is the path to the i386\System32\Config folder of the Windows PE image on the RIS server), click Software, and then click Open.

5. In the Key Name text box, type TemporaryHiveName (where TemporaryHiveName is a temporary name you assign to the hive), and then click OK.

6. In the Registry Editor, navigate to TemporaryHiveName\Microsoft\Windows\Currentversion\Setup (where TemporaryHiveName is a temporary name you assign to the hive).

7. On the Edit menu, click New, and then click DWORD Value.

8. For the name of the new value, type LogLevel, and then press ENTER.

9. Double-click LogLevel, select Hexadecimal in Value data type 101, and then click OK.

Verify that the LogLevel entry now has a value of 0x00000101.

10. Click TemporaryHiveName (where TemporaryHiveName is the temporary name you assigned to the hive).

11. On the File menu, click Unload Hive.

12. In the Unload Hive dialog box, click Yes.

13. Close the Registry Editor.

Set the Setupapi.log File to Read-onlyTo set the Setupapi.log file to read-only, perform the following steps:

1. On the RIS server, open Windows Explorer, navigate to RISImageI386Path (where RISImageI386Path is the path to the I386 folder of the Windows PE image that you want to modify)—for example, D:\RemoteInstall\Setup\English\Images\winpe\i386).

2. In the details pane, right-click Setupapi.log, and then click Properties.

Note The Setupapi.log file is not present until after you successfully start from the Windows PE image for the first time.

3. In the Setupapi.log Properties dialog box, select Read-only, and then click OK.

4. Close Windows Explorer.

Automating the RIS Client Installation WizardAlthough you have enabled the Windows PE Tools option, the process still requires manual intervention to complete the installation of Windows PE. If you are installing a single image of Windows PE, you can automate the Client Installation Wizard screens in RIS.


To automate the RIS Client Installation Wizard, perform the following steps:

1. Enable the Tools option in the Choice Options dialog box, and disable all other options.

2. Modify the Tools.osc file to enable automated installation.

3. Modify the Login.osc file to further automate installation.

4. Modify the Welcome.osc, Install.osc, and Oschoice.osc files to further automate installation.

Enabling Only Tools in the Choice Options Dialog BoxTo enable the Tools (Maintenance and Troubleshooting) option in the Client Installation Wizard, perform the following steps:

1. Start Active Directory Users and Computers.

2. In the console tree, browse to GroupPolicyContainer (where GroupPolicyContainer is either the domain or the organizational unit (OU) that contains the RIS servers), right-click GroupPolicyContainer, and then click Properties.

3. On the Group Policy tab, click the default domain policy, and then click Edit.

4. In the console tree of the Group Policy Object Editor, expand User Configuration, expand Windows Settings, and then click Remote Installation Services.

5. In the details pane, double-click Choice Options.

6. In the Tools section of the Choice Options Properties dialog box, click Enabled.

7. In the Automatic Setup section, click Disabled.

8. In the Custom Setup section, click Disabled.

9. In the Restart Setup section, click Disabled, and then click OK.

10. Close the Group Policy Object Editor.

11. Close Active Directory Users and Computers.

Modifying Tools.oscYou need to modify Tools.osc so that RIS automatically selects the default tool without waiting for interaction.

To modify the Tools.osc file, perform the following steps:

1. On the RIS server, start Notepad.

2. In Notepad, open ToolsPath\Tools.osc (where ToolsPath is the path to the Template folder of the Windows PE image that you want to modify)—for example, \RemoteInstall\Setup\English\Images\RIS\I386\Templates.

3. In the Tools.osc file, locate the entry <SELECT NAME="SIF" NOAUTO SIZE=12>, which Listing 14 shows.

<OSCML><META KEY=F3 ACTION="REBOOT"><META KEY=F1 HREF="TOOLSHLP"><META KEY=ESC HREF="CHOICE"><META SERVER ACTION="ENUM TOOLS CMDCONS"><TITLE> Client Installation Wizard Tools</TITLE><FOOTER> [ENTER] continue [ESC] go back [F1] help [F3] restart computer</FOOTER><BODY left=5 right=75><BR><BR>Use the arrow keys to select one of the following options:


<BR><P left=8><FORM ACTION="LAUNCH"><SELECT NAME="SIF" NOAUTO SIZE=12>%OPTIONS%</SELECT></FORM></P><BOLD>Description:</BOLD>&nbsp&nbsp<TIPAREA></BODY></OSCML>

Listing 14. Original Version of Tools.osc

4. Remove NOAUTO from the entry, as illustrated in Listing 15.

<OSCML><META KEY=F3 ACTION="REBOOT"><META KEY=F1 HREF="TOOLSHLP"><META KEY=ESC HREF="CHOICE"><META SERVER ACTION="ENUM TOOLS CMDCONS"><TITLE> Client Installation Wizard Tools</TITLE><FOOTER> [ENTER] continue [ESC] go back [F1] help [F3] restart computer</FOOTER><BODY left=5 right=75><BR><BR>Use the arrow keys to select one of the following options:<BR><P left=8><FORM ACTION="LAUNCH"><SELECT NAME="SIF" SIZE=12>%OPTIONS%</SELECT></FORM></P><BOLD>Description:</BOLD>&nbsp&nbsp<TIPAREA></BODY></OSCML>

Listing 15. Modified Version of Tools.osc


Customizing Login.oscTo customize Login.osc to provide credentials for authentication, complete the following steps:

1. Use a text editor to open the file \RemoteInstall\OSChooser\English\login.osc.

2. Replace the string "*****" with the username and password values appropriate for your environment.

For example, if you used OSDUser for the USERNAME value and Deploy101 for the PASSWORD value, the edited lines are:

<INPUT NAME="USERNAME" MAXLENGTH=255 TYPE=TEXT VALUE=OSDUser>

<INPUT NAME="*PASSWORD" TYPE=PASSWORD MAXLENGTH=20 VALUE=Deploy101>

The following is an example of a modified login.osc file:


<OSCML>

<TITLE> SMS OSD Client Installation Wizard Logon</TITLE>

<FOOTER> [ENTER] continue [ESC] clear [F1] help [F3] restart computer</FOOTER>

<META KEY=F3 ACTION="REBOOT">

<META KEY=F1 HREF="LOGINHLP">

<META KEY=ESC HREF="LOGIN">

<META ACTION="LOGIN">

<META ACTION=AUTOENTER>

<BODY left=5 right=75>

Type a valid user name, password, and domain name. You may use the Internet-style logon format (for example:

[email protected]).

<FORM ACTION="CHOICE">

&nbsp&nbspUser name: <INPUT NAME="USERNAME" MAXLENGTH=255 TYPE=TEXT VALUE=osduser>

&nbsp&nbsp&nbspPassword: <INPUT NAME="*PASSWORD" TYPE=PASSWORD MAXLENGTH=20 VALUE=Deploy101>

Domain name: <INPUT NAME="USERDOMAIN" VALUE=%SERVERDOMAIN% MAXLENGTH=255>

</FORM>

Press the TAB key to move between the User name, Password, and Domain name fields.

You are connected to %SERVERNAME%

</BODY>

</OSCML>

Customizing Welcome.osc, Install.osc, and Oschoice.oscTo customize Welcome.osc, Install.osc, and Oschoice.osc to provide credentials for authentication, complete the following steps:

1. In Notepad, open \RemoteInstall\OSChooser\English\OSCFile (where OSCFile is Welcome.osc).

2. Search for the entry <META ACTION="LOGIN">.

3. On the next line, add the entry <META ACTION=AUTOENTER>.

4. Save the file and exit Notepad.

Complete steps 1-4 for the following files:

Install.osc

Oschoice.osc

Note Oschoice.osc is used by RIS when there is more than one RIS image to choose from. It prompts the user for the appropriate image.

Installing Solution Accelerator for BDDBefore you can deploy images to workstations, you must install Solution Accelerator for BDD. Several technologies are included in Solution Accelerator for BDD, and you must install each technology separately.

To install Solution Accelerator for BDD, perform the following steps:

1. Install the SMS 2003 OSD Feature Pack.

2. Install the ZTI files.

3. Install USMT 2.6.

4. Install the AdminDB Console.

5. Install Solution Accelerator for BDD Reporting.


Installing the SMS 2003 OSD Feature PackYou install the SMS 2003 OSD Feature Pack on either an SMS 2003 site server or on a workstation running the SMS 2003 Administrator Console. As previously mentioned, you must install SMS 2003 SP1 on all site servers to support the SMS 2003 OSD Feature Pack. In addition, you need to install the SMS Administrator Console supplied with SMS 2003 SP1. To ensure that more than one workstation can administer the SMS 2003 OSD Feature Pack, install the SMS 2003 OSD Feature Pack on an SMS 2003 site server (recommended).

To install the SMS 2003 OSD Feature Pack, you must:

Extract the setup files that come with the product.

Install the SMS 2003 OSD Feature Pack on an SMS site server and administrator console.

Note It is recommended that you back up your SMS site before upgrading SMS or adding a feature pack.

Note For more information about installing the SMS 2003 OSD Feature Pack, see Microsoft Systems Management Server 2003 Operating System Deployment Feature Pack Users Guide in the Additional Resources section of this guide.

Installing ZTI FilesInstall the ZTI files in a folder in which you will create the SMS 2003 OSD Feature Pack images. To install the ZTI files, perform the following steps:

1. Install the files in the Bddenterprise.msi file.

2. Install additional files that the ZTI scripts require.

Install the Files in the Bddenterprise.msi FileTo install the files in the Bddenterprise.msi file, perform the following steps:

1. Navigate to the folder in which the Bddenterprise.msi file resides.

2. Double-click the Bddenterprise.msi file.

3. Complete the BDD Enterprise wizard by performing the steps in Table 16.

Table 16. Completing the BDD Enterprise Wizard

On This Wizard Page Do This…

Welcome to the BDD Enterprise Setup Wizard

Click Next.

License Agreement Review the license agreement, click I agree, and then click Next.

BDD Enterprise Information

Review the information and then click Next.

Select Installation Folder

In the Folder text box, type BDDEnterpirseFolder (where BDDEnterpriseFolder is the path to the folder in which you want to install BDD Enterprise). The default folder location is C:\Program Files\BDD Enterprise.

Click Everyone.

Click Next.

Confirm Installation Click Next.

Setup Complete Click Close.


4. Set the NTFS file system folder permissions on ZTIFolder (where ZTIFolder is the name of the folder into which you installed the ZTI files)to the following permissions:

Authenticated Users: Read

Administrators: Full Control

5. Share the folder selected in step 4 as ZTI with the following shared folder permissions:



Note For the remainder of this document, the shared folder created in this step will be referred to as the ZTI shared folder.

Install the Additional Files in the Bddenterprise.msi FileIn addition to the files found in the Bddenterprise.msi file, you also need to manually install files that the ZTI scripts require. Table 17 lists the additional files required and where they reside. Dbnmpntw.dll and Sqloledb.rll are only needed if you will be accessing SQL Server. Copy the files to the ZTI shared folder you created. You will add these files to phases in your Image package later as described in the Configuring the ZTI Operating System Image section of this guide.

Table 17. Additional Files Required by ZTI Scripts and Their Location

File Located

Dbnmpntw.dll Any Windows XP SP2 installation

Sqloledb.rll Any Windows XP SP2 installation

Capicom.dll Downloaded from Microsoft at http://www.microsoft.com/downloads/details.aspx?FamilyID=860ee43a-a843-462f-abb5-ff88ea5896f6&displaylang=ca

Note You also need to include the Sqloledb.rll file in the Windows PE image. For more information about how to include files in Windows PE images, see the Microsoft Windows Preinstallation Environment User's Guide (Winpe.chm) in the Docs folder of the Windows PE 2004 CD or review the online documentation related to Windows PE at http://www.microsoft.com/whdc/system/winpreinst/default.mspx

Installing USMT 2.6You need to install USMT version 2.6 in a shared folder. Create the shared folder so that the folder can be accessed by the SMS primary site server on which you installed the SMS 2003 OSD Feature Pack.

To install USMT 2.6, perform the following steps:

1. Complete the USMT Setup Wizard by using the information in Table 18.

Table 18. Completing the USMT Setup Wizard

On This Wizard Page Do This

Welcome Click Next.

License Agreement Review the license agreement, click I agree, and then click Next.

Select Installation Folder

In the Folder text box, type USMTFolder (where USMTFolder is the path to the folder in which you want to install USMT). The default folder location is C:\USMT\Bin.

Click Everyone.


Click Next.

Confirm Installation Click Next.

Setup Complete Click Close.

2. Set the following NTFS file system folder permissions on USMTFolder (where USMTFolder is the name of the folder in which you installed the USMT files):



3. Share USMTFolder (where USMTFolder is the name of the folder <typically Bin> in which you installed the USMT files)with the following shared folder permissions:



Note For the remainder of this document, the shared folder created in this step will be referred to as the USMT shared folder.

Installing the AdminDB ConsoleWhen you installed the ZTI files, you installed the AdminDB console in the same folder structure. The AdminDB console should be in the AdminDB folder beneath the ZTI shared folder.

To install the AdminDB console, perform the following steps:

1. Install the AdminDB files.

2. Determine the size of the AdminDb database

3. Run the script that creates the AdminDB database.

4. Configure the database and log settings for the AdminDB console

Installing the AdminDB FilesTo install the AdminDB console, perform the following step:

1. Copy the \\servername\ZTI\AdminDB (where servername is the name of the server on which you installed the ZTI files) folder and subfolders to LocalPath\AdminDB (where LocalPath is a local path on the computer on which you want to run the AdminDB console).

Determining The Size of the AdminDB DatabaseBefore you can run the script that creates the AdminDB database, you need to determine the size of your AdminDB database. The database needs to be created large enough to hold all the configuration information for your workstation-specific settings.

The default—9 MB—provides enough storage to support 500 computers (assuming that you are using an unmodified AdminDB database schema). For more information about modifying the AdminDB database schema, see Modifying the AdminDB Database Schema in this guide.

You can calculate the approximate size of the database by:

1. Multiplying the length of one row in the database (approximately 3.5 KB) by the number of computers that you want to include in the deployment.

2. Determine the number of administrators who will modify the AdminDB database, then add two to that number.


For each administrator, the AdminDB console creates a separate backup copy of the database to support the Rollback function. AdminDB creates backups of the database when an administrator performs an Import or an Update function on the AdminDB database.

3. Multiply the size of the database you calculated in step 1 by the number you determined in step 2: This is the size of the data portion of the database.

For example, if you want to deploy to approximately 10,000 computers and you have three administrators, the size of the data portion of the database will be 150 MB (3.5 KB × 10,000 × (3 + 2)).

4. Multiply the size of the data portion of the database you calculated in step 3 by 1.5. This is the size of the transaction log portion of the database.

For example, if you determine that the data portion of the database is 150 MB, the size of the transaction log portion of the database will be 225 MB (150MB × 1.5).

5. Add the size of the data portion and the transaction log portion of the database to determine the total size of the AdminDB database.

You must ensure that the SQL Server you select to host the AdminDB database has sufficient disk capacity to store the AdminDB database.

Running the Script That Creates the AdminDB DatabaseTo create the AdminDB database, perform the following steps:

1. Copy the following files from the AdminDB\database folder to TargetFolder on SQLServer (where AdminDB is the folder into which you copied the AdminDB, TargetFolder is a folder you create, and SQLServer is the same SQL Server that SMS uses):

BDDAdminDB-Create.sql

BDDAdminDB-Create.cmd

2. From a command prompt, change to TargetFolder (where TargetFolder is the folder you created in step 1), type BDDAdminDB-Create, then press ENTER.

3. From a command prompt, type type BDDAdminDB-Create.log | more, then press ENTER.

The BDDAdminDB-Create.cmd script creates a log file called BDDAdminDB-Create.log.

4. Review the contents of the BDDAdminDB-Create.log file to determine if any errors occurred during the creation of the AdminDB database.

5. Close the command prompt window.

Configuring the Database and Log Settings for the AdminDB Console The AdminDB console need to be configured so that the console uses the appropriate data source for the database you created earlier in the process. In addition, you need to configure the location where the console will store log files.

To configure the database and log settings for the AdminDB console, perform the following steps:

1. Use an Extensible Markup Language (XLM) editor such as Microsoft® Office FrontPage® 2003 or Notepad to edit the AdminDB\GUI\Bddadmindb config file (where AdminDB is the folder in which you copied the AdminDB folder).

2. Modify the SQL OLE DB connect string located at approximately line 19 to connect to SQLServer (where SQLServer is the same SQL Server machine that SMS uses), as shown in Listing 16.

<add key="ConnectionString" value="Provider=sqloledb;Data Source=(SQLServer); Integrated Security=SSPI;Initial Catalog=BDDAdminDB" />


Listing 16. Configuring the name of the SQL Server that hosts the AdminDB database

3. Modify the SQL OLE DB connect string located at approximately line 19 to connect to Database (where Database is the name of the AdminDB database), as shown in Listing 17.

<add key="ConnectionString" value="Provider=sqloledb;Data Source=(local); Integrated Security=SSPI;Initial Catalog=Database" />

Listing 17. Configuring the name of the AdminDB database

4. If necessary, modify the file name and path of the log file created by the AdminDB console, as shown in Listing 18.

<add key="LogFilePath" value="C:\BDDadminDB.log" />

Listing 18. Configuring log path and file name used by the AdminDB console

5. Close the XML editor.

Configuring the Appropriate Resource AccessDuring the deployment to the workstations, the SMS client connects to the distribution point shares and shared folders. You need to create accounts within SMS for use by the SMS client when accessing these resources.

To configure the appropriate resource access, perform the following steps:

1. Configure SMS client access accounts.

2. Configure shared folder permissions.

Configuring Client Access AccountsThe SMS client needs an account to provide as credentials when accessing your distribution points and shared folders. The accounts you need to configure are listed in Table 19.

Table 19. Accounts Needed To Be Configured

For This Description

SMS client connection account

Used by legacy clients (such as Windows NT 4.0 Workstation) to install the legacy client software.

SMS advanced client network access account

Used by OSD on Windows 2000 Workstation and later operating systems to access the distribution point that contains the OS package.

SMS legacy client software installation account

Used by OSD on operating systems prior to Windows 2000 Workstation to access the distribution point that contains the OS package.

To configure the client access accounts, perform the following steps:

1. Create the user account and password in an Active Directory domain.

2. In the SMS Administrator Console, navigate to the Client node, as illustrated in Figure 8.


Figure 8. Adding Client Connection accounts

3. Right-click the Client node, click New, and then click Windows User Account.

4. In the Connection Account Properties dialog box, click Set.

5. Complete the Windows User Account dialog box by using the information in Table 20, and then click OK.

Table 20. Information Required To Complete the Windows User Account Dialog Box

For This Do This

User name Type UserName (where UserName is the name of the user account that you wish to use).

Password Type Password (where Password is the password for the user account that you wish to use).

Confirm Password Type Password (where Password is the password for the user account that you wish to use).

6. Repeat steps 3–5 for each client access account you need to create.

7. In the SMS Administrator Console, navigate to the Component Configuration node, as illustrated in Figure 9.


Figure 9. Configuring Software Distribution to use the Client Connection accounts

8. In the details pane, right-click Software Distribution, and then click Properties.

The Software Distribution Properties dialog box, illustrated in Figure 10, appears.


Figure 10. Configuring the Software Distribution properties

9. In the Software Distribution Properties dialog box, click the General tab, enter the corresponding accounts in the Legacy Client Software Installation Account and the Advanced Client Network Access Account text boxes, and then click OK.

10. Close any open windows.

Creating Additional Shared FoldersAfter you have configured the SMS client access accounts, you need to create additional shared folders in which to store the user state migration data and the deployment logs. Table 21 lists the shared folders that you need to create and describes the purpose of each shared folder. For more information about the planning for these share folders, see Providing Sufficient Storage for User State Migration Data and Providing Sufficient Storage for Deployment Logs earlier in this guide.

Table 21. Shared Folders and Their Descriptions

Shared Folder Description

MigData Stores the user state migration data during the deployment process

Logs Stores the deployment logs during the deployment process


Configuring Shared Folder PermissionsAfter you have configured the SMS client access accounts, you need to configure the appropriate shared folder permissions. Ensure that unauthorized users are unable to access user state migration information and the deployment logs. Only the workstation creating the user state migration information and the deployment logs should have access to these folders.

To configure the shared folder permissions for each folder listed in Table 21, perform the following steps for each folder:

1. Start Windows Explorer and navigate to SharedFolder (where SharedFolder is one of the shared folders listed in Table 21).

2. Right-click SharedFolder (where SharedFolder is one of the shared folders listed in Table 21), and then click Properties.

3. On the Security tab, click Advanced.

4. On the Permissions tab, clear the Allow inheritable permissions from the parent to propagate to this object and all child objects check box.

5. When the Remove when prompted to either Copy or Remove the permission entries that were previously applied from the parent appears, click Remove.

6. On the Permissions tab, click Add.

7. In the Enter the object name to select text box, type Domain Computers, and then click OK.

This action allows domain computers to create subfolders.

8. On the Permission Entry for Text dialog box, in the Apply onto list, select This folder only.

9. On the Permission Entry for Text dialog box, in the Permissions list, select Allow for the Create Folders/Append Data permission, and then click OK.

10. On the Permissions tab, click Add.

11. In the Enter the object name to select text box, type CREATOR OWNER, and then click OK.

This action allows domain computers to access the subfolders they create.

12. On the Permission Entry for Text dialog box, in the Apply onto list, select Subfolders and files only.

13. On the Permission Entry for Text dialog box, in the Permissions list, select Allow for the Full Control permission, and then click OK.

14. Repeat steps 10–13 for each group that you want to grant administrative privileges.

The permissions you set in these steps allows a workstation to connect to the appropriate share and create a new folder in which to store user state information or logs, respectively. The folder permissions prevent other users or computers from accessing the data stored in the folder.

Note The default permissions on the SMS distribution point shares should provide the appropriate resource access by default.

Configuring Access for Deployment PhasesThe deployment of your operating system packages to your workstation can be broken down into the phases described in Table 22. These phases occur during different sequences in the deployment process.

Table 22. Operating System Deployment Phases and Their Descriptions


Phase Phase Description Credentials Available

Validation Performs validation checks to make sure that the operating system installation can proceed; specifically blocks installation on server operating systems

Any credentials

State Capture Gathers information from the configuration file, databases, and the local machine to determine how the image installation process should proceed, including whether there is enough space to do a local USMT state backup; invokes USMT Scanstate as appropriate

Any credentials

Package Selection

When Windows PE is used to prepare the workstation for installation, OSD uses the information in the Ripinfo.ini file to locate and run the command in the [UserCommand] section (Zerotouchinstallation.vbs). OSD ignores the [ImageInfo] section and simply passes control to Zerotouchinstallation.vbs

When you initiate the installation of Windows PE from a CD, the CD-based method ignores the [UserCommand] section and uses the information in the [ImageInfo] section. The CD-based method is not automated and requires manual selection of the image to install.

This phase exists only when you are installing a new operating system installation (New Computer and Replace Computer scenarios),

Credentials in Ripinfo.ini that provide access to the distribution point

Credentials in Ripinfo.ini that provide access to the shared folder specified in the [UserCommand] section

Preinstall Confirms that the necessary information has been gathered (or in the case of the New Computer or Replace Computer scenario, gathers the information)

Any credentials

Postinstall Updates the Sysprep.inf file with information gathered in the previous custom actions

Any credentials

State Restore Invokes USMT Loadstate to restore the user state that was previously backed up

Any credentials

You can divide the authentication requirements into authentication required for:

The Package Selection phase.

All other phases.

Authenticating Access During the Package Selection PhaseDuring the Package Selection phase, only a limited number of credentials are available. These credentials are stored in the Ripinfo.ini file and are used by OSD to provide access to the resources. The credentials supplied in Ripinfo.ini include credentials as specified in the:

[RIPInfo] section. The credentials in [RIPInfo] are used to authenticate access for the shared folder on the distribution point where the package image is stored.

[UserCommand] section. The credentials in the [UserCommand] section are used to authenticate access to the shared folder where the command line program is stored (which may also be on the same distribution point).


A sample Ripinfo.ini file is illustrated in Figure 11.

[RIPInfo]

Images=1

LocalImage=Yes

WizTitle=XPSP2

AllowMachineName=No

SiteCode=SMS

ManagementPoint=SERVER1:80

Reserved1=5EDBD289503F9DA5B84F6BA5320EACCB250DA92CA96A46E265F7732A4071BF0BD196976C659D66

Reserved2=E35E5E17C5AD023A280D3DBC9D5C0DF0042E583113F3A183CE7A9DDE0E15640B29D4AFC6BE517A

Reserved3=66AEA099AE219FD2A1AB1C4E97D1D3E9C67E58F60B

[UserCommand]

CommandLine=""\\Server1\SMSPKGE$\SMS00001\ZeroTouchInstallation.vbs" /phase:NewComputer" /scriptlog

NetworkShare=\\Server1\SMSPKGE$\SMS00001

Reserved1=2BDEF2AE706BC58AEA1B1DF04F0BD8CF5C0AAB5DDB1F43E25F2D6967E794E2F62416DCD3736A27

Reserved2=965B5E10C5D97A355AA70B0082C94BADE1A90C403969116AF008F0618690CDAFB7A374FD7E7E56

Reserved3=C3ABADA631DDDC0686C3C3CFF748EB6F0E5FCE89AD

Figure 11. Sample Ripinfo.ini

You can only connect to the following two servers during the Package Selection:

Distribution point specified in the [RIPInfo] section.

Server hosting the network share specified in the [UserCommand] section.

Note If both of these sections point to the distribution point, then you can only access resources on the distribution point.

Authenticating Access During All Other PhasesDuring the other phases listed in table, you can connect to:

The distribution point by using the user credentials supplied by OSD.

Other servers by using the Connect to UNC action.

You supply credentials when you configure a Connect to UNC action. In addition to a connection to shared folders, you can use the credentials supplied in the Connect to UNC action to authenticate to application or database servers (such as Microsoft® SQL Server® 2000 or Microsoft® Exchange Server 2003).

To authenticate on these application or database servers, use the Connect to UNC action to connect to any share on that server. Other connections, such as Named Pipes or Remote Procedure Call, will use the same credentials you supplied in the Connect to UNC action.

Authenticating Access Through Encrypted CredentialsYou can also supply credentials to the Zerotouchinstallation.vbs script through the Encryptedsettings.ini file. The Zerotouchinstallation.vbs. script first tries to obtain credentials from Encryptedsettings.ini to use when accessing SQL server or a shared folder (such as SLShare, UDShare, or DriverPath).

You can use this method for providing credentials when you need to deliver an SMS package to a workstation without using OSD. For example, you could use this method in the Replace Computer scenario when you send an SMSP package that captures user state migration information (see more information on this by reviewing the Replace Computers scenario earlier in this guide).

In instances where you are using OSD, use Connect to UNC instead.

The credentials stored in Zerotouchinstallation.vbs are encrypted and decrypted by:


Encrypt.vbs. Used to encrypt the credentials and place them in Encryptedsettings.ini by using an encryption key stored in another file. The syntax is as follows:

Cscript Encrypt.vbs Unencryptedcredentials.ini Encryptionkey.txt Encryptedcredentials.ini

Where:

Unencryptedcredentials.ini is the name of the file that contains your unencrypted credentials (as illustrated in Listing 19).

Encryptionkey.txt is the name of the file that contains the key pair used for encryption.

Decrypt.vbs. Used to decrypt the credentials stored in Encryptedsettings.ini and place the unencrypted credentials in a file by using an encryption key stored in another file.

Cscript Decrypt.vbs Encryptedcredentials.ini Encryptionkey.txt Unencryptedcredentials.ini

Where:

Unencryptedcredentials.ini is the name of the file that contains your unencrypted credentials (as illustrated in Listing 19).

Encryptionkey.txt is the name of the file that contains the key pair used for encryption.

Note Encrypt.vbs and Decrypt.vbs are installed during the BDDEnterprise.msi process.

[Server]

NYC-AM-FIL-01=WOODGROVEBANK\NYCUtil;P@ssword

DAL-AM-FIL-01=WOODGROVEBANK\DALUtil;password!

[SQL]

NYC-AM-SQL-04=sa;password

Listing 19. Sample file that contains unencrypted credentials

To use Encryptedcredentials.ini you need to include the following in the image package:

An Encryptedcredentials.ini file that contains your credentials.

Capicom.dll to support access to Encryptedcredentials.ini.

To use Encryptedcredentials.ini to provide credentials to a server running SQL Server 2000, you need to add the SQLShare parameter in the SQL section in Customsettings.ini.

Configuring the ZTI Operating System ImageYou can configure a particular operating system to use the ZTI scripts by using the SMS Administrator Console. The SMS 2003 OSD Feature Pack defines phases, listed in Table 23, that occur during the deployment of your SMS 2003 OSD Feature Pack image to the workstation. You need to configure each phase with the appropriate ZTI script settings to fully automate your Windows XP deployment.

Table 23. SMS OSD Feature Pack Phases, the Custom Action Names, and Their Descriptions

Phase Custom Action Name Phase Description

Validation Zero Touch Installation—Validation

Performs validation checks to make sure that the operating system installation can proceed; specifically blocks installation on server operating systems

State Capture

Zero Touch Installation—State Capture

Gathers information from the configuration file, databases, and the local machine to determine how the image installation process should proceed, including whether there is enough space to do a local USMT state backup; invokes USMT Scanstate as appropriate


Preinstall Zero Touch Installation—Preinstall

Confirms that the necessary information has been gathered (or in the “bare metal” case, gathers it)

Postinstall Zero Touch Installation—Postinstall

Updates the Sysprep.inf file with information gathered in the previous custom actions

State Restore

Zero Touch Installation—State Restore

Invokes USMT Loadstate to restore the user state that was previously backed up

Configuring the Validation Phase ActionsTo configure the Validation phase actions, perform the following steps:

1. In the SMS Administrator Console, expand Image Packages, expand Package, then click Programs (where Package is the name of the package you want to configure).

2. In the details pain, double-click Program (where Program is the name of the program that you want to configure).

3. In the Program Properties dialog box, click the Advanced tab (where Program is the name of the program that you want to configure).

4. In the Phase drop-down list, select Validation, and then click Add.

The Add Action: Validation dialog box appears.

5. From the list of action types, select Custom, and then click OK.

6. Complete the custom actions by using the information listed in Table 24, where servername is the name of the server hosting the shared folder.

Table 24. Configuration Information for the Validation Phase Actions

Field Value

Name Zero Touch Installation—Validation

Command line

Zerotouchinstallation.vbs /phase:Validation

Files \\servername\ZTI\Customsettings.ini

\\servername\ZTI\Dbnmpntw.dll

\\servername\ZTI\Zerotouchinstallation.vbs

\\servername\ZTI\Sqloledb.rll

Configuring the State Capture Phase ActionsTo configure the State Capture phase actions, perform the following steps:




4. In the Phase drop-down list, select State Capture, and then click Add.


5. From the list of action types, select Custom, and then click OK.


Table 25. Configuration Information for the State Capture Phase Actions

Field Value

Name Zero Touch Installation—State Capture

Command line

Zerotouchinstallation.vbs/phase:StateCapture





\\servername\ZTI\Updateuser.inf

\\servername\USMT\*.*

Specifying User Profiles to MigrateThe deployment process utilizes a file called Updateuser.inf, as seen in Table 25. Updateuser.inf is included as a parameter on the USMT command line during the State Capture phase. You specify the user profiles that you want USMT to migrate by entering them in the [IncludeUsers] section of the Updateuser.inf file. You can also specify user profiles that you want USMT to ignore by entering them in the [ExcludeUsers] section of the Updateuser.inf file. The Updateuser.inf file allows you to dynamically build a user list, while keeping the USMT command line the same.

The format for entering the names of the user profiles is Domain\Username (where Domain can be any Active Directory domain, or computer name for local accounts, and Username is the username of the user profile). Table 26 lists examples entries in Updateuser.inf.

Table 26. Examples of Entries in Updateuser.inf

Example Captures…

* or *\* All user profiles.

Domain\* All user profiles in Domain (where Domain is the name of a domain or computer).

Domain\Username

Username profile in Domain (where Username is the name of the user and Domain is the name of the domain or computer where Username exists).

Listing 20 shows a sample Updateuser.ini. In this example, all user profiles are migrated except any user profiles for users that exist:

On the local computer (%Computername%\*).

In the APPDOMAIN domain (APPDOMAIN\*).

[IncludeUsers]

*\*

.

.

.

[ExcludeUsers]

%Computername%\*


APPDOMAIN\*

Listing 20. Sample Updateuser.inf

For more information about the variables and wild-card characters supported by USMT in Updateuser.inf, see [Include Users] Section and [Exclude Users] Section in User State Migration Tool Help included with USMT 2.6.

Specifying Additional File Extensions to MigrateBy default, USMT migrates the file type known to the Windows operating system. You can instruct USMT to migrate additional file types by using the Userdata.inf file. The [Files and Folders] section of Userdata.inf allows you to easily migrate extensions, specific files, standard directories (like My Documents), and new directories (for example, C:\myfiles) directly to the same location on the destination computer. A sample Userdata.inf file is illustrated in Listing 20.

[Files and Folders]

EXT, doc

FILE, %appdata%\myfile.dat

DIR, %csidl_personal%*\*

Listing 21. Sample Userdata.inf

For more information about the [Files and Folders] section in Updateuser.inf, see [Files and Folders] Section in User State Migration Tool Help included with USMT 2.6.

Backing Up the Administrators and Power Users Group MembershipDuring the State Capture phase, the Zerotouchinstallation.vbs script backs up the membership of the local Administrators and Power Users groups. Later in the State Restore phase, the Zerotouchinstallation.vbs script restores the group membership for each group to the same list of users.

If you want to disable the backup and restore of Administrator and Power Users group membership, configure the CaptureGroups setting in Customsettings.ini to NO, as illustrated in Listing 22. If the CaptureGroups setting is missing or set to any other value, the Administrators and Power Users group membership is migrated.

[Settings]Priority= DefaultGateway, SQL, DefaultCustomKeysUserData=UDShare,UDDir,UDProfiles,SLShare,OSInstall,JoinDomainCustomKeysSysprep=ComputerName,TimeZone,JoinDomain,MachineObjectOUOSDVariableKeys=OSDINSTALLSILENT,OSDINSTALLPACKAGE,OSDINSTALLPROGRAM,OSDNEWMACHINENAMEScanStateArgs=/i:miguser.inf /i:migapp.inf /i:migsys.inf /i:sysfiles.inf /i:updateuser.inf /v:7 /x /s /f /o /cLoadStateArgs=/v:7 /cCaptureGroups=NOUserExit=ZTIUserExit.vbs

Listing 22. Configuring CaptureGroups Settings to Disable Migration of Administrators and Power Users Group Membership

For more information on migrating the Administrators and Power Users group membership see, Restoring the Administrators and Power Users Group Membership later in this guide.

Configuring the Preinstall Phase ActionsTo configure the Preinstall phase actions, perform the following steps:





4. In the Phase drop-down list, select Preinstall, and then click Add.

5. In the list of action types, select Custom, and then click OK.


Table 27. Configuration Information for the Preinstall Phase Actions

Field Value

Name Zero Touch Installation—Preinstall

Command line

Zerotouchinstallation.vbs/phase:Preinstall





Note If the Logs or Migdata shared folders, created earlier in the process, are located on a server other than the distribution point containing your image packages, you will need to add a Connect to UNC custom action as the first item in the Preinstall phase. The syntax of this action would be something like %UDShare%.

Configuring the Postinstall Phase ActionsTo configure the Postinstall phase actions, perform the following steps:




4. In the Phase drop-down list, select Postinstall, and then click Add.



Table 28. Configuration Information for the Postinstall Phase Actions

Field Value

Name Zero Touch Installation—Postinstall

Command line

Zerotouchinstallation.vbs/phase:Postinstall

Files \\servername\ZTI\Capicom.dll

\\servername\ZTI\Customsettings.ini





Configuring the State Restore Phase ActionsTo configure the State Restore phase actions, perform the following steps:




4. In the Phase drop-down list, select State Restore, and then click Add.



Table 29. Configuration Information for the State Restore Phase Actions

Field Value

Name Zero Touch Installation—State Restore

Command line

Zerotouchinstallation.vbs/phase:StateRestore

Files \\servername\ZTI\Capicom.dll

\\servername\ZTI\Customsettings.ini




\\servername\ZTI\Updateuser.inf

\\servername\USMT\*.*

\\servername\SMS_XXX\OSD\OSDSWDExec.exe (where XXX is the site code of your SMS site server)

\\servername\\SMS_XXX\OSD\OSDConnectToUNC.exe (where XXX is the site code of your SMS site server)

Note For troubleshooting purposes in your lab environment, you may want to include the /debug:true switch to the end of your command line in each phase. This causes OSD to retain the C:\MININT directory, instead of deleting it, when complete. This allows you to review the logs when any error occurs.

Performing Steps Required For Images Created by Using the BDD Computer Imaging SystemIf the image you are deploying is created by using the BDD Computer Imaging System, you need to call POST2.BAT to:

Install any hardware-specific software.


Make any necessary post-deployment configuration changes (such as configuring network settings).

To call POST2.BAT, add a new custom action after the Zero Touch Installation—State Restore custom action. The custom action should run C:\Local\POST2.BAT with no parameters.

Note POST2.BAT (and the other batch files that POST2.BAT calls) cannot reboot the system. If a reboot is required, use a Reboot action after the custom action that runs POST2.BAT.

Restoring the Administrators and Power Users Group MembershipEarlier in the State Capture phase, the Zerotouchinstallation.vbs script backs up the membership of the local Administrators and Power Users groups. During the State Restore phase, the Zerotouchinstallation.vbs script restores the group membership for each group to the same list of users.

If you want to disable the backup and restore of Administrator and Power Users group membership, configure the CaptureGroups setting in Customsettings.ini to NO, as illustrated in Listing 23. If the CaptureGroups setting is missing or set to any other value, the Administrators and Power Users group membership is migrated.

[Settings]Priority= DefaultGateway, SQL, DefaultCustomKeysUserData=UDShare,UDDir,UDProfiles,SLShare,OSInstall,JoinDomainCustomKeysSysprep=ComputerName,TimeZone,JoinDomain,MachineObjectOUOSDVariableKeys=OSDINSTALLSILENT,OSDINSTALLPACKAGE,OSDINSTALLPROGRAM,OSDNEWMACHINENAMEScanStateArgs=/i:miguser.inf /i:migapp.inf /i:migsys.inf /i:sysfiles.inf /i:updateuser.inf /v:7 /x /s /f /o /cLoadStateArgs=/v:7 /cCaptureGroups=NOUserExit=ZTIUserExit.vbs

Listing 23. Configuring CaptureGroups Settings to Disable Migration of Administrators and Power Users Group Membership

For more information about migrating the Administrators and Power Users group membership see, Backing Up the Administrators and Power Users Group Membership earlier in this guide.

Creating the ZTI OS Image Installation CDTo completely automate the SMS 2003 OSD Feature Pack image installation process, you need to include the ZTI script in the image installation CD. The script Zerotouchinstallation.vbs gathers the SMS operating system image package ID and program name.

To create the ZTI operating system image installation CD, perform the following steps:

1. In the SMS Administrator Console, navigate to the Image Packages node.

2. Right-click the Image Packages node, click All Tasks, and then click Create Operating System Image Installation CD.

3. Complete the Operating System Image Installation CD Wizard by using the information in Table 30.

Table 30. Completing the Operating System Image Installation CD Wizard

On This Wizard Page Do This

Welcome to the Operating System Image Installation CD Wizard

Click Next.


Installation Settings Select the Automatically choose the OS Package to install by running a custom program or a script check box, and then click Next.

Install from SMS distribution points

Ensure the central site server is specified in the list of servers, click Select All, and then click Next.

Automatically select Operating System Package

In the File name text box, type \\servername\ZTI\Zerotouchinstallation.vbs (where servername is the name of the server hosting the shared folder).

Note The Zerotouchinstallation.vbs file must reside on the same server as the distribution point on which your image packages reside, because you do not have the option to provide a second set of credentials to connect to a different server (Connect to UNC).

In the Arguments text box, type /phase:NewComputer.

Note In your lab environment, add the /debug:true switch to the end of the argument to provide additional debugging and troubleshooting information by using pop-ups displayed in Windows PE.

In the User name text box, type SMSClientAccount (where SMSClientAccount is the name of the client account created in Configuring Client Access Accounts earlier in this guide.

In the Password text box and Confirm password box, type Password (where Password is the password of the client account created earlier in the deployment process).

Click Next.

Note The account credentials are stored on the installation CD in an encrypted format.

Windows PE Settings If additional network drivers are required, select the Include additional network drivers from this location check box, and then type DriverPath (where DriverPath is the fully qualified path to any additional network drivers required in your environment).

If additional storage drivers are required, select the Include additional storage drivers from this location check box, and then type DriverPath (where DriverPath is the fully qualified path to any additional storage drivers required in your environment).

Click Next.

Create CD Image In the Name text box, type CDName (where CDName is the name of the CD image).

In the File name text box, type CDFileName (where CDFileName is the file name for the CD image).

Wizard Complete Click Finish.

4. Generate a CD of the operating system image contents.

Note Do not burn the image file itself onto the CD. Burn the content of the image onto the CD.

In the .iso image that you create, there is a file named Ripinfo.ini. Ripinfo.ini is an answer file used by RIS to automate the installation of your operating system. When you are booting Windows PE from a RIS server, Ripinfo.ini also includes:

The command line for the script used to automate your installation


The list of available packages in the image.

You need to update your images when either of the items listed above change. While you can edit the Ripinfo.ini file directly, it is recommended that you create a new image by using the Operating System Image Installation CD wizard. The wizard will automatically update Ripinfo.ini to reflect any changes in the command line or available packages.

Configuring ZTI Processing RulesThe ZTI scripts configure workstations settings based on rules and configuration settings stored in the Customsettings.ini file or in a SQL Server database. During the MSF Planning phase, you determined the appropriate ZTI processing rules to use in your organization. Now you need to configure those rules in the Customsettings.ini or in the AdminDB database.

To configure the ZTI processing rules, perform these steps:

1. Configure group-based rules in Customsettings.ini.

2. Modify the AdminDB database schema.

3. Configure workstation-based rules.

4. Update ZTI processing rules in the SMS OSD Feature Pack image.

Note For more information about determining the appropriate ZTI processing rules, see Determining the Appropriate ZTI Processing Rules earlier in this guide. For more information about the Customsettings.ini file, see Appendix B, Customsettings.ini Reference, later in this guide.

Configuring Group-Based Rules in Customsettings.iniYou configure group-based rules in the Customsettings.ini file. Modify the Customsettings.ini file based on the group-based rules you determined during the MSF Planning phase. The Customsettings.ini file, along with your group-based rules, becomes your Customsettings.ini template. For more information about determining the appropriate group-based rules, see Determining the Appropriate ZTI Processing Rules earlier in this guide.

Modifying the AdminDB Database SchemaThe AdminDB database contains the workstation-based rules. The default schema contains the common characteristics used to identify and configure a workstation. However, if you want to provide additional configuration options or use other characteristics to identify a workstation, you need to modify the database schema.

To modify the AdminDB database schema, perform the following steps:

1. Modify the AdminDB console components.

2. Modify the AdminDB console validation functions.

Modifying the AdminDB Console ComponentsYou can modify or remove any column in the AdminDB database except for the following:

ID

ComputerName

MacAddress

AdminUser

Modifying the database schema affects several components. Table 31 lists each component and provides guidance on where and how to updated the components.

Table 31. AdminDB Console Components, Their Location, and How To Update the Component

Component Location How To Update the Component

BDDAdminCore table BDDAdminDB database

Use SQL Server Enterprise Manager to add, delete, or modify columns.

BDDAdminBackUp table

BDDAdminDB database

Use SQL Server Enterprise Manager to add, delete, or modify columns.

BDDAdminBackUpUser stored procedure

BDDAdminDB database

Use SQL Query Analyzer to modify the SELECT statement marked with the comment "-- Back up the entire BDDAdminCore table into BDDAdminBackUp”.

BDDAdminRollBackUser stored procedure

BDDAdminDB database

Use SQL Server Enterprise Manager to modify the SELECT statement marked with the comment "-- roll back the last back-up”.

ColumnsHeaders Bddadmindb.config file

Use an XML editor to modify the column listed in the ColumnsHeaders entity in the Bddadmindb.config file.

Existing .csv documents Various folders Use Microsoft® Office Excel to modify the column names and positions.

Validation functions Bddadmindb.hta file Use the appropriate editor to modify the validation functions in the section "LIST OF VALIDATION FUNCTIONS". For more information about creating validations functions, see Modifying AdminDB Console Validation Functions in this guide.

  in the BddAdmindb.hta file

In the  section, modify the column headers listed.

  in the BDDadminDB.hta file

In the  section, modify the column description and data type listed.

Update AdminDB schema documentation

Modify the schema documentation to reflect the actual schema.

Update AdminDB .csv documentation

Modify the .csv documentation to reflect the actual schema.

Bddadmindb-Create.sql \database folder Use SQL Query Analyzer to modify the script to create the tables based on the modified


schema.

Modifying AdminDB Console Validation FunctionsWhen you are modifying the schema of the AdminDB database, you need to include updated validation functions for the columns you are adding or modifying. You need to ensure that:

A validation function exists for each column

You terminate each function with a statement that returns either true or false

To modify the AdminDB console validation functions, perform these steps:

1. Modify the validation functions in the section "LIST OF VALIDATION FUNCTIONS” by using Office FrontPage 2003, Notepad, or another program suitable for modifying .hta files.

2. Enable the debugging of the Bddadmindb.hta file by replacing all occurrences of On Error Resume Next with ‘On Error Resume Next.

This modification makes the On Error Resume Next statement a comment. Nine occurrences should be replaced.

3. Import a .csv file by using the Replace action to verify that the validation functions are working correctly.

4. If errors occur, modify the validation functions.

5. Continue to test the validation functions until the test is successful.

6. Disable Bddadmindb.hta file debugging by replacing all occurrences of ’On Error Resume Next with On Error Resume Next.

Configure Workstation-Based RulesDepending on your environment, you might need to add exceptions to your Customsettings.ini template. You add specific configuration settings that are unique to that workstation. These configuration settings can be in addition to or instead of the group-based rules.

To configure the workstation-based rules, add exceptions to the:

AdminDB database (recommended). Add the workstation-based rules to the AdminDB database by using the AdminDB console. Configure workstation-based rules by using this method when workstations have connectivity to the AdminDB database.

Customsettings.ini template. Add the workstation-based rules to the AdminDB database by using the AdminDB console. Then, append the rules to the Customsettings.ini template. Configure workstation-based rules by using this method when workstations are unable to connect to the AdminDB database.

Note For more information about determining the appropriate method for processing workstation-based rules, see Determining the Appropriate ZTI Processing Rules earlier in this guide.

To configure the workstation-based rules, you need to:

Modify the AdminDB database

Append the workstation-based rules to the Customsettings.ini template (when your workstations are unable to connect to the AdminDB database)


Modifying the AdminDB DatabaseYou modify the AdminDB database by using the AdminDB console. The AdminDB database was created earlier in the installation process. For more information about the AdminDB database, see Creating the AdminDB Database earlier in this guide.

To modify the AdminDB database, perform the following steps:

1. Create a .csv file that contains the entries for the exceptions to the group-based rules.

Create the .csv file by using a program such as Office Excel 2003 or Microsoft® Office Access 2003. Maintain the master copy of the information in the .csv file. Always overwrite the information in the AdminDB database with the information in the .csv file.

Note For more information about the format of the .csv file, see Appendix B, AdminDB .csv File Format Reference in this guide. For more information about determining which workstations require unique rules and AdminDB database entries, see Determining the Appropriate ZTI Processing Rules earlier in this guide.

2. In the ZTIInstallationFolder\AdminDB folder (where ZTIInstallationFolder is the folder in which you installed the ZTI files), double-click Bddadmindb.hta.

The default location for ZTIInstallationFolder is Program Files\BDD Enterprise\Zero Touch Installation).

3. On the Import/Export tab, click Replace.

4. In the Open dialog box, browse to CSVFolder (where CSVFolder is the folders containing the .csv file you created in step 1), and then double-click CSVFile (where CSVFile is the file name of the .csv file you created in Step 1).

5. In the BDD AdminDB dialog box, click OK.

6. Close the AdminDB console.

Note If you are storing the workstation-based rules in the AdminDB database, refer to Updating ZTI Processing Rules in the SMS OSD Feature Pack Image later in this guide.

The AdminDB console has other functions that are outside the processes described here. Table 32 lists the additional functions and provides a brief description of how to use them.

Table 32. Other AdminDB Console Database Functions and Their Descriptions

Functions Description

Update Allows you to perform maintenance on existing database entries (add, delete, and update); use this function when you want to modify the AdminDB database based on the .csv file instead of replacing the entire database

Export Exports the existing database entries to a .csv file

Rollback Restores the database to the version prior to the last Import or Update action performed

Each Replace or Update function creates a complete backup of the AdminDB database. The Rollback function uses this backup to restore the database to a state prior to the last Import or Update action performed. The database backups are performed on a username-by-username basis.

For example, if two ZTI administrators, Admin-A and Admin-B, are responsible for managing a single AdminDB database, a separate backup of the last Replace or Update action is maintained for each administrator, which can result in lost information. Consider the sequence of actions and their results listed in Table 33.

Table 33. Example of Database Actions and the Results of Performing a Rollback

Action Results

Admin-A performs an Backup copy of the database is made for Admin-A


Update action on the database.

Admin-B performs an Update action on the database.

Backup copy of the database, including updates made by Admin-A, is made for Admin-B

Admin-A performs a Rollback action on the database.

Database is restored to the state prior to Admin-A performing the update, which results in the loss of the update performed by Admin-B

Note Because a backup copy of the AdminDB database information is persisted for each ZTI administrator, limit the number of ZTI administrators to reduce the disk space used by the AdminDB database.

Appending Workstation-Based Rules to the Customsettings.ini TemplateTo append workstation-based rules to the Customsettings.ini template, perform the following steps:

1. Copy your existing Customsettings.ini template to ConfigFileFolder (where ConfigFileFolder is the folder in which you want to store the customized version of the Customsettings.ini template).

2. In the ZTIInstallationFolder\AdminDB folder, double-click Bddadmindb.cmd (where ZTIInstallationFolder is the folder in which you installed the ZTI files).

The default location for the ZTIInstallationFolder is Program Files\BDD Enterprise\Zero Touch Installation).

3. On the Import/Export tab, click Append ini.

4. In the Open dialog box, browse to ConfigFileFolder (where ConfigFileFolder is the folders containing the copy of the Customsettings.ini template file you selected in step 1), and then double-click Customsettings.ini.

The AdminDB console appends the database entries to the copy of your Customsettings.ini template.

5. In the BDD AdminDB dialog box, click OK.

6. Close the AdminDB console.

Updating ZTI Processing Rules in the SMS OSD Feature Pack ImageEach time you update the Customsettings.ini file, you need to update the corresponding SMS OSD Feature Pack images.

Note If you updated the group-based rules that are stored in the AdminDB database but not the Customsettings.ini file, you can proceed to the next step in the process.

For each SMS OSD Feature Pack image that you need to update, perform the following steps:

1. Copy the modified Customsettings.ini file to \\servername\ZTI. (where servername is the name of the server hosting the shared folder).

2. On the SMS site server or workstation on which you installed the SMS 2003 OSD Feature Pack, start the SMS Administrator Console.

3. In the SMS Administrator Console, browse to OSDPackage (where OSDPackage is the name of the SMS OSD Feature Pack image that you want to update).


4. Right-click OSDPackage (where OSDPackage is the name of the SMS OSD Feature Pack image that you want to update), click All Tasks, and then click Update Operating System Package Files.

5. Right-click OSDPackage (where OSDPackage is the name of the SMS OSD Feature Pack image that you want to update), click All Tasks, and then click Update Distribution Points.

6. Close the SMS Administrator Console.

Preparing the Windows PE CDs and ImagesIn some deployment scenarios, the target workstations are configured by Windows PE prior to the deployment of Windows XP. You deploy Windows PE first through RIS to configure the partitions used to install Windows XP. Therefore, you need to prepare the Windows PE CDs and images that RIS will use.

To prepare the Windows PE CDs and images, perform the following steps:

1. Add support to Windows PE for additional network adapters.

2. Add Windows Management Instrumentation (WMI) support to Windows PE.

3. Create customized Windows PE images.

4. Transfer the Windows PE CD images to the RIS servers.

5. Add support to your RIS image for additional network adapters.

Note For more information about Windows PE, RIS, and using RIS to deploy Windows PE, see Microsoft Systems Management Server 2003 Operating System Deployment Feature Pack Users Guide, which is included in the SMS OSD Feature Pack installation files.

Adding Support to Windows PE for Additional Network AdaptersEnsure that Windows PE has the appropriate network adapter support for all the adapters in your organization. For more information about adding support to Windows PE for additional network adapters, see the following information in the Additional Resources section of this guide:

Computer Imaging System Feature Team Guide, Enterprise Edition—This guide provides information about and procedures for building a custom Windows PE image that contains all the necessary drivers.

Microsoft Systems Management Server 2003 Operating System Deployment Feature Pack Users Guide—This guide provides information about using the Operating System Image Installation CD wizard to update the SMS OSD Feature Pack version of Windows PE if you need to add additional drivers that were missed when building your custom Windows PE image.

Adding WMI Support to Windows PEYou need to add WMI support to your Windows PE images. The version of Windows PE that is included with the SMS OSD Feature Pack does not include WMI support.

Note If you do not add WMI support to Windows PE, the ZTI scripts will not be able to discover attributes such as HAL type, asset tag, serial number, make, model, or universally unique identifier (UUID). Without adding WMI support, you will be limited to identifying workstations only by MAC address.

Note For more information about how to add WMI support to Windows PE, see the Microsoft Windows Preinstallation Environment User's Guide (Winpe.chm) in the Docs folder of the Windows PE 2004 CD.


You can also use the Computer Imaging System Configuration Tool (Config.hta) to add WMI support to Windows PE. Config.hta is included as a utility in Solution Accelerator for BDD. Config.hta allows you to build, configure and customize images. Config.hta also lets you determine actions to occur after the operating system installation is complete. For more information about creating images by using Config.hta, see Computer Imaging System Feature Team Guide, Enterprise Edition in Additional Resources later in this guide.

Creating A Customized Windows PE ImageAfter you have completed adding support for additional network adapters and WMI, you are ready to create your customized Windows PE CDs.

To create your customized Windows PE image, perform the following steps:

1. Use Mkimg.cmd to create the Windows PE image.

Note For more information about using Mkimg.cmd to create the Windows PE image, see the OEM Preinstallation Kit (OPK), or review the Winpe.chm file in the Docs folder of the Windows PE 1.5 CD.

2. Make the appropriate modifications to Winbom.ini.

3. Customize the Windows PE splash screen.

4. Import the image into the SMS OSD Feature Pack.

Modifying Winbom.iniTo make the appropriate modifications to Winbom.ini, perform the following steps:

1. Open the Winbom.ini file in Notepad.

2. Beneath the WinPE section, open a new line, and then type Quiet=Yes.


4. Copy the Winbom.ini file to the I386\System32 folder in the Windows PE image you created.

Customizing the Windows PE Splash ScreenTo replace the default Windows PE splash screen with a custom splash screen, perform the following steps:

1. On the RIS server, open Windows Explorer

2. Navigate to RISSourcePath (where RISSourcePath is the path to the Winpe folder in the Windows PE image that you want to modify—for example, D: WinPE15\Winpe).

3. Rename the existing Winpe.bmp file to Winpe_Original.bmp.

4. Copy PersonalizedBMP (where PersonalizedBMP is the file name of the customized splash screen you want to display) to Winpe.bmp.

5. Close Windows Explorer.

Importing the Image into the SMS OSD Feature PackTo import the image into the SMS OSD Feature pack, perform the following steps:

1. On the SMS site server or workstation on which you installed the SMS 2003 OSD Feature Pack, start the SMS Administrator Console.

2. In the SMS Administrator Console, right-click Image Packages, click All Tasks, and then click Update Windows PE.

3. Complete the Update Windows PE Wizard by using the information in Table 34


Table 34. Information for Completing the Update Windows PE Wizard

On This Page Do This

Welcome to the Update Windows PE Wizard

Click Next.

Windows PE Settings In the Source folder text box, type Path (where Path is the path to the Windows PE image).

Click Next.

Window PE Update Complete

Click Finish.

4. Close the SMS Administrator Console.

Transferring Windows PE CD Images to the RIS ServersAfter you have created the Windows PE CD images, you are ready to transfer them to the RIS servers.

Note For more information about Windows PE, RIS, and using RIS to deploy Windows PE, see the Microsoft Systems Management Server 2003 Operating System Deployment Feature Pack Users Guide, which is included in the SMS OSD Feature Pack installation files.

Adding Support to the RIS Image for Additional Network AdaptersYou need to add support for additional network adapters that are unavailable in the default configuration of RIS. You can add the network drivers to your RIS image.

Note Before you can complete this procedure, you need to obtain the correct network drivers from your vendor. Obtain the Windows XP versions of the network drivers.

To add support to your RIS image for additional network adapters, copy the files shown in Table 35 (where RISImagePath is the path to the root of the RIS image—for example, D:\RemoteInstall\Setup\English\Images\WinPE15).

Table 35. Source Network Driver Files and Where To Copy Them in a RIS Image

Copy These Files To

*.sys RISImagePath\I386

RISImagePath\I386\system32\drivers

*.inf RISImagePath\I386

RISImagePath\I386\inf

*.din, *.bin, *.exe, or other files

RISImagePath\I386

RISImagePath\I386\system32

For more information about adding additional network adapters to RIS, see the following resources:

Microsoft Knowledge Base Article 823658: “The Operating System Image You Selected Does Not Contain the Necessary Drivers for Your Network Adapter.” This error message occurs during the text-mode part of Setup when you use RIS to deploy an operating system image. (Refer to the Addition Resources section of this guide.)


Microsoft Knowledge Base Article 246184, “How To Add Third-Party OEM Network Adapters to RIS Installations,” which is available in the Additional Resources section of this guide.

StabilizingFigure 12 shows the detailed activities that must be performed during the Stabilizing phase prior to initiating the deployment to production workstations. These activities include testing each server component as well as testing the Windows PE CDs to assure proper operation. The results of this testing are documented in a test report, which is one of the deliverables.

Figure 12. Activities during the Stabilizing phase

Identifying Roles and ResponsibilitiesIn addition to the tasks defined in the following process description, take note of the responsibilities that are allocated to the role clusters. Table 36 defines these focus areas for the different role clusters during this phase.

Table 36. Team Roles and Their Responsibilities During the Stabilizing Phase

Role Focus

Product Management Communications plan execution; deployment launch planning

Program Management Project tracking; bug management


Development Bug resolution; process optimization; code optimization

Test Lab testing; documenting known issues and resolutions

Release Management Pilot management and support; test management and support

Identifying Milestones in the Stabilizing PhaseTable 37 lists the project milestones and deliverables that you need to complete during the Stabilizing phase. The project plan you create needs to include these milestones, the resources required for each milestone, and the length of time to complete each milestone.

Table 37. Stabilizing Phase Project Milestones and Deliverable Description

Stabilizing Phase Milestone


Lab tests and pilot deployments performed

All deployment scenarios—New Computer, Refresh Computer, and Replace Computer—are tested in a lab environment and in pilot deployments.

Test

Deployment teams prepared

Appropriate documentation, troubleshooting processes, diagnostic tools, and common deployment issues are transferred from the design and test teams to the deployment team.

Program Management

Performing Lab Tests and Pilot DeploymentsBefore you begin deployments in your production environment, verify your deployment processes in test labs and by conducting pilot deployments. As you are creating your ZTI design and deployment plans, begin testing in your lab.

You start using the test lab in the Planning phase and continue using the lab throughout the life cycle of the Solution Accelerator for BDD deployment environment. Figure 13 illustrates the sequence of lab testing and pilot deployments in a deployment process.


Figure 13. Sequence of lab testing and pilot deployment in the deployment process

During the lab tests and pilot deployments, you need to:

Test the Solution Accelerator for BDD Deployment Process As early as possible in your deployment process, start testing components of your deployment plan. In the early stages, the type of your testing will be more proof-of-concept and focus on individual components. In the later stages, testing will focus on the overall process. For more information about testing the Solution Accelerator for BDD deployment process, see the Test Feature Team Guide and the Test Case Workbook.

Document Common Deployment Problems and Resolutions As you are going through the various stages of testing and pilot deployments, document any deployment problems that you encounter along with a resolution. For some examples of common deployment problems and resolutions, see Appendix I, Resolving Common ZTI Deployment Problems, later in this guide. The deployment problems listed in this appendix are those found during the testing of these procedures in a lab environment and actual deployments. However, you need to perform your own testing to discover any issues that are unique to your environment.

Document Troubleshooting Procedures and Diagnostic Tools You need to document any troubleshooting procedures and diagnostic tools used during lab testing and pilot deployments. For information about common deployment problems, see Appendix J, ZTI Troubleshooting Procedures and Diagnostic Tools, later in this guide.

Revise Deployment Plans After you have completed your lab tests and pilot deployments, revise your deployment plans to reflect any issues and resolutions that you discovered. Ensure these revised plans are provided to the deployment teams along with the deployment problems and resolutions, troubleshooting procedures, and diagnostic tools.

Preparing Deployment TeamsAfter the lab test and pilot deployments are complete, you need to prepare the deployment teams. The deployment teams need to know what was learned during the lab tests and pilot deployments.


To prepare your deployment teams, complete the following tasks:

Notify the Deployment and Operations feature teams about the deployment start date. Notify the teams when you plan start the deployment so that they can be ready to provide support.

Notify users of changes in contacts for support (operations to deployment). Users need to know the appropriate contact information for deployment-related issues (if this number is different from the usual support contact information).

Communicate the group of workstations to be deployed. Provide the deployment teams with a list of the workstations to be included in the deployment. Ensure that you provide the appropriate sequencing of groups of workstations when required.

Identify workstation configurations that were successfully deployed during lab and pilot tests. Ensure that the deployment teams know the configurations that should work without difficulty, based on lessons learned in the lab test and pilot deployments.

Identify workstation configurations that failed during lab and pilot testing. Ensure that the deployment teams know the workstation configurations that resulted in problems so that they can monitor those configurations more closely.

Identify any troubleshooting procedures and diagnostic tools. Provide the deployment teams with documentation that describes troubleshooting procedures and diagnostic tools used during the lab testing and pilot deployments.

DeployingWith the Deploying and Stabilizing phases complete, the servers are ready to process workstation deployments. Figure 14 provides the detailed task breakdown for the Deploying phase.


Figure 14. Activities during the Deploying phase

Roles and ResponsibilitiesIn addition to the tasks defined in the following process description, take note of the responsibilities that are allocated to the role clusters. Table 38 defines these focus areas for the different role clusters during this phase.

Table 38. Team Roles and Their Responsibilities During the Deploying Phase

Role Focus



Development Bug resolution; code optimization

User Experience Training materials

Test Testing and bug reporting

Release Management Pilot management and support; deployment planning; operations and support training, executing the deployments


Milestones in the Deploying PhaseTable 39 lists the project milestones and deliverables that you need to complete during the Deploying phase. The project plan you create needs to include these milestones, the resources required for each milestone, and the length of time to complete each milestone.

Table 39. Deploying Phase Project Milestones and Deliverable Description

Deploying Phase Milestone


Deployment Wizard run The appropriate combination of scenarios (New Computer, Refresh Computer, Replace Computer) is identified.

Deployment

Running the Deployment WizardTo initiate the deployment of Windows XP to targeted workstations, run the Deployment Wizard in the SMS Administrator Console. The high-level steps for completing the Deployment Wizard include:

1. In the SMS Administrator console, navigate to OSDImage (where OSDImage is the name of the SMS OSD Feature Pack operating system image you want to deploy).

2. Select the appropriate distribution points.

3. Select the applications to advertise.

4. Select the target collection for the image.

For more information about how to run the Deployment Wizard, see the Microsoft Systems Management Server 2003 Operating System Deployment Feature Pack Users Guide in the Additional Resources section of this guide.

Note The images that you distribute to the distribution points are very large. For instances in which low-speed links connect sites, the images might not be available on the distribution points within the site for long periods of time (such as 24 hours or longer).

Transitioning to OperationsAfter the initial deployment is complete and proper workstation operation has been verified, the process is transitioned from a deployment initiative to an operating initiative. The information technology (IT) operations group is then responsible for the ongoing workstation maintenance and support. This process is typically well structured and formal, where documentation, knowledge, and other materials are formally transferred from one group to another.

Roles and ResponsibilitiesIn addition to the tasks defined in the following process description, take note of the responsibilities that are allocated to the role clusters. Table 40 defines these focus areas for the different role clusters during this phase.

Table 40. Team Roles and Their Responsibilities During the Transition to Operations

Role Focus



Development Bug resolution; code optimization


User Experience Training materials

Test Testing and bug reporting

Release Management Pilot management and support; deployment planning; operations and support training, executing the deployments

Milestones in the Transition to OperationsTable 41 lists the project milestones and deliverables that you need to complete during the Transition to Operations. The project plan you create needs to include these milestones, the resources required for each milestone, and the length of time to complete each milestone.

Table 41. Transition to Operations Project Milestones and Deliverable Description

Transition to Operations Milestone


Transition preparations complete

The operations and deployment teams have been notified of the transition date. Users are now aware of the change in contact information for support.

Deployment

Current deployment status communicated

The current status of all workstation being transitioned is communicated. Any updates to troubleshooting procedures and diagnostic tools are also communicated.

Deployment

Preparing for the TransitionAfter the deployment of a batch of workstations is complete, you are ready to transition the support of those workstations to operations. In preparation for that transition, you need to:

Notify the Deployment and Operations feature teams of the transition date. Ensure that the Deployment and Operations feature teams are aware of when the support for the workstations will be transitioned. The Operations feature team must be ready for users to call with support questions, and the Deployment feature team must know to direct users to the Operations feature team for future support.

Notify users of changes in contacts for support (deployment to operations). Users need to know when they should stop contacting the Deployment feature team for support. Supply users with the numbers and contact information for the Operations feature team.

Communicating the Current Deployment StatusJust before you make the transition from the deployment team to the operations team, you need to inform the Operations feature team of the current status of the deployment. Communicate the current deployment status each time a group of workstations is migrated.

Communicate the current deployment status by identifying the workstations that:

Have been successfully deployed. You need to make certain the Operations feature team has an accurate list of workstations that have been successfully deployed. This list will provide them with an estimate of how many deployed workstations they are taking responsibility for after the transition. Also, the list will give them an idea of the location for the transitioned workstations.

Failed during the deployment process and were rolled back. The Operations feature team needs to know the workstations in the group that are in their original state. In this way,


the team will know that those workstations should operate as before and should not initiate support calls based on the deployment.

Are pending deployment. The Operations feature team needs to know if workstations in the group are still pending deployment. For those workstations, they will forward support issues back to the Deployment feature team.

In addition, you need to communicate any updates to troubleshooting procedures and diagnostic tools since the last group of workstations was transitioned.

Note For more information about troubleshooting procedures and diagnostic tools, see Appendix I, Resolving Common ZTI Deployment Problems, later in this guide.

Additional Resources MSF Team Model

http://www.microsoft.com/downloads/details.aspx?FamilyID=c54114a3-7cc6-4fa7-ab09-2083c768e9ab&DisplayLang=en

DiskPart

http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/diskpart.mspx

Computer Imaging System Feature Team Guide, Enterprise Edition

Included in Solution Accelerator for BDD

Lite Touch Deployment Feature Team Guide, Enterprise Edition

Included in Solution Accelerator for BDD

Microsoft Knowledge Base Article 823658, “The Operating System Image You Selected Does Not Contain the Necessary Drivers for Your Network Adapter”

http://support.microsoft.com/?id=823658

Microsoft Knowledge Base Article 246184, “How To Add Third-Party OEM Network Adapters to RIS Installations”

http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B246184

Description of Client Installation Wizard Screens for Remote Installation Services

http://support.microsoft.com/default.aspx?scid=kb;en-us;268325

SMS 2003 SP1 Product Overview

http://www.microsoft.com/smserver/evaluation/overview/default.asp

Business Desktop Deployment User State Migration Feature Team Guide

http://www.microsoft.com/technet/itsolutions/techguide/mso/bdd/bddusmt.mspx

Microsoft Systems Management Server 2003 Operating System Deployment Feature Pack Users Guide

Included in the SMS 2003 OSD Feature Pack


Appendix A: Sample Customsettings.ini FilesThe common scenarios for applying configuration settings by using Customsettings.ini include:

All workstation-based configuration settings in Customsettings.ini only.

All workstation-based configuration settings in the AdminDB database only.

Workstation-based configuration settings in both Customsettings.ini and the AdminDB database.

Settings in Customsettings.ini OnlyThis sample Customsettings.ini file assumes that all the configuration settings are stored in the Customsettings.ini file. For examples that store configuration settings in the AdminDB database, see Workstations Settings in AdminDB Database Only and Workstation Settings in AdminDB database and Customsettings.ini later in this guide.

In this sample, there is no SQL keyword in the Priority attribute and all the workstation-based configuration settings are in the [xx:xx:xx:xx:xx:xx] sections (where xx:xx:xx:xx:xx:xx is the MAC address of the workstation.

[Settings]Priority= MACADDRESS, DefaultGateway, DefaultCustomKeysUserData=UDShare,UDDir,UDProfiles,SLShare,OSInstall,Packages(*),Administrators(*)CustomKeysSysprep=ComputerName,TimeZone,JoinDomain,MachineObjectOUOSDVariableKeys=OSDINSTALLSILENT,OSDINSTALLPACKAGE,OSDINSTALLPROGRAM,OSDNEWMACHINENAMEScanStateArgs=/i:miguser.inf /i:migapp.inf /i:migsys.inf /i:sysfiles.inf /i:updateuser.inf /v:7 /x /s /f /o /cLoadStateArgs=/v:7 /cUserExit=ZTIUserExit.vbs

[Default]UDShare=\\NYC-AM-FIL-01\MigDataSLShare=\\NYC-AM-FIL-01\LogsUDProfiles=*\*OSDINSTALLSILENT=1OSDINSTALLPACKAGE=NYC00001OSDINSTALLPROGRAM=InstallXPTimeZone=010JoinDomain=WOODGROVEBANKMachineObjectOU= OU=Workstations,DC=americas,DC=corp,DC=woodgrovebank,DC=comComputerName=%OSDNEWMACHINENAME%UDDir=%OSDCOMPUTERNAME%OSInstall=Y


[NYC]UDShare=\\NYC-AM-FIL-01\MigData


SLShare=\\NYC-AM-FIL-01\LogsPackages1=NYC00010-InstallPackages2=NYC00011-InstallAdministrator1=WOODGROVEBANK\NYC Help Desk Staff

[DALLAS]UDShare=\\DAL-AM-FIL-01\MigDataSLShare=\\DAL-AM-FIL-01\LogsSQLDefault=DB_DALAdministrator1=WOODGROVEBANK\DAL Help Desk Staff

[WASHINGTON]UDShare=\\WSG-AM-FIL-01\MigDataSLShare=\\WSG-AM-FIL-01\LogsAdministrator1=WOODGROVEBANK\WSG Help Desk Staff

[00:03:FF:CB:4E:C2]OSDNEWMACHINENAME=WasW2KTimeZone=004

[00:0F:20:35:DE:AC]OSDNEWMACHINENAME=HPD530-1TimeZone=008

[00:03:FF:FE:FF:FF]OSDINSTALLPACKAGE=NYC00002OSDINSTALLPROGRAM=SpecialXPOSDNEWMACHINENAME=BVMXP

[SysprepInfMapping]ComputerName=UserDataTimeZone=GuiUnattendedJoinDomain=IdentificationMachineObjectOU=Identification

Workstation Settings in AdminDB Database OnlyThis sample Customsettings.ini file assumes that all the workstation configuration settings are stored in the AdminDB database. For examples that store configuration settings in Customsettings.ini, see Workstations Settings in Customsettings.ini Only earlier in this guide and Workstation Settings in AdminDB Database and Customsettings.ini later in this guide.

In this sample, the SQL keyword is listed in the Priority attribute and all the workstation-based configuration settings are stored in the AdminDB database referenced by the [DB_xxx] sections (where xxx is NYC, DAL, and WSG).

[Settings]Priority= DefaultGateway, SQL, DefaultCustomKeysUserData=UDShare,UDDir,UDProfiles,SLShare,OSInstall,JoinDomainCustomKeysSysprep=ComputerName,TimeZone,JoinDomain,MachineObjectOUOSDVariableKeys=OSDINSTALLSILENT,OSDINSTALLPACKAGE,OSDINSTALLPROGRAM,OSDNEWMACHINENAMEScanStateArgs=/i:miguser.inf /i:migapp.inf /i:migsys.inf /i:sysfiles.inf /i:updateuser.inf /v:7 /x /s /f /o /cLoadStateArgs=/v:7 /cUserExit=ZTIUserExit.vbs


[Default]UDShare=\\NYC-AM-FIL-01\MigDataSLShare=\\NYC-AM-FIL-01\LogsUDProfiles=*\*OSDINSTALLSILENT=1OSDINSTALLPACKAGE=NYC00001OSDINSTALLPROGRAM=InstallXPTimeZone=010JoinDomain=americas.corp.woodgrovebank.comMachineObjectOU= OU=Workstations,DC=americas,DC=corp,DC=woodgrovebank,DC=comComputerName=%OSDNEWMACHINENAME%UDDir=%OSDCOMPUTERNAME%OSInstall=Y


[NYC]SQLDefault=DB_NYC

[DALLAS]SQLDefault=DB_DAL

[WASHINGTON]SQLDefaul=DB_WSG


[DB_DAL]SQLServer=DAL-AM-FIL-01Database=BDDAdminDBTable=BDDAdminCoreParameters=MacAddress

[DB_WSG]SQLServer=WSG-AM-DC-01Database=BDDAdminDBTable=BDDAdminCoreParameters=MacAddress

[SMS]SQLServer=NYC-AM-SMS-01Database=SMS_NYCTable=v_ProgramParameters=PackageID,ProgramName



Workstation Settings in AdminDB Database and Customsettings.iniThis sample Customsettings.ini file assumes that all the configuration settings are stored in the Customsettings.ini file. For examples that store configuration settings in SQL Server, see Workstations Settings in Customsettings.ini Only and Workstation Settings in SQL Server Only earlier in this guide.

In this sample, there is a MACADDRESS and a SQL keyword in the Priority attribute. The workstation-based configuration settings are found in the [xx:xx:xx:xx:xx:xx] sections and in the AdminDB database (where xx:xx:xx:xx:xx:xx is the MAC address of the workstation. This is a mixture of the two previous methods.

[Settings]Priority= DefaultGateway, MACADDRESS, SQL, DefaultCustomKeysUserData=UDShare,UDDir,UDProfiles,SLShare,OSInstall,JoinDomainCustomKeysSysprep=ComputerName,TimeZone,JoinDomain,MachineObjectOUOSDVariableKeys=OSDINSTALLSILENT,OSDINSTALLPACKAGE,OSDINSTALLPROGRAM,OSDNEWMACHINENAMEScanStateArgs=/i:miguser.inf /i:migapp.inf /i:migsys.inf /i:sysfiles.inf /i:updateuser.inf /v:7 /x /s /f /o /cLoadStateArgs=/v:7 /cUserExit=ZTIUserExit.vbs

[Default]UDShare=\\NYC-AM-FIL-01\MigDataSLShare=\\NYC-AM-FIL-01\LogsUDProfiles=*\*OSDINSTALLSILENT=1OSDINSTALLPACKAGE=NYC00001OSDINSTALLPROGRAM=InstallXPTimeZone=010JoinDomain=americas.corp.woodgrovebank.comMachineObjectOU= OU=Workstations,DC=americas,DC=corp,DC=woodgrovebank,DC=comComputerName=%OSDNEWMACHINENAME%UDDir=%OSDCOMPUTERNAME%OSInstall=Y


[NYC]UDShare=\\NYC-AM-FIL-01\MigDataSLShare=\\NYC-AM-FIL-01\LogsUDProfiles=*\*JoinDomain=americas.corp.woodgrovebank.comMachineObjectOU= OU=Workstations,DC=americas,DC=corp,DC=woodgrovebank,DC=comSQLDefault=DB_NYC

[DALLAS]UDShare=\\DAL-AM-FIL-01\MigDataSLShare=\\DAL-AM-FIL-01\LogsJoinDomain=americas.corp.woodgrovebank.com


UDProfiles=*\*SQLDefault=DB_DAL

[WASHINGTON]UDShare=\\WSG-AM-DC-01\MigDataSLShare=\\WSG-AM-DC-01\LogsUDProfiles=*\*JoinDomain=americas.corp.woodgrovebank.com

[02:12:01:03:01:01]OSDINSTALLSILENT=1OSDINSTALLPACKAGE=NYC00004OSDINSTALLPROGRAM=NYC_VMOSDNEWMACHINENAME=WasCL01TimeZone=004

[00:0D:56:9B:44:9E]OSDINSTALLSILENT=1OSDINSTALLPACKAGE=NYC00002OSDINSTALLPROGRAM=NYC_GX270OSDNEWMACHINENAME=WasCL02TimeZone=004

[00:0D:56:9B:42:5E]'All CL03 info located on the AdminDB'OSDINSTALLSILENT=1'OSDINSTALLPACKAGE=NYC00002'OSDINSTALLPROGRAM=NYC_GX270'OSDNEWMACHINENAME=WasCL03'TimeZone=004

[00:0B:CD:73:0E:CB]OSDINSTALLSILENT=1OSDINSTALLPACKAGE=NYC00002OSDINSTALLPROGRAM=NYC_GX270OSDNEWMACHINENAME=WasCL04TimeZone=004

[00:0F:1F:A0:7E:60]'Replacement scenario from CLI-04 to CLI-06'UDDir is in AdminDBOSDINSTALLSILENT=1OSDINSTALLPACKAGE=NYC00003OSDINSTALLPROGRAM=NYC_D600OSDNEWMACHINENAME=WasCL06'UDDIR=NYC-AM-CLI-04TimeZone=004


[DB_DAL]SQLServer=DAL-AM-SMS-01Database=BDDAdminDBTable=BDDAdminCore


Parameters=MacAddress

[SMS]SQLServer=NYC-AM-SMS-01Database=SMS_NYCTable=v_ProgramParameters=PackageID,ProgramName


Appendix B: Customsettings.ini ReferenceZTI requires the ability to dynamically determine how to proceed based on a set of rules. These rules are defined in a single configuration file named Customsettings.ini. The rules applied during the ZTI processing on a particular machine are based on:

Information obtained from the machine itself, such as MAC address, asset tag, machine GUID, TCP/IP default gateway, HAL, computer name, etc.

Information retrieved from one or more databases. Based on the machine information, it is possible to dynamically determine how the ZTI process should proceed.

Static information. If some information required for the ZTI process cannot be determined using the machine or database information retrieved, one or more sections (for example,. [Default]) can be used to fill in the missing values.

This Customsettings.ini file should be placed in the same directory as the main ZTI script, ZeroTouchInstallation.vbs. This script will read the contents of the file during the appropriate phase in the ZTI process.

Configuring the [Settings] SectionThe [Settings] section is the section that determines how the remainder of the Customsettings.ini file is processed. A typical [Settings] section is illustrated in Listing 24.

[Settings]Priority=MacAddress, DefaultGateway, Default CustomKeysUserData=UDShare, UDDir, UDProfiles, SLShare, OSInstall, Packages(*), Administrators(*)CustomKeysSysprep=ComputerName, TimeZone, JoinDomainOSDVariableKeys=OSDINSTALLSILENT, OSDINSTALLPACKAGE, OSDINSTALLPROGRAM, OSDNEWMACHINENAMEScanStateArgs=/i:miguser.inf /i:migapp.inf /i:migsys.inf /i:sysfiles.inf /i:updateuser.inf /v:7 /x /s /f /o /cLoadStateArgs=/v:7 /cUserExit=CustomScript.vbs

Listing 24. [Settings] section in Customsettings.ini

Note All values should be included on one line. The lines wrap in this example are caused by the limitations of the document width.

The following are required values in the [Settings] section:

Priority

CustomKeysUserData


CustomKeysSysprep

OSDVariableKeys

ScanStateArgs

LoadStateArgs

The UserExit value is optional. Each of these sections is described in further detail later in this guide.

PriorityThe Priority value determines the sequence and section of where to find configuration values. Each section will be searched in the order specified. Once all the required custom key values are found, the remaining sections are not used.

The supported values for Priority are listed in Table 42.

Table 42. Priority Key Values and their Description

Priority Key Values

Description

DefaultGateway Each TCP/IP default gateway address (for example, 10.1.1.1) will be used to find a similarly-named section (for example, [10.1.1.1]) in the configuration file. The section does not have to exist. If it is found, it will be searched for custom key values not yet populated.

LocalDataName Any local machine value known to the ZTI script can be used to identify a section name in the configuration file. For example, specifying “HostName” would cause the script to look for a section with the current machine name. Some values, like “MacAddress”, will result in multiple section names being checked, since a machine can have multiple MAC addresses. The values that can be specified for <LocalDataName> are: OSVersion, HALName, Hostname, AssetTag, SerialNumber, Make, Model, Product, UUID, IPAddress, MacAddress.

<CustomSection> One or more specific section names can be specified. For example, if “MySection” were included in the Priority list, the [MySection] section would be searched for any custom key values not yet populated.

Example: Priority=MacAddress, DefaultGateway, Default

CustomKeysUserDataThis value defines the custom user data keys that must be populated for the ZTI process.

The supported values for CustomKeysUserData are listed in Table 43.

Table 43. CustomKeysUserData and Their Description

CustomKeysUserData

Description

UDShare Share to save User Data

UDDir Directory under UDShare to save User Data

UDProfiles User profile on local machine to save. You can specify multiple users by separating the users with a comma.


SLShare Share to save log file from custom scripts.

OSInstall Flag value to control the deployment process. This flag must be set to Y for an operating system image to be deployed to the machine. (If OSInstall is not listed in the CustomKeysUserData key list, images can be deployed to any machine.)

Packages(*) A collection of package IDs and programs that should be installed on a machine during the State Restore phase. The (*) designator marks this key as a collection, so values are added to the collection as they are encountered (building a list); duplicates are ignored. Values must be specified in the “NNN00000-Program” format, where “NNN00000” is the SMS package ID and Program is the SMS program name.

Administrators(*) A collection of groups or users that should be added to the Administrators group (or the localized or renamed equivalent) on the deployed machine. The (*) designator marks this key as a collection, so values are added to the collection as they are encountered (building a list); duplicates are ignored.

PowerUsers(*) A collection of groups or users that should be added to the Power Users group (or the localized or renamed equivalent) on the deployed machine. The “(*)” designator marks this key as a collection, so values are added to the collection as they are encountered (building a list); duplicates are ignored.

DriverPath or DriverPath(*)

The UNC path specified by this custom key will be copied to the local machines “\Drivers” directory. All “\Drivers” subdirectories will be scanned looking for drivers; any not already included in the Sysprep.inf’s “OemPnpDriverPath” value will be added to that path (subject to the 4096 character limit on this value).

ImageSize The actual size of the OS image (contained in the OS.WIM file) which should be used instead of a size estimate.

ImageSizeMultiplier

If ImageSize is not specified, this value is used as a multiplier with the size of the OS image (contained in the OS.WIM file). The size will be multiplied by this value to get an estimated size at deployment. If not specified, a default value of 2.5 will be used (assuming 2.5X compression within the WIM file).

Example: CustomKeysUserData=UDShare, UDDir, UDProfiles, SLShare, OSInstall, Packages(*), Administrators(*), PowerUsers(*), DriverPath, ImageSize

CustomKeysSysprepThis value defines the data keys that will be used to update the Sysprep.inf file, which controls how the machine is initially configured when the operating system first starts up. Each value specified should correspond to a value in the Sysprep.inf file. The [SysprepInfMapping] section must contain one entry for each of these values which specifies the section of the Sysprep.inf file that contains the specific value.

A list of common values for CustomKeysSysprep are listed in Table 44. Any value can be supported; it just needs to be to defined on the CustomKeysSysprep line and in the [SysprepInfMapping] section.

Table 44. CustomKeysSysprep and Their Description

CustomKeysSyspr Description


ep

ComputerName Computer name to be assigned to the workstation.

TimeZone Time zone in which the workstations is located.

JoinDomain Domain name of the domain to which the workstation will belong.

MachineObjectOU Active Directory organization unit where the computer account of the workstation will be created.

Example: CustomKeysSysprep=ComputerName, TimeZone, JoinDomain, MachineObjectOU

OSDVariableKeysThis value defines the data keys that are needed to automate or control the SMS 2003 OSD Feature Pack image installation process.

The supported values for OSDVariableKeys are listed in Table 45.

Table 45. OSDVariableKeys and Their Description

OSDVariableKeys Description

OSDINSTALLSILENT This value must be set to a value (normally 1) to indicate that the SMS 2003 OSD Feature Pack Image Installation Wizard should not be displayed. In order for this to work properly, the next three values must be specified as well.

OSDINSTALLPACKAGE This value specifies the SMS package ID (for example, SMS00001) for the OS package that should be installed on the machine.

OSDINSTALLPROGRAM

This value specifies the OS program name (for example, ZTI Install) within the specified OS package that should be executed. All ZTI custom actions should be defined as part of this OS program definition.

OSDNEWMACHINENAME

For new machines, this value must be populated so that the SMS 2003 OSD Feature Pack knows what name to assign to a new machine. This value can be set to * to indicate that Windows should generate a name during mini-setup; the value can then be overridden later in the process by ZTI through editing the Sysprep.inf file.

Example: OSDVariableKeys=OSDINSTALLSILENT, OSDINSTALLPACKAGE, OSDINSTALLPROGRAM, OSDNEWMACHINENAME

ScanStateArgsThis value specifies the arguments that should be passed to the USMT Scanstate process. The ZTI script will determine which version of Scanstate to call (Scanstate.exe for Unicode systems, Scanstatea.exe for ANSI systems) and will insert the appropriate logging, progress, and state store parameters. If this value is not included in the settings file, the user state backup process will be skipped.


Example: ScanStateArgs=/i:miguser.inf /i:migapp.inf /i:migsys.inf /i:sysfiles.inf /i:updateuser.inf /v:7 /x /s /f /o /c

LoadStateArgsThis value specifies the arguments that should be passed to the USMT Loadstate process. The ZTI script will insert the appropriate logging, progress, and state store parameters. If this value is not included in the settings file, the user state restore process will be skipped.

Example:LoadStateArgs=/v:7 /c

UserExitThis value specifies the name of a script that should be called as part of the phase processing. This enables custom script functions to be called during the ZTI processing without modifying the main ZeroTouchInstallation.vbs script. It will be called twice:

After machine information has been gathered but before the processing for this particular phase has been performed. In this case, the exit can set a parameter (bSkip) to indicate that the remaining process for this phase should be skipped.

After the normal processing for the phase has been completed, allowing the exit to change any of the values retrieved.

A sample user exit function written in VBScript can be seen in Appendix G: Sample User Exit Function later in this guide.

Example:UserExit=MyUserExit.vbs

Configuring the [SysprepInfMapping] SectionThe [SysprepInfMapping] section, as illustrated in Listing 25, is required so that ZTI knows how to edit the Sysprep.inf file using the custom key values defined previously. Since each value could exist in one of several Sysprep.inf sections, it is necessary to indicate which section contains the value.


Listing 25. [SysprepInfMapping] section in Customsettings.ini

In each case the syntax is as follows and described in Table 46:

<CustomKeyName>=<SysprepInfSection>

Table 46. [SysprepInfMapping] Values and Their Description

SysprepMapping Value Description

<CustomKeyName> The name specified (for example, “ComputerName”) must match one of the custom key names defined in the [Settings] section. It will also be used as the name in the Sysprep.inf file.


<SysprepInfSection> The value specified (for example, “UserData”) indicates the section name in the Sysprep.inf file (in this case, “[UserData]”).

Configuring the [DefaultGateway] SectionThe [DefaultGateway] section, as illustrated in Listing 26, is used to provide “friendly” names for each TCP/IP default gateway value found on a computer. This allows multiple default gateway addresses to point to a single section name. If an entry is not found in the [DefaultGateway] section for a particular TCP/IP default gateway value, that default gateway will be ignored. A typical [DefaultGateway] section may look like this:

[DefaultGateway]10.1.1.1=MainOffice10.2.1.1=RemoteOffice

Listing 26. [DefaultGateway] section in Customsettings.ini


<DefaultGatewayAddress>=<CustomSection>

Table 47. [DefaultGateway] Values and Their Description

SysprepMapping Value Description

< DefaultGatewayAddress >

The value specified (for example, “10.1.1.1”) is a TCP/IP default gateway address on the current machine.

< CustomSection > For the default gateway address specified (for example, “10.1.1.1”) the specified custom section name (for example, “MainOffice”) should be used to get ZTI custom key settings.

Configuring Custom SectionsCustom sections, as illustrated in listing, are used to specify the actual custom key values that should be used, to specify the database that should be used to retrieve the custom key values, or both. A typical custom section may look like this:

[00:03:FF:CB:4E:C2]UDShare=\\SERVER\MigDataSLShare=\\SERVER\LogsOSDINSTALLSILENT=1OSDINSTALLPACKAGE=SMS00001OSDINSTALLPROGRAM=ZTI InstallOSDNEWMACHINENAME=WasWIN2000PROComputerName=WasWIN2000PROTimeZone=004

Listing 27. [SysprepInfMapping] section in Customsettings.ini

Each name specified corresponds to a custom key value specified in the [Settings] section; the value specified is then assigned to that custom key, but only if that custom key does not already have a value (so the first match from any custom section is used). Any custom key names not specified will not be changed.

The following optional special keys can also be specified:

The SQLDefault key instructs the ZTI scripts to use the values in the section indicated to connect to SQL Server to look for custom key values; any values retrieved from SQL Server will be used before considering any specific values in the custom settings section (considered


“fallback” values if no database match is found). See the next section for a description of a database section.

The UserExit key specifies the name of a script that should be called before processing this section. This enables custom script functions to be called during the ZTI processing without modifying the main ZeroTouchInstallation.vbs script.

The “Subsection” key specifies the name of another section that should be checked for custom key values. The value of the “Subsection” key can include variables, e.g. “%Model%”, which will automatically be replaced with the actual value.


[<CustomSection>]SQLDefault=<SQLSection>UserExit=<UserExitScriptFile>Subsection=<CustomSectionWithVariables><CustomKeyName>=<KeyValue>

Table 48. CustomSection Values and their Description

CustomSection Value Description

<CustomSection> The name of the custom section.

SQLDefault An optional value specifying the name of a database section that specifies the information necessary for connecting to SQL Server to retrieve custom key values.

UserExit Specifies the name of a script that should be called as part of the section processing. This enables custom script functions to be called during the ZTI processing without modifying the main ZeroTouchInstallation.vbs script. It will be called twice:

Before any values have been read from the .ini file section or database. In this case, the exit can set a parameter (bSkip) to indicate that the remaining processing for this section should be skipped.

After the normal processing for the section has been completed, allowing the exit to change any of the values retrieved.

Example:

UserExit=MyUserExit.vbs

For an example of a sample user exit function written in VBScript, see Appendix G: Sample User Exit Function later in this guide.

Subsection Specifies a subsection that should also be checked for further values, with all variables automatically replaced with the proper value. This allows the CustomSettings.ini to represent more complex “and” conditions between multiple variables.

Example:

[Settings]Priority=Make

[Dell Computer Corporation]Subsection=Dell-%Model%

[Dell-Latitude D600]CustomKeyName=CustomKeyValue

<CustomKeyName> One of the custom key names specified in the [Settings] section.


<KeyValue> The value that should be assigned to the specified custom key name (assuming the custom key does not already have a value).

Configuring Database SectionTo offer the greatest level of flexibility, the ZTI scripts can query SQL Server to obtain values for custom key settings specified in the [Settings] section. To query SQL Server, more information is needed such as the name of the server, the database on that server, the name of the table, and details of the table structure. All of these values can be specified in a database section.

Multiple database sections can be specified, each with different SQL Server information, further enhancing the flexibility. One special database section, named “[SMS]” must be defined if packages are specified above; this special section is used to resolve SMS package IDs and program names to command lines.


[<CustomSection>]SQLDefault=<SQLSection>UserExit=<UserExitScriptFile><CustomKeyName>=<KeyValue>

A typical database section may appear as follows:

[BDDAdminDB]SQLServer=SERVER01Database=BDDAdminDBTable=BDDAdminCoreParameters=MacAddressSLShare=ScriptLogShare

In this particular case, the ZTI scripts will connect to database “BDDAdminDB” on server “SERVER01” and query table “BDDAdminCore” using the “MacAddress” custom key as the database query criteria (matched up with the appropriate database column ID). Additionally, a column name translation is specified: the “SLShare” custom key name should be matched up with the “ScriptLogShare” database column. The SQL query that would be generated as a result of this would be:

SELECT * FROM BDDAdminCore WHERE MacAddress IN ('00:00:00:00:00:00','11:11:11:11:11:11')

The following example shows multiple parameters being specified:

[BDDAdminDB]SQLServer=SERVER01Database=BDDAdminDBTable=BDDAdminCoreParameters=Make, Model

This would result in the following SQL statement:

SELECT * FROM BDDAdminCore WHERE Make = 'Acme' and Model = 'CorporatePC'

In the case of a stored procedure, the results would be slightly different:

[BDDAdminDB]SQLServer=SERVER01Database=BDDAdminDBStoredProcedure=spBDDAdminParameters=Make, Model

This would result in the following SQL statement:


EXECUTE spBDDAdmin 'Acme', 'CorporatePC'

The general syntax of a database section is:

[<DatabaseSection>]SQLServer=<SQLServerName>Database=<SQLDatabaseName>Table=<SQLTableName>StoredProcedure=<SQLStoredProcedureName>Parameters=<Any local key or custom key>UseEncryptedFile=<True | False>EncryptedFile=<EncryptedFileName>DomID=<DomainUserID>DomPwd=<DomainPassword>DBID=<DatabbaseUserID>DBPwd=<DatabasePassword><CustomKeyName>=<SQLColumnName>

Table 49. DatabaseSection Values and Their Description

SysprepMapping Value

Description

< DatabaseSection >

The name of the database section.

SQLServer The name of the server (for example, “SERVER01”) that is running SQL Server.

Database The name of the SQL Server database (on the specified server, for example, “BDDAdminDB”) that should be used.

Table The name of the SQL Server table (on the specified server and database, for example, “BDDAdminCore”) that should be queried. If a “StoredProcedure” value is specified, a “Table” value cannot be specified.

StoredProcedure The name of the SQL Server stored procedure (on the specified server and database, for example, “BDDAdminCore”) that should be executed. If a “Table” value is specified, a “StoredProcedure” value cannot be specified.

Parameters The custom key or local key values that should be used when querying the database. Multiple values can be specified, separated by commas. If the key specified has multiple values (for example, “MacAddress”), an “IN” clause will be added to a table query, but only the first value will be used when calling the stored procedure.

DBID This optional value specifies a SQL Server user ID needed for making a “standard security” or “SQL security” connection to the database. If not specified, an “integrated security” (or “Windows security”) connection will be made. If an encrypted file is being used, the value will be retrieved from that file instead.

DBPwd This optional value specifies the password that corresponds to the SQL Server user ID specified. If an encrypted file is being used, the value will be retrieved from that file instead.

<CustomKeyName> This specifies the name of the custom key that needs to be remapped into a different SQL Server column.

<SQLColumName> The SQL Server column name that should be used instead of the custom key name.


Appendix D: AdminDB Database SchemaTable 50 lists the schema for the BDDAdminCore table used by the AdminDB console and the corresponding information for each field.

Table 50. Schema for the Database Used by the ZTI AdminDB Console

Field Type Size

Nulls

Mandatory

Description and Example

ID Int 4 Y

ComputerName nvarchar

50 Y Computer name of the workstation.

MacAddress nvarchar

50 Y MAC address of the workstation ( example: 00:04:75:c2:f2:3e

Note This value must be unique in the database

AssetTag nvarchar

50 Y Asset tag of the workstation.

SerialNumber nvarchar

50 Y Serial number of the workstation

Make nvarchar

50 Y Manufacturer of the workstation

Model nvarchar

50 Y Model number of the workstation.

UDShare nvarchar

255

Y UNC path to the share where user data is stored.

UDDir nvarchar

255

Y Existing computer name (used to make folder beneath UDShare).

UDProfiles nvarchar

255

Y Name of user profile being migrated.

SLShare nvarchar

255

Y UNC path to the share where ZTI script creates log files.

TimeZone nvarchar

50 Y Time zone where workstation will be deployed

AdminPassword nvarchar

50 Y Password to be assigned to local administrator account on workstation.

DomainAdmin nvarchar

50 Y Domain-based account name that is a member of the Domain Administrators group.

DomainAdminPassword

nvarchar

50 Y Password for the domain-based account.

JoinDomain nvarchar

50 Y Domain name that the workstation will join.

MachineObjectOU nvarchar

255

Y Active Directory OU where the machine account will be created.


JoinWorkGroup nvarchar

50 Y Workgroup name that the workstation will join.

FullName nvarchar

50 Y User name configured on the workstation.

OrgName nvarchar

50 Y Organization name to be configured on the workstation.

Command0 nvarchar

255

Y Obsolete field that is no longer used by the Zerotouchinstallation.vbs.

OsdInstallSilent char 1 Y Indicates if the SMS 2003 OSD Feature Pack image installation wizard should be displayed (1 in this field indicates the wizard will not be displayed).

OsdInstallPackage nvarchar

255

Y Unique ID of the OS Deployment package that the OS Image Installation CD or RIS should install. This is set by the custom program or script specified in the Operating System Image Installation CD Wizard

OsdInstallProgram nvarchar

255

Y Name of the OS Deployment Program that the OS Image Installation CD or RIS should install. This is set by the custom program or script specified in the Operating System Image Installation CD Wizard

OsdNewMachineName

nvarchar

255

Y Name to assign to the computer when the new operating system is installed. This variable is used in the new computer and replace computer installation scenarios when running the OS Image Installation CD or from RIS. In a refresh computer scenario, ZTI can rename the machine by including the “ComputerName=%OSDNEWMACHINENAME% line in the default section.

OsdStatePath nvarchar

255

Y Path where OSD stores user state migration information.

OSInstall char 1 Y Flag monitored by Zerotouchinstallation.vbs to determine of the script should continue to run. If set to False, Zertotouchinstallation.vbs

AdminUser nvarchar

255

Y Indicates the username who added or last modified the record.


Appendix E: AdminDB .csv File Format ReferenceTable 51 lists the fields in .csv files created by the ZTI AdminDB console and the corresponding information for each field.

Table 51. Fields in .csv Files Created by the ZTI AdminDB Console

Field Type Size Validated

Description and Example

UpdateFlag nvarchar

1 Y For import:

A = add a record.

M = modify a record.

D = delete a record

For export the value is blank.

ComputerName nvarchar

50 Y Computer name of the workstation.

MacAddress nvarchar

50 Y MAC address of the workstation

Example: 00:04:75:c2:f2:3e

AssetTag nvarchar

50 Asset tag of the workstation.

SerialNumber nvarchar

50 Serial number of the workstation

Make nvarchar

50 Manufacturer of the workstation

Model nvarchar

50 Model number of the workstation.

UDShare nvarchar

255 Y UNC path to the share where user data is stored.

UDDir nvarchar

255 Existing computer name (used to make folder beneath UDShare).

UDProfiles nvarchar

255 Name of user profile being migrated.

SLShare nvarchar

255 Y UNC path to the share where ZTI script creates log files.

TimeZone nvarchar

50 Time zone where workstation will be deployed

AdminPassword nvarchar

50 Password to be assigned to local administrator account on workstation.

DomainAdmin nvarchar

50 Domain-based account name that is a member of the Domain Administrators group.

DomainAdminPasswor nvarch 50 Password for the domain-based account.


d ar

JoinDomain nvarchar

50 Domain name that the workstation will join.

MachineObjectOU nvarchar

255 Active Directory OU where the machine account will be created.

JoinWorkGroup nvarchar

50 Workgroup name that the workstation will join.

FullName nvarchar

50 User name configured on the workstation.

OrgName nvarchar

50 Organization name to be configured on the workstation.

Command0 nvarchar

255 Obsolete field that is no longer used by the Zerotouchinstallation.vbs.

OsdInstallSilent char 1 Indicates if the SMS 2003 OSD Feature Pack image installation wizard should be displayed (1 in this field indicates the wizard will not be displayed).

OsdInstallPackage nvarchar

255 Unique ID of the OS Deployment package that the OS Image Installation CD or RIS should install. This is set by the custom program or script specified in the Operating System Image Installation CD Wizard

OsdInstallProgram nvarchar

255 Name of the OS Deployment Program that the OS Image Installation CD or RIS should install. This is set by the custom program or script specified in the Operating System Image Installation CD Wizard

OsdNewMachineName nvarchar

255 Name to assign to the computer when the new operating system is installed. This variable is used in the new computer and replace computer installation scenarios when running the OS Image Installation CD or from RIS. In a refresh computer scenario, ZTI can rename the machine by including the “ComputerName=%OSDNEWMACHINENAME% line in the default section.

OsdStatePath nvarchar

255 Path where OSD stores user state migration information.

OSInstall char 1 Flag monitored by Zerotouchinstallation.vbs to determine of the script should continue to run. If set to False, Zertotouchinstallation.vbs


Appendix F: ZTI Scenario Process FlowchartsFigure 15, Figure 16, and Figure 17 lists the process flowcharts for the Refresh Computer, New Computer, and Replace Computer scenarios, respectively.

Figure 15. Process flowchart for the Refresh Computer scenario


Figure 16. Process flowchart for the New Computer scenario


Figure 17. Process flowchart for the Replace Computer scenario


Appendix G: Sample User Exit Function Listing 28 illustrates an example of a user exit function written in VBScript.

'//---------------------------------------------------------------------------'//'//'// File: ZTIUserExit.vbs'//'// Function: UserExit()'//'// Input: sType - user exit type (PHASE, SECTION)'// sWhen - when being called (BEFORE, AFTER)'// sDetail - detail for the exist (phase name, section name)'// bSkip - flag to indicate whether to skip normal processing (only possible with BEFORE)'// '// Return: Success - 0'// Failure - 1'//'// Purpose: This is a sample user exit, showing some of the capabilities of a user exit.'//'//---------------------------------------------------------------------------

Function UserExit(sType, sWhen, sDetail, bSkip)

Dim iRetVal

LogInfo sLogFile, "User exit started: " & sType & " " & sWhen & " " & sDetail, LogTypeInfo

If sType = "PHASE" and sDetail = "PREINSTALL" and sWhen = "BEFORE" then

' Check to see if Windows PE is running from a different drive than the first disk partition ' (as identified by OSD). If this is the case, then this is a new machine and we can ' repartition and format the drive.

If Left(objOSD("OSDTARGETDRIVE"), 2) <> Left(wshEnv("SystemDrive"), 2) then

' First run DISKPART

LogInfo sLogFile, "USEREXIT: About to run Diskpart.", LogTypeInfo iRetVal = wshShell.Run("DISKPART.EXE /s """ & sThisScriptDir & "\ZTIDiskPart.txt""", 0, true) If iRetVal <> Success then LogInfo sLogFile, "USEREXIT: ERROR - Diskpart returned a non-zero return code, rc = " & iRetVal, LogTypeError UserExit = iRetVal EXIT FUNCTION End if

' Now run a quick format

LogInfo sLogFile, "USEREXIT: About to run quick format.", LogTypeInfo iRetVal = wshShell.Run("FORMAT C: /FS:NTFS /V:OSDisk /Q /Y", 0, true) If iRetVal <> Success then LogInfo sLogFile, "USEREXIT: ERROR - Quick format returned a non-zero return code, rc = " & iRetVal, LogTypeError UserExit = iRetVal


EXIT FUNCTION End if Else LogInfo sLogFile, "USEREXIT: Windows PE is running from the system drive, must be a refresh.", LogTypeInfo End if Else LogInfo sLogFile, "USEREXIT: No user exit processing is required.", LogTypeInfo End if

UserExit = Success

End Function

Listing 28. User Exit function example in Visual Basic

Figure 18 illustrates a sample ZTIDiskPart.txt file used by ZTIUserExit.vbs to create the partitions. In Listing 28 you can see where the ZTIUserExit.vbs calls DiskPart.exe and passes ZTIDiskPart.txt as a parameter.

select disk 0cleancreate partition primaryassign letter=c:activeexit

Figure 18. ZTIDiskPart.txt parsed by ZTIUserExit.vbs

Both ZTIuserexit.vbs and ZTIDiskPart.txt must be included in the package that you are distributing to the workstation. For more information on updating OSD packages, see Microsoft Systems Management Server 2003 Operating System Deployment Feature Pack Users Guide in Additional Resources earlier in this guide.


Appendix H: Training ResourcesThe following training resources are available to assist you in training your deployment teams.

Using the Solution Accelerator for Business Desktop Deployment Standard Edition (online course)Located at https://www.microsoftelearning.com/Desktopdeployment/.

This course provides students with the new knowledge and skills necessary to plan and implement an efficient and predictable deployment of Office Professional 2003 Edition in a medium- to large-sized environment using Solution Accelerator for Business Desktop Deployment Standard Edition.

Microsoft® Windows® Scripting Self-Paced Learning Guide by Microsoft PressThis book describes how to write system administration scripts—straight from Microsoft scripting experts. This practical learning guide teaches how to use scripting techniques to gain control over your Microsoft Windows environment—all at your own pace. Build practical skills on everything from writing your first script in Microsoft Visual Basic® Scripting Edition (VBScript) to working with Windows Scripting Host (WSH), Windows Management Instrumentation (WMI), and Active Directory® Services Interface (ADSI), and from creating logon scripts to automating the management of systems, user accounts, files, printers, the registry, network services, directory services, security features, group policy, and more. The companion CD features the complete eBook, plus more than 200 sample scripts and a host of timesaving scripting tools.

Microsoft TechNet Windows XP Service Pack 2 Resources for IT ProfessionalsLocated at http://www.microsoft.com/technet/winxpsp2.mspx

Windows XP Service Pack 2 contains major security improvements designed to provide better protection against hackers, viruses, and worms. Windows XP Service Pack 2 also improves the manageability of the security features in Windows XP and provides more and better information to help users make decisions that may potentially affect their security and privacy.

The Windows XP Service Pack 2 site on Microsoft TechNet is the best resource for accessing the most up-to-date technical information regarding this service pack.

Microsoft Windows Preinstallation Reference (Deploy.chm)Located in the Deploy.cab file in the \Support\Tools folder on the Windows XP CD-ROM.

This help file, titled the “Microsoft Windows Preinstallation Reference”, describes how to configure Windows during an unattended installation or deployment of Windows XP. Each setting in the Unattend.txt file (used to configure which Windows components are installed) and the Sysprep.inf file (used to automate Windows XP mini-setup) is described in this file.

Microsoft TechNet Script CenterLocated at http://www.microsoft.com/technet/scriptcenter/default.mspx


The TechNet Script Center provides one-stop shopping for system administrators wanting to manage their Windows computers using Microsoft's scripting technologies.

Microsoft Windows Preinstallation Environment User's Guide (Winpe.chm)Located in the “DOCS” folder of the Windows PE 1.5 CD

This help file, titled the “Microsoft Windows Preinstallation Environment User's Guide,” provides information to corporate administrators about using Windows PE to deploy Microsoft Windows to computers within your organization. It describes the features of Windows PE and explains how to configure and customize Windows PE for your specific requirements.

Microsoft TechNetLocated at http://www.microsoft.com/technet/ Subscriptions

With a TechNet subscription, the latest Microsoft technical information is delivered monthly on CD-ROM or DVD-ROM discs, avoiding the need to download the content from the Microsoft TechNet web site. A fully-searchable knowledge base is also included, to help improve the productivity of IT Professionals.

Microsoft Developer Network (MSDN)Located at http://msdn.microsoft.com/subscriptions/

The Microsoft Developer Network (MSDN) subscription program enables IT Professionals to receive Microsoft server, desktop, productivity, and developer tools software packages. These can be used in lab environments (described below) to improve productivity and reduce the cost of maintaining a lab.


Appendix I: Resolving Common ZTI Deployment ProblemsThe following describes how to resolve some common ZTI deployment problems.

Troubleshooting General Deployment ProblemsTable 52 lists some symptoms that can cause the ZTI deployment process to fail, the possible problems, and some suggestion methods for resolving the problem.

Table 52. SMS Related Deployment Symptoms, Possible Problems, and Possible Solutions

Symptom Possible Problem Resolution

Workstations are not receiving the OSD package advertisements

Workstations are not included in the appropriate SMS collection.

Verify that the workstations are in the SMS collection used during the distribution of your OSD package.

ZTI scripts do not run properly

Workstations may not meet the hardware and software requirements.

Review workstation hardware and software requirements in Verifying Correct Workstation Software Versions and Verifying Adequate Workstation Resources earlier in this guide.

Appropriate permissions may not be set on MigData, Logs, or distribution point shares.

Log on as the appropriate account and attempt to access files in the shares.

Updated packages and programs are not appearing on distribution points

Scheduled distribution of updates to packages and programs may be occurring longer than you required.

Manually updated the distribution points by using SMS 2003 Administrator.

Scanstate.exe returns an error code 32 on a workstation running Windows NT SP6a

Task Scheduler service is running that keeps the file SchedLog.txt in use.

Modify the Sysfiles.inf to exclude SchedLog.txt

The following are some SMS related troubleshooting resources:

Scenarios and Procedures for Systems Management Server 2003: Planning and Deployment

http://www.microsoft.com/downloads/details.aspx?FamilyID=E0644BB4-2336-4254-8A18-9BC180713F7E&displaylang=en

Active Directory Schema Modification and Publishing for Systems Management Server 2003

http://www.microsoft.com/downloads/details.aspx?FamilyId=D1DE764C-8E26-455F-BEE5-34FB1CA9F2C4&displaylang=en

Troubleshooting PXE Boot Related Issues in RISIn brief, the PXE protocol operates as follows: The client initiates the protocol by broadcasting a DHCP Discover packet containing an extension that identifies the request as coming from a


client that implements the PXE protocol. Assuming that a boot server implementing this extended protocol is available, the boot server sends an offer containing the IP address of the server that will service the client. The client uses TFTP to download the executable file from the boot server. Finally, the client initiates execution of the downloaded image.

The initial phase of this protocol piggybacks on a subset of the DHCP messages to enable the client to discover a boot server (that is, a server that delivers executable files for new computer setup). The client may use the opportunity to obtain an IP address (which is the expected behavior), but is not required to do so.

The second phase of this protocol takes place between the client and a boot server, and uses the DHCP message format simply as a convenient format for communication. This second phase of the protocol is otherwise unrelated to the standard DHCP services. The next few pages outline the step-by-step process during PXE client initialization.

For more information on troubleshooting PXE boot-related issues in RIS, see Knowledge Base Article 244036: Description of PXE Interaction Among PXE Client, DHCP, and RIS Server at http://support.microsoft.com/kb/244036/EN-US/

Disabling Windows PE Logging on the RIS Server The first procedure you should do is to make sure you have disabled logging to setupapi.log following the instructions in the “Disabling Windows PE Logging on the RIS Server” section earlier in this document.

Ensuring the Proper DHCP ConfigurationDepending on the router models in use, the specific router configuration of DHCP broadcast forwarding might be supported to either a subnet (or router interface), or to a specific host. If your DHCP servers and RIS servers are separate computers, ensure that the routers forwarding DHCP broadcasts are designed so that both the DHCP and RIS servers receive the client broadcasts, otherwise the client does not receive a reply to its remote boot request.

Is there a router between the client and the remote installation server that is not allowing the DHCP-based requests/responses through? When the RIS client and the RIS server are on separate subnets the router between the two systems must be configured to forward DHCP packets to the RIS server. This is because RIS clients discover a RIS server by using a DHCP broadcast message. Without DHCP forwarding set up on a router, the clients' DHCP broadcasts will never reach the RIS server. This DHCP forwarding process is sometimes referred to as DHCP Proxy or IP Helper Address in router configuration manuals. Please refer to your router instructions for setting up DHCP forwarding on your specific router.

Improving PXE IP Address Assignment Response TimeIf it is taking a long time (15-20 seconds) for your PXE client to get an IP address, here are some things you might want to check:

Is the NIC on your client and the switch/router set to the same speed (Auto, duplex, full etc)

Do you have the IP address for your RIS server in the IP Helper file on the router you’re connecting through? If the list is long, can you move the address for the RIS server near the top?

Setupapi.log is disabled per section Disable WinPE Logging on the RIS Server earlier in this document.


Troubleshooting Failed New Computer Scenario DeploymentFailure to Copy Log Files to Shared FoldersDuring the deployment of a New Computer or Replace Computer scenario, you may see a warning message similar to the following, even though the share specified does exist:

Warning - Unable to copy local logfile (C:\MININT\SMSOSD\OSDLOGS\ZeroTouchInstallation.log) because \\SERVERNAMEservername\Logs does not exist.

This message can occurs because OSD may not have the appropriate credentials to access the \\servername\Logs folder, when the \\servername\Logs folder resides on a server other than the distribution point. For more information on providing the appropriate credential for the different deployment phases, see Configuring Access for Deployment Phases earlier in this guide.

Identifying Error Codes Returned by Zerotouchinstallation.vbsTable 53 lists the error codes returned by Zerotouchinstallation.vbs and a description of each error code. These return codes are recorded in the OSD log file (OSDAgent.log) which is stored in one of the following locations:

If the %TEMP% environment variable is set for the LocalSystem or default user profile, the OSD log file is stored in the %WINDIR%\TEMP\SMSOSD folder.

Otherwise, the OSD log file is stored in the %WINDIR%\SMSOSD folder.

Table 53. Zerotouchinstallation.vbs Error Codes and Their Description

Error Code

This Error Code Indicates That…

5000 Windows Scripting Host (WSH) is not installed.

5001 The version of WSH is prior to version 5.6.

5002 The script was unable to create WScript.Shell object. This infers that WSH is operating improperly and needs to be reinstalled.

5003 The script was unable to create WScript.Network object. This infers that WSH is operating improperly and needs to be reinstalled.

5004 The script was unable to create Scripting.FileSystemObject object. This infers that WSH is operating improperly and needs to be reinstalled.

5005 The script was unable to initialize the WshShell.Environment. This infers that WSH is operating improperly and needs to be reinstalled.

5005 No named parameters were passed to the script.

Figure 19 is an excerpt from an OSD log file that illustrates how to find the error code in OSDAgent.log. In this excerpt, the error code reported is 5001

.

.

.

<![LOG[The operating system installation failed. Please contact your system administrator for assistance.

The action "Zero Touch Installation - Validation" failed with exit code 5001]LOG]!><time="15:43:51.576+000"

date="09-19-2004" component="OSDAgent" context="" type="3" thread="856" file="actionengine.cpp:1567">

.


.

.

Figure 19. Excerpt from the OSDAgent.log file that contains error code 5001


Appendix J: Deploying Windows XP Using Windows Product ActivationYou can use the Windows Product Activation (WPA) automation method in Windows XP to support fully-automated deployments. You can use an answer file and the built-in Windows Management Instrumentation (WMI) activation feature to automate the WPA during setup. If you are however using volume license media with volume license keys this guidance is not necessary.

For more information on using WPA and WMI to automate WPA during setup, please see Deploying Windows XP Using Windows Product Activation at http://www.microsoft.com/technet/prodtechnol/winxppro/deploy/wpadepl.mspx.


Appendix K: Sample Stored Procedure CallsListing 29 lists the BDDAdminDB-IdentifyComputer.sql script that is called by the [DB_IdentifyComputer] section in the excerpt from the sample Customsettings.ini file in Listing 30.

In this example, BDDAdminDB-IdentifyComputer.sql :

Creates a table, called MachineNameSequence, which contains the columns listed in Table 54.

Table 54. Columns in the MachineNameSequence Table and a Description of the Colums

Column Description

Prefix Prefix to include as the leading portion of the generated computer name (for example WRKSTA- in the generated name WRKSTA-00021).

Sequence Last number used to generate the sequence portion of the generated computer name (for example 00021 in the generated name WRKSTA-00021

Creates a stored procedure, called IdentifyComputer, which creates a unique computer name, and then updates the AdminDB database with the new computer name, the MAC address, the make of the workstation, and the model of the workstation.

Note In the new machine scenario, you may want to include additional logic in the IdentifyComputer"stored procedure to automatically populate the OSDINSTALLPACKAGE and OSDINSTALLPROGRAM columns (for example, based on the make and model passed). The current version of the script does not have this feature implemented.

use [BDDAdminDB]GO

if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[IdentifyComputer]')

and OBJECTPROPERTY(id, N'IsProcedure') = 1)drop procedure [dbo].[IdentifyComputer]GO

if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[MachineNameSequence]')

and OBJECTPROPERTY(id, N'IsUserTable') = 1)drop table [dbo].[MachineNameSequence]GO

CREATE TABLE [dbo].[MachineNameSequence] ([Prefix] [varchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,[Sequence] [int] NOT NULL

) ON [PRIMARY]GO

INSERT INTO [dbo].[MachineNameSequence] (Prefix, Sequence) VALUES ('PC', 0)GO


SET QUOTED_IDENTIFIER ON GOSET ANSI_NULLS ON GO

CREATE PROCEDURE [dbo].[IdentifyComputer]@MacAddress CHAR(17),@Make VARCHAR(50),@Model VARCHAR(50)AS

DECLARE @Cnt INT, @Prefix VARCHAR(50), @Sequence INT, @NewName VARCHAR(50)

SET NOCOUNT ON

/* See if there is an existing record for this machine */

SELECT @Cnt=COUNT(*) FROM BDDAdminCoreWHERE MacAddress = @MacAddress

/* No record? Add one. */

IF @Cnt = 0BEGIN

/* Create a new machine name */

BEGIN TRAN

SELECT @Prefix=Prefix, @Sequence=Sequence FROM MachineNameSequence SET @Sequence = @Sequence + 1 UPDATE MachineNameSequence SET Sequence = @Sequence SET @NewName = @Prefix + Right('00000'+LTrim(Str(@Sequence)),5)

/* Insert the new record */

INSERT INTO BDDAdminCore (MacAddress, Make, Model, ComputerName, OSDNewMachineName,

OSDInstallSilent, OSInstall) VALUES (@MacAddress, @Make, @Model, @NewName, @NewName, '1', 'Y')

COMMIT TRAN

END

/* Return the record as the result set */

SELECT * FROM BDDAdminCoreWHERE MacAddress = @MacAddress

GOSET QUOTED_IDENTIFIER OFF


GOSET ANSI_NULLS ON GO

Listing 29. BDDAdminDB-IdentifyComputer.sql script to create table and IdentifyComputer stored procedure

.

.

.

[IdentifyComputer]

SQLDefault=DB_IdentifyComputer

[DB_IdentifyComputer]

SQLServer=SERVER1

Database=BDDAdminDB

StoredProcedure=IdentifyComputer

Parameters=MacAddress, Make, Model

Listing 30. Excerpt from the Customsettings.ini file that calls the IdentifyComputer stored procedure