You are on page 1of 111

Business Desktop Deployment

SOLUTION ACCELERATOR
ENTERPRISE EDITION

Zero Touch Installation Deployment Feature Team Guide


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
This 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 Team


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

Communication
Key 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 Models


For additional guidance on team models, see MSF Team Model in the Additional Resources section
of this guide.
Zero Touch Installation Deployment Feature Team Guide 5

Introduction
This 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.

Background
The 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.
6 Solution Accelerator for Business Desktop Deployment

Prerequisites
Installing, 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


Appropriate
The 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.
Zero Touch Installation Deployment Feature Team Guide 7

ZTI Deployment Process Overview


Before 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 Milestones


As 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.
8 Solution Accelerator for Business Desktop Deployment

Table 1. High-Level Project Milestones and Their Descriptions


High-Level Milestone Description
Planning
Appropriate deployment scenario The appropriate combination of scenarios (new
selected 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 Any training required by the Operations and
teams trained Deployment feature teams occurs to ensure that both
teams are ready by the time deployment occurs.
Consensus for deployment plan All stakeholders in the Solution Accelerator for BDD
obtained 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 Each phase of the SMS 2003 OSD Feature Pack
programs configured 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 The deployment process is validated in test labs.
completed 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
Zero Touch Installation Deployment Feature Team Guide 9

SMS 2003 OSD Feature Pack Deployment of images to workstations is initiated.


Deployment Wizard run
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 The current list of migrated workstations, workstations
communicated that were unable to migrate, and current processes for
resolving deployment issues is communicated from the
Deployment feature team to the Operations feature
team.

Envisioning
The 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.

Planning
Figure 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.
10 Solution Accelerator for Business Desktop Deployment

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
Zero Touch Installation Deployment Feature Team Guide 11

Roles and Responsibilities


All 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 Business requirements analysis; communications plan
management
Program Master project plan and master project schedule; budget
management
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 Operations requirements; pilot and deployment plan/schedule; network
management discovery; application and hardware inventory; interfacing with operations
and security feature teams

Milestones and Deliverables in the Planning Phase


Table 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 Deliverable Description Owner
Milestone
Appropriate deployment The appropriate combination of scenarios (new Development
scenario selected computer installation, in-place upgrade, or side-
by-side upgrade) is identified.
Required infrastructure Perquisite technologies and infrastructure exists Development
exists for performing the deployment.
Monitoring plan The list of servers, services, and system Development
complete resources to be monitored is created. The
frequency of monitoring is also decided.
Teams trained Any training required by the Operations and Program
Deployment feature teams occurs to ensure management
that both teams are ready by the time
deployment occurs.
Consensus for All stakeholders in the Solution Accelerator for Product Management
deployment plan BDD project provide consensus for acting on the
obtained deployment plan and future project milestones.
12 Solution Accelerator for Business Desktop Deployment

Selecting the Appropriate Deployment Scenario


As 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 Scenario


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


Zero Touch Installation Deployment Feature Team Guide 13

Figure 3. Refresh Computer deployment process

New Computer Scenario


In 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.
14 Solution Accelerator for Business Desktop Deployment

Figure 4. New Computer deployment process

Replace Computer Scenario


In 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.
Zero Touch Installation Deployment Feature Team Guide 15

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 Information


During 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.
16 Solution Accelerator for Business Desktop Deployment

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.
Zero Touch Installation Deployment Feature Team Guide 17

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 Information


The 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 Exists


Before 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 Infrastructure


Solution 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.
18 Solution Accelerator for Business Desktop Deployment

Identifying the Storage Requirements for Distribution Points


When 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 Points


If 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 Data


Determine 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 Data


For 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
Zero Touch Installation Deployment Feature Team Guide 19

(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 Data


After 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 Logs


The 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 Logs


For 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 Logs


After 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.
20 Solution Accelerator for Business Desktop Deployment

Using Remote Installation Services


You 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 Configuration


Before 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 Versions


The 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 Resources


Prior 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)
Zero Touch Installation Deployment Feature Team Guide 21

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


Because 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 Rules


The 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.
22 Solution Accelerator for Business Desktop Deployment

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 Used


The 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.
Zero Touch Installation Deployment Feature Team Guide 23

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 Settings


You 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, Default


CustomKeysUserData=UDShare,UDDir,UDProfiles,SLShare,OSInstall,JoinDomain
CustomKeysSysprep=ComputerName,TimeZone,JoinDomain,MachineObjectOU
OSDVariableKeys=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.
24 Solution Accelerator for Business Desktop Deployment

Prioritizing the ZTI Processing Rules


You 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 Settings


Listing 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, Default


CustomKeysUserData=UDShare,UDDir,UDProfiles,SLShare,OSInstall,JoinDomain
CustomKeysSysprep=ComputerName,TimeZone,JoinDomain,MachineObjectOU
OSDVariableKeys=OSDINSTALLSILENT,OSDINSTALLPACKAGE,OSDINSTALLPROGRAM,OSDNEWMACHINENAME
.
.
.
Listing 2. Example in Which Client-Based Settings Take Precedence

Prioritizing Group-Based Configuration Settings


Listing 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.
Zero Touch Installation Deployment Feature Team Guide 25

Priority= DefaultGateway, SQL, Default


CustomKeysUserData=UDShare,UDDir,UDProfiles,SLShare,OSInstall,JoinDomain
CustomKeysSysprep=ComputerName,TimeZone,JoinDomain,MachineObjectOU
OSDVariableKeys=OSDINSTALLSILENT,OSDINSTALLPACKAGE,OSDINSTALLPROGRAM,OSDNEWMACHINENAME
.
.
.
Listing 3. Example in Which Group-Based Settings Take Precedence

Prioritizing Default Configuration Settings


The 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
26 Solution Accelerator for Business Desktop Deployment

[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 Rules


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 appropriate workstation groupings
• Identifying the group-based configuration settings

Identifying the Appropriate Workstation Groupings


You 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], According to hardware Specific hardware attributes (such as HAL
[AssetTag], configuration types) to select the appropriate images for
[SerialNumber], deployment
[UUID]
Existing operating According to existing Appropriate images to deploy and potential
system software configuration settings to migrate
[Default] In absence of other Configuration settings in the event the
groupings 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
Zero Touch Installation Deployment Feature Team Guide 27

environments, you might expect a one-to-one mapping between default gateway and a
corresponding section.
[DefaultGateway]
172.16.0.3=NYC
172.16.1.3=NYC
172.16.2.3=NYC
172.16.111.3=DALLAS
172.16.112.3=DALLAS
172.16.116.3=WASHINGTON
172.16.117.3=WASHINGTON

[NYC]
UDShare=\\NYC-AM-FIL-01\MigData
SLShare=\\NYC-AM-FIL-01\Logs
Packages1=NYC00010-Install
Packages2=NYC00011-Install
Administrator1=WOODGROVEBANK\NYC Help Desk Staff

[DALLAS]
UDShare=\\DAL-AM-FIL-01\MigData
SLShare=\\DAL-AM-FIL-01\Logs
Administrator1=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 Settings


After 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.
28 Solution Accelerator for Business Desktop Deployment

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 Rules


After 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 Rules


Most 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.
Zero Touch Installation Deployment Feature Team Guide 29

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-1
OSDINSTALLPACKAGE=DAL00342
OSDINSTALLPROGRAM=CustomXP

[00:03:FF:FE:FF:FF]
OSDNEWMACHINENAME=BVMXP
OSDINSTALLPACKAGE=NYC00002
OSDINSTALLPROGRAM=SpecialXP
Listing 7. How Woodgrove Identified Workstations
30 Solution Accelerator for Business Desktop Deployment

Identifying the Workstation-Based Configuration Settings


After 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).
Zero Touch Installation Deployment Feature Team Guide 31

• OSDINSTALLPROGRAM is the name of the workstation-specific SMS OSD


program to run on the workstation (SpecialXP).

Determining Where To Store Workstation-Based Configuration


Settings
You 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 Requires connectivity to the SQL
of workstation-based configuration Server machine managing the ZTI
settings AdminDB database
Customsettings.ini Can be used for workstations that Because the Customsettings.ini file
are unable to connect to the ZTI is stored in the SMS OSD Feature
AdminDB database 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-1
OSDINSTALLPACKAGE=DAL00342
OSDINSTALLPROGRAM=CustomXP
32 Solution Accelerator for Business Desktop Deployment

[00:03:FF:FE:FF:FF]
OSDNEWMACHINENAME=BVMXP
OSDINSTALLPACKAGE=NYC00002
OSDINSTALLPROGRAM=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=NYC
172.16.111.3=DALLAS
172.16.116.3=WASHINGTON

.
.
.

[NYC]
SQLDefault=DB_NYC

[DALLAS]
SQLDefault=DB_DAL

[WASHINGTON]
SQLDefaul=DB_WSG

[DB_NYC]
SQLServer=NYC-AM-SMS-01
Database=BDDAdminDB
Table=BDDAdminCore
Parameters=MacAddress

[DB_DAL]
SQLServer=DAL-AM-FIL-01
Database=BDDAdminDB
Table=BDDAdminCore
Parameters=MacAddress

[DB_WSG]
SQLServer=WSG-AM-DC-01
Database=BDDAdminDB
Table=BDDAdminCore
Parameters=MacAddress
Listing 9. Workstation Configuration Settings in the ZTI AdminDB Database
Zero Touch Installation Deployment Feature Team Guide 33

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 Functions


You 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, Default
CustomKeysUserData=UDShare,UDDir,UDProfiles,SLShare,OSInstall,JoinDomain
CustomKeysSysprep=ComputerName,TimeZone,JoinDomain,MachineObjectOU
OSDVariableKeys=OSDINSTALLSILENT,OSDINSTALLPACKAGE,OSDINSTALLPROGRAM,OSDNEWMACHINENAME
ScanStateArgs=/i:miguser.inf /i:migapp.inf /i:migsys.inf /i:sysfiles.inf /i:updateuser.inf /v:7 /x /s /f /o
/c
LoadStateArgs=/v:7 /c
UserExit=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 Procedures


In 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
34 Solution Accelerator for Business Desktop Deployment

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 Members


Before 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.
Zero Touch Installation Deployment Feature Team Guide 35

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


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

Developing
Figure 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.
36 Solution Accelerator for Business Desktop Deployment

Figure 7. Activities during the Developing Phase


Zero Touch Installation Deployment Feature Team Guide 37

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 Responsibilities


In 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 Phase


Table 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 Deliverable Description Owner
Milestone
RIS server prepared The existing servers running RIS are Development
configured and ready to deploy Windows PE
images to workstations.
Solution Accelerator for All the Solution Accelerator for BDD Development
BDD installed components are installed and ready for
operating system image deployment.
Appropriate resource Appropriate SMS client access accounts are Development
38 Solution Accelerator for Business Desktop Deployment

access configured created, and the corresponding shared


folder permissions are assigned to the
accounts.
ZTI operating system Appropriate ZTI operating system images Development
image configured are configured for all SMS OSD Feature Pack
phases (Validation, State Capture, Preinstall,
Postinstall, and State Restore).
ZTI operating system CD used for deployment of the operating Development
image installation CD system image to workstations is created.
created The ZTI script and corresponding
Customsettings.ini file are included in the
image.
ZTI processing rules The processing rules, configured in Development
configured Customsettings.ini, are created. When
appropriate, additional settings are stored in
a SQL Server database.
Windows PE CDs and Images and CDs used to deploy Windows PE Development
images prepared on workstations—either through RIS or
directly through CDs—are prepared.

Preparing the RIS Server


When 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.
Zero Touch Installation Deployment Feature Team Guide 39

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 Directory
During 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 =Flat
Version="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 =WinPE
Version="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 Server


By 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.
40 Solution Accelerator for Business Desktop Deployment

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 Image


To 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-only


To 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 Wizard


Although 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.
Zero Touch Installation Deployment Feature Team Guide 41

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 Box


To 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.osc
You 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:
42 Solution Accelerator for Business Desktop Deployment

<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
5. Save the file, and then close Notepad.

Customizing Login.osc
To 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:


Zero Touch Installation Deployment Feature Team Guide 43

<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:
Username@Company.com).
<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.osc


To 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 BDD


Before 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.
44 Solution Accelerator for Business Desktop Deployment

Installing the SMS 2003 OSD Feature Pack


You 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 Files


Install 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 File


To 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 Click Next.
Enterprise Setup Wizard
License Agreement Review the license agreement, click I agree, and then click Next.
BDD Enterprise Review the information and then click Next.
Information
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:
Zero Touch Installation Deployment Feature Team Guide 45

• Authenticated Users: Read


• Administrators: Full Control
5. Share the folder selected in step 4 as ZTI with the following shared folder permissions:
• Authenticated Users: Read
• Administrators: Full Control
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 File


In 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.6


You 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.
46 Solution Accelerator for Business Desktop Deployment

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):
• Authenticated Users: Read
• Administrators: Full Control
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:
• Authenticated Users: Read
• Administrators: Full Control
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 Console


When 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 Files


To 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 Database


Before 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.
Zero Touch Installation Deployment Feature Team Guide 47

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 Database


To 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.
48 Solution Accelerator for Business Desktop Deployment

<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 Access


During 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 Accounts


The 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 Used by legacy clients (such as Windows NT 4.0 Workstation) to
account install the legacy client software.
SMS advanced client Used by OSD on Windows 2000 Workstation and later operating
network access account systems to access the distribution point that contains the OS
package.
SMS legacy client Used by OSD on operating systems prior to Windows 2000
software installation Workstation to access the distribution point that contains the OS
account 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.
Zero Touch Installation Deployment Feature Team Guide 49

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.
50 Solution Accelerator for Business Desktop Deployment

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.
Zero Touch Installation Deployment Feature Team Guide 51

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 Folders


After 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
52 Solution Accelerator for Business Desktop Deployment

Configuring Shared Folder Permissions


After 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 Phases


The 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
Zero Touch Installation Deployment Feature Team Guide 53

Phase Phase Description Credentials Available


Validation Performs validation checks to make sure that the Any credentials
operating system installation can proceed; specifically
blocks installation on server operating systems
State Capture Gathers information from the configuration file, Any credentials
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
Package When Windows PE is used to prepare the workstation Credentials in
Selection for installation, OSD uses the information in the Ripinfo.ini that provide
Ripinfo.ini file to locate and run the command in the access to the
[UserCommand] section (Zerotouchinstallation.vbs). distribution point
OSD ignores the [ImageInfo] section and simply
Credentials in
passes control to Zerotouchinstallation.vbs
Ripinfo.ini that provide
When you initiate the installation of Windows PE from access to the shared
a CD, the CD-based method ignores the folder specified in the
[UserCommand] section and uses the information in [UserCommand]
the [ImageInfo] section. The CD-based method is not section
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),
Preinstall Confirms that the necessary information has been Any credentials
gathered (or in the case of the New Computer or
Replace Computer scenario, gathers the information)
Postinstall Updates the Sysprep.inf file with information gathered Any credentials
in the previous custom actions
State Restore Invokes USMT Loadstate to restore the user state that Any credentials
was previously backed up

You can divide the authentication requirements into authentication required for:
• The Package Selection phase.
• All other phases.

Authenticating Access During the Package Selection Phase


During 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
54 Solution Accelerator for Business Desktop Deployment

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 Phases


During 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 Credentials


You 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
Zero Touch Installation Deployment Feature Team Guide 55

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 Image


You 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 Performs validation checks to make sure that the
—Validation operating system installation can proceed; specifically
blocks installation on server operating systems
State Zero Touch Installation Gathers information from the configuration file,
Capture —State Capture 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 Confirms that the necessary information has been
—Preinstall gathered (or in the “bare metal” case, gathers it)
Postinstall Zero Touch Installation Updates the Sysprep.inf file with information gathered in
56 Solution Accelerator for Business Desktop Deployment

—Postinstall the previous custom actions


State Zero Touch Installation Invokes USMT Loadstate to restore the user state that was
Restore —State Restore previously backed up

Configuring the Validation Phase Actions


To 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 Zerotouchinstallation.vbs /phase:Validation
line
Files \\servername\ZTI\Customsettings.ini
\\servername\ZTI\Dbnmpntw.dll
\\servername\ZTI\Zerotouchinstallation.vbs
\\servername\ZTI\Sqloledb.rll

Configuring the State Capture Phase Actions


To configure the State Capture 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 State Capture, and then click Add.
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 25, where servername is
the name of the server hosting the shared folder.
Table 25. Configuration Information for the State Capture Phase Actions
Zero Touch Installation Deployment Feature Team Guide 57

Field Value
Name Zero Touch Installation—State Capture
Command Zerotouchinstallation.vbs/phase:StateCapture
line
Files \\servername\ZTI\Customsettings.ini
\\servername\ZTI\Dbnmpntw.dll
\\servername\ZTI\Zerotouchinstallation.vbs
\\servername\ZTI\Sqloledb.rll
\\servername\ZTI\Updateuser.inf
\\servername\USMT\*.*

Specifying User Profiles to Migrate


The 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\Userna Username profile in Domain (where Username is the name of the user and
me 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.
58 Solution Accelerator for Business Desktop Deployment

Specifying Additional File Extensions to Migrate


By 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 Membership


During 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, Default
CustomKeysUserData=UDShare,UDDir,UDProfiles,SLShare,OSInstall,JoinDomain
CustomKeysSysprep=ComputerName,TimeZone,JoinDomain,MachineObjectOU
OSDVariableKeys=OSDINSTALLSILENT,OSDINSTALLPACKAGE,OSDINSTALLPROGRAM,OSDNEWMACHINENAME
ScanStateArgs=/i:miguser.inf /i:migapp.inf /i:migsys.inf /i:sysfiles.inf /i:updateuser.inf /v:7 /x /s /f /o
/c
LoadStateArgs=/v:7 /c
CaptureGroups=NO
UserExit=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 Actions


To configure the Preinstall 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 Preinstall, and then click Add.
5. In the list of action types, select Custom, and then click OK.
Zero Touch Installation Deployment Feature Team Guide 59

6. Complete the custom actions by using the information listed in Table 27, where servername is
the name of the server hosting the shared folder.
Table 27. Configuration Information for the Preinstall Phase Actions
Field Value
Name Zero Touch Installation—Preinstall
Command Zerotouchinstallation.vbs/phase:Preinstall
line
Files \\servername\ZTI\Customsettings.ini
\\servername\ZTI\Dbnmpntw.dll
\\servername\ZTI\Zerotouchinstallation.vbs
\\servername\ZTI\Sqloledb.rll

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 Actions


To configure the Postinstall 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 Postinstall, and then click Add.
5. In the list of action types, select Custom, and then click OK.
6. Complete the custom actions by using the information listed in Table 28, where servername is
the name of the server hosting the shared folder.
Table 28. Configuration Information for the Postinstall Phase Actions
Field Value
Name Zero Touch Installation—Postinstall
Command Zerotouchinstallation.vbs/phase:Postinstall
line
Files \\servername\ZTI\Capicom.dll
\\servername\ZTI\Customsettings.ini
\\servername\ZTI\Dbnmpntw.dll
\\servername\ZTI\Zerotouchinstallation.vbs
\\servername\ZTI\Sqloledb.rll

Configuring the State Restore Phase Actions


To configure the State Restore phase actions, perform the following steps:
60 Solution Accelerator for Business Desktop Deployment

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 State Restore, and then click Add.
5. In the list of action types, select Custom, and then click OK.
6. Complete the custom actions by using the information listed in Table 29, where servername is
the name of the server hosting the shared folder.
Table 29. Configuration Information for the State Restore Phase Actions
Field Value
Name Zero Touch Installation—State Restore
Command Zerotouchinstallation.vbs/phase:StateRestore
line
Files \\servername\ZTI\Capicom.dll
\\servername\ZTI\Customsettings.ini
\\servername\ZTI\Dbnmpntw.dll
\\servername\ZTI\Zerotouchinstallation.vbs
\\servername\ZTI\Sqloledb.rll
\\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 System
If 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.
Zero Touch Installation Deployment Feature Team Guide 61

Restoring the Administrators and Power Users Group Membership


Earlier 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, Default
CustomKeysUserData=UDShare,UDDir,UDProfiles,SLShare,OSInstall,JoinDomain
CustomKeysSysprep=ComputerName,TimeZone,JoinDomain,MachineObjectOU
OSDVariableKeys=OSDINSTALLSILENT,OSDINSTALLPACKAGE,OSDINSTALLPROGRAM,OSDNEWMACHINENAME
ScanStateArgs=/i:miguser.inf /i:migapp.inf /i:migsys.inf /i:sysfiles.inf /i:updateuser.inf /v:7 /x /s /f /o
/c
LoadStateArgs=/v:7 /c
CaptureGroups=NO
UserExit=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 CD


To 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 Click Next.
Operating System Image
Installation CD Wizard
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 Ensure the central site server is specified in the list of servers, click
distribution points Select All, and then click Next.
Automatically select In the File name text box, type
Operating System \\servername\ZTI\Zerotouchinstallation.vbs (where
Package servername is the name of the server hosting the shared folder).
62 Solution Accelerator for Business Desktop Deployment

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 Rules


The 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
Zero Touch Installation Deployment Feature Team Guide 63

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


You 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 Schema


The 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.
64 Solution Accelerator for Business Desktop Deployment

Modifying the AdminDB Console Components


You 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 Use SQL Server Enterprise Manager to add,
database delete, or modify columns.
BDDAdminBackUp table BDDAdminDB Use SQL Server Enterprise Manager to add,
database delete, or modify columns.
BDDAdminBackUpUser BDDAdminDB Use SQL Query Analyzer to modify the SELECT
stored procedure database statement marked with the comment "-- Back
up the entire BDDAdminCore table into
BDDAdminBackUp”.
BDDAdminRollBackUser BDDAdminDB Use SQL Server Enterprise Manager to modify
stored procedure database the SELECT statement marked with the
comment "-- roll back the last back-up”.
ColumnsHeaders Bddadmindb.config Use an XML editor to modify the column listed
file 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.
<!-- Column headers --> <!-- Graphic section In the <!-- Column headers --> section, modify
--> in the the column headers listed.
BddAdmindb.hta file

<!-- Column values --> <!-- Graphic section In the <!-- Column values --> section, modify
--> in the the column description and data type listed.
BDDadminDB.hta file
Update AdminDB Modify the schema documentation to reflect
schema documentation the actual schema.
Update AdminDB .csv Modify the .csv documentation to reflect the
documentation actual schema.
Bddadmindb-Create.sql \database folder Use SQL Query Analyzer to modify the script
to create the tables based on the modified
schema.
Zero Touch Installation Deployment Feature Team Guide 65

Modifying AdminDB Console Validation Functions


When 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 Rules


Depending 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)
66 Solution Accelerator for Business Desktop Deployment

Modifying the AdminDB Database


You 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
Zero Touch Installation Deployment Feature Team Guide 67

Update action on the


database.
Admin-B performs an Backup copy of the database, including updates made by Admin-A, is
Update action on the made for Admin-B
database.
Admin-A performs a Database is restored to the state prior to Admin-A performing the
Rollback action on the update, which results in the loss of the update performed by Admin-
database. 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


Template
To 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


Image
Each 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).
68 Solution Accelerator for Business Desktop Deployment

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 Images


In 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


Adapters
Ensure 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 PE


You 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.
Zero Touch Installation Deployment Feature Team Guide 69

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 Image


After 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.ini
To 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.
3. Save the file, and then close Notepad.
4. Copy the Winbom.ini file to the I386\System32 folder in the Windows PE image you created.

Customizing the Windows PE Splash Screen


To 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 Pack


To 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
70 Solution Accelerator for Business Desktop Deployment

Table 34. Information for Completing the Update Windows PE Wizard


On This Page Do This
Welcome to the Click Next.
Update Windows PE
Wizard
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 Click Finish.
Complete

4. Close the SMS Administrator Console.

Transferring Windows PE CD Images to the RIS Servers


After 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


Adapters
You 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 • RISImagePath\I386
files
• 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.)
Zero Touch Installation Deployment Feature Team Guide 71

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

Stabilizing
Figure 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 Responsibilities


In 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
72 Solution Accelerator for Business Desktop Deployment

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 Phase


Table 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 Deliverable Description Owner
Milestone
Lab tests and pilot All deployment scenarios—New Test
deployments performed Computer, Refresh Computer, and
Replace Computer—are tested in a lab
environment and in pilot deployments.
Deployment teams Appropriate documentation, Program
prepared troubleshooting processes, diagnostic Management
tools, and common deployment issues
are transferred from the design and test
teams to the deployment team.

Performing Lab Tests and Pilot Deployments


Before 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.
Zero Touch Installation Deployment Feature Team Guide 73

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 Teams


After 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.
74 Solution Accelerator for Business Desktop Deployment

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.

Deploying
With 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.
Zero Touch Installation Deployment Feature Team Guide 75

Figure 14. Activities during the Deploying phase

Roles and Responsibilities


In 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
Product Management Communications plan execution; deployment launch planning
Program Management Project tracking; bug management
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
76 Solution Accelerator for Business Desktop Deployment

Milestones in the Deploying Phase


Table 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 Deliverable Description Owner
Milestone
Deployment Wizard run The appropriate combination of scenarios (New Deployment
Computer, Refresh Computer, Replace Computer)
is identified.

Running the Deployment Wizard


To 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 Operations
After 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 Responsibilities


In 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
Product Management Communications plan execution; deployment launch planning
Program Management Project tracking; bug management
Development Bug resolution; code optimization
Zero Touch Installation Deployment Feature Team Guide 77

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 Operations


Table 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 Deliverable Description Owner
Operations Milestone
Transition preparations The operations and deployment teams have been Deployment
complete notified of the transition date. Users are now aware
of the change in contact information for support.
Current deployment The current status of all workstation being Deployment
status communicated transitioned is communicated. Any updates to
troubleshooting procedures and diagnostic tools are
also communicated.

Preparing for the Transition


After 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 Status


Just 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,
78 Solution Accelerator for Business Desktop Deployment

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
Zero Touch Installation Deployment Feature Team Guide 79

Appendix A: Sample Customsettings.ini


Files
The 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 Only


This 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, Default
CustomKeysUserData=UDShare,UDDir,UDProfiles,SLShare,OSInstall,Packages(*),Administrators(*)
CustomKeysSysprep=ComputerName,TimeZone,JoinDomain,MachineObjectOU
OSDVariableKeys=OSDINSTALLSILENT,OSDINSTALLPACKAGE,OSDINSTALLPROGRAM,OSDNEWMACHINENAME
ScanStateArgs=/i:miguser.inf /i:migapp.inf /i:migsys.inf /i:sysfiles.inf /i:updateuser.inf /v:7 /x /s /f /o
/c
LoadStateArgs=/v:7 /c
UserExit=ZTIUserExit.vbs

[Default]
UDShare=\\NYC-AM-FIL-01\MigData
SLShare=\\NYC-AM-FIL-01\Logs
UDProfiles=*\*
OSDINSTALLSILENT=1
OSDINSTALLPACKAGE=NYC00001
OSDINSTALLPROGRAM=InstallXP
TimeZone=010
JoinDomain=WOODGROVEBANK
MachineObjectOU= OU=Workstations,DC=americas,DC=corp,DC=woodgrovebank,DC=com
ComputerName=%OSDNEWMACHINENAME%
UDDir=%OSDCOMPUTERNAME%
OSInstall=Y

[DefaultGateway]
172.16.0.3=NYC
172.16.111.3=DALLAS
172.16.116.3=WASHINGTON

[NYC]
UDShare=\\NYC-AM-FIL-01\MigData
80 Solution Accelerator for Business Desktop Deployment

SLShare=\\NYC-AM-FIL-01\Logs
Packages1=NYC00010-Install
Packages2=NYC00011-Install
Administrator1=WOODGROVEBANK\NYC Help Desk Staff

[DALLAS]
UDShare=\\DAL-AM-FIL-01\MigData
SLShare=\\DAL-AM-FIL-01\Logs
SQLDefault=DB_DAL
Administrator1=WOODGROVEBANK\DAL Help Desk Staff

[WASHINGTON]
UDShare=\\WSG-AM-FIL-01\MigData
SLShare=\\WSG-AM-FIL-01\Logs
Administrator1=WOODGROVEBANK\WSG Help Desk Staff

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

[00:0F:20:35:DE:AC]
OSDNEWMACHINENAME=HPD530-1
TimeZone=008

[00:03:FF:FE:FF:FF]
OSDINSTALLPACKAGE=NYC00002
OSDINSTALLPROGRAM=SpecialXP
OSDNEWMACHINENAME=BVMXP

[SysprepInfMapping]
ComputerName=UserData
TimeZone=GuiUnattended
JoinDomain=Identification
MachineObjectOU=Identification

Workstation Settings in AdminDB Database Only


This 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, Default
CustomKeysUserData=UDShare,UDDir,UDProfiles,SLShare,OSInstall,JoinDomain
CustomKeysSysprep=ComputerName,TimeZone,JoinDomain,MachineObjectOU
OSDVariableKeys=OSDINSTALLSILENT,OSDINSTALLPACKAGE,OSDINSTALLPROGRAM,OSDNEWMACHINENAME
ScanStateArgs=/i:miguser.inf /i:migapp.inf /i:migsys.inf /i:sysfiles.inf /i:updateuser.inf /v:7 /x /s /f /o
/c
LoadStateArgs=/v:7 /c
UserExit=ZTIUserExit.vbs
Zero Touch Installation Deployment Feature Team Guide 81

[Default]
UDShare=\\NYC-AM-FIL-01\MigData
SLShare=\\NYC-AM-FIL-01\Logs
UDProfiles=*\*
OSDINSTALLSILENT=1
OSDINSTALLPACKAGE=NYC00001
OSDINSTALLPROGRAM=InstallXP
TimeZone=010
JoinDomain=americas.corp.woodgrovebank.com
MachineObjectOU= OU=Workstations,DC=americas,DC=corp,DC=woodgrovebank,DC=com
ComputerName=%OSDNEWMACHINENAME%
UDDir=%OSDCOMPUTERNAME%
OSInstall=Y

[DefaultGateway]
172.16.0.3=NYC
172.16.111.3=DALLAS
172.16.116.3=WASHINGTON

[NYC]
SQLDefault=DB_NYC

[DALLAS]
SQLDefault=DB_DAL

[WASHINGTON]
SQLDefaul=DB_WSG

[DB_NYC]
SQLServer=NYC-AM-SMS-01
Database=BDDAdminDB
Table=BDDAdminCore
Parameters=MacAddress

[DB_DAL]
SQLServer=DAL-AM-FIL-01
Database=BDDAdminDB
Table=BDDAdminCore
Parameters=MacAddress

[DB_WSG]
SQLServer=WSG-AM-DC-01
Database=BDDAdminDB
Table=BDDAdminCore
Parameters=MacAddress

[SMS]
SQLServer=NYC-AM-SMS-01
Database=SMS_NYC
Table=v_Program
Parameters=PackageID,ProgramName

[SysprepInfMapping]
ComputerName=UserData
TimeZone=GuiUnattended
JoinDomain=Identification
MachineObjectOU=Identification
82 Solution Accelerator for Business Desktop Deployment

Workstation Settings in AdminDB Database and


Customsettings.ini
This 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, Default
CustomKeysUserData=UDShare,UDDir,UDProfiles,SLShare,OSInstall,JoinDomain
CustomKeysSysprep=ComputerName,TimeZone,JoinDomain,MachineObjectOU
OSDVariableKeys=OSDINSTALLSILENT,OSDINSTALLPACKAGE,OSDINSTALLPROGRAM,OSDNEWMACHINENAME
ScanStateArgs=/i:miguser.inf /i:migapp.inf /i:migsys.inf /i:sysfiles.inf /i:updateuser.inf /v:7 /x /s /f /o
/c
LoadStateArgs=/v:7 /c
UserExit=ZTIUserExit.vbs

[Default]
UDShare=\\NYC-AM-FIL-01\MigData
SLShare=\\NYC-AM-FIL-01\Logs
UDProfiles=*\*
OSDINSTALLSILENT=1
OSDINSTALLPACKAGE=NYC00001
OSDINSTALLPROGRAM=InstallXP
TimeZone=010
JoinDomain=americas.corp.woodgrovebank.com
MachineObjectOU= OU=Workstations,DC=americas,DC=corp,DC=woodgrovebank,DC=com
ComputerName=%OSDNEWMACHINENAME%
UDDir=%OSDCOMPUTERNAME%
OSInstall=Y

[DefaultGateway]
172.16.0.3=NYC
172.16.111.3=DALLAS
172.16.116.3=WASHINGTON

[NYC]
UDShare=\\NYC-AM-FIL-01\MigData
SLShare=\\NYC-AM-FIL-01\Logs
UDProfiles=*\*
JoinDomain=americas.corp.woodgrovebank.com
MachineObjectOU= OU=Workstations,DC=americas,DC=corp,DC=woodgrovebank,DC=com
SQLDefault=DB_NYC

[DALLAS]
UDShare=\\DAL-AM-FIL-01\MigData
SLShare=\\DAL-AM-FIL-01\Logs
JoinDomain=americas.corp.woodgrovebank.com
Zero Touch Installation Deployment Feature Team Guide 83

UDProfiles=*\*
SQLDefault=DB_DAL

[WASHINGTON]
UDShare=\\WSG-AM-DC-01\MigData
SLShare=\\WSG-AM-DC-01\Logs
UDProfiles=*\*
JoinDomain=americas.corp.woodgrovebank.com

[02:12:01:03:01:01]
OSDINSTALLSILENT=1
OSDINSTALLPACKAGE=NYC00004
OSDINSTALLPROGRAM=NYC_VM
OSDNEWMACHINENAME=WasCL01
TimeZone=004

[00:0D:56:9B:44:9E]
OSDINSTALLSILENT=1
OSDINSTALLPACKAGE=NYC00002
OSDINSTALLPROGRAM=NYC_GX270
OSDNEWMACHINENAME=WasCL02
TimeZone=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=1
OSDINSTALLPACKAGE=NYC00002
OSDINSTALLPROGRAM=NYC_GX270
OSDNEWMACHINENAME=WasCL04
TimeZone=004

[00:0F:1F:A0:7E:60]
'Replacement scenario from CLI-04 to CLI-06
'UDDir is in AdminDB
OSDINSTALLSILENT=1
OSDINSTALLPACKAGE=NYC00003
OSDINSTALLPROGRAM=NYC_D600
OSDNEWMACHINENAME=WasCL06
'UDDIR=NYC-AM-CLI-04
TimeZone=004

[DB_NYC]
SQLServer=NYC-AM-SMS-01
Database=BDDAdminDB
Table=BDDAdminCore
Parameters=MacAddress

[DB_DAL]
SQLServer=DAL-AM-SMS-01
Database=BDDAdminDB
Table=BDDAdminCore
84 Solution Accelerator for Business Desktop Deployment

Parameters=MacAddress

[SMS]
SQLServer=NYC-AM-SMS-01
Database=SMS_NYC
Table=v_Program
Parameters=PackageID,ProgramName

[SysprepInfMapping]
ComputerName=UserData
TimeZone=GuiUnattended
JoinDomain=Identification
MachineObjectOU=Identification

Appendix B: Customsettings.ini Reference


ZTI 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] Section


The [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, JoinDomain
OSDVariableKeys=OSDINSTALLSILENT, OSDINSTALLPACKAGE, OSDINSTALLPROGRAM, OSDNEWMACHINENAME
ScanStateArgs=/i:miguser.inf /i:migapp.inf /i:migsys.inf /i:sysfiles.inf /i:updateuser.inf /v:7 /x /s /f /o
/c
LoadStateArgs=/v:7 /c
UserExit=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
Zero Touch Installation Deployment Feature Team Guide 85

• CustomKeysSysprep
• OSDVariableKeys
• ScanStateArgs
• LoadStateArgs
The UserExit value is optional. Each of these sections is described in further detail later in this
guide.

Priority
The 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

CustomKeysUserData
This 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
CustomKeysUserD Description
ata
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.
86 Solution Accelerator for Business Desktop Deployment

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 The UNC path specified by this custom key will be copied to the local
DriverPath(*) 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

CustomKeysSysprep
This 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.
Zero Touch Installation Deployment Feature Team Guide 87

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

OSDVariableKeys
This 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

ScanStateArgs
This 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
88 Solution Accelerator for Business Desktop Deployment

LoadStateArgs
This 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

UserExit
This 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] Section


The [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.
[SysprepInfMapping]
ComputerName=UserData
TimeZone=GuiUnattended
JoinDomain=Identification
MachineObjectOU=Identification
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]”).
Zero Touch Installation Deployment Feature Team Guide 89

Configuring the [DefaultGateway] Section


The [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=MainOffice
10.2.1.1=RemoteOffice
Listing 26. [DefaultGateway] section in Customsettings.ini
In each case the syntax is as follows and described in Table 47:
<DefaultGatewayAddress>=<CustomSection>
Table 47. [DefaultGateway] Values and Their Description
SysprepMapping Value Description
< The value specified (for example, “10.1.1.1”) is a TCP/IP default
DefaultGatewayAddress 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 Sections


Custom 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\MigData
SLShare=\\SERVER\Logs
OSDINSTALLSILENT=1
OSDINSTALLPACKAGE=SMS00001
OSDINSTALLPROGRAM=ZTI Install
OSDNEWMACHINENAME=WasWIN2000PRO
ComputerName=WasWIN2000PRO
TimeZone=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.
90 Solution Accelerator for Business Desktop Deployment

• 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.
In each case the syntax is as follows and described in Table 48:
[<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).
Zero Touch Installation Deployment Feature Team Guide 91

Configuring Database Section


To 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.
In each case the syntax is as follows and described in Table 49:
[<CustomSection>]
SQLDefault=<SQLSection>
UserExit=<UserExitScriptFile>
<CustomKeyName>=<KeyValue>

A typical database section may appear as follows:


[BDDAdminDB]
SQLServer=SERVER01
Database=BDDAdminDB
Table=BDDAdminCore
Parameters=MacAddress
SLShare=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=SERVER01
Database=BDDAdminDB
Table=BDDAdminCore
Parameters=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=SERVER01
Database=BDDAdminDB
StoredProcedure=spBDDAdmin
Parameters=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>
92 Solution Accelerator for Business Desktop Deployment

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 Description
Value
< 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.
Zero Touch Installation Deployment Feature Team Guide 93

Appendix D: AdminDB Database Schema


Table 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 Siz Null Mandato Description and Example
e s ry
ID Int 4 Y
ComputerName nvarch 50 Y Computer name of the workstation.
ar
MacAddress nvarch 50 Y MAC address of the workstation ( example:
ar 00:04:75:c2:f2:3e
Note This value must be unique in the database

AssetTag nvarch 50 Y Asset tag of the workstation.


ar
SerialNumber nvarch 50 Y Serial number of the workstation
ar
Make nvarch 50 Y Manufacturer of the workstation
ar
Model nvarch 50 Y Model number of the workstation.
ar
UDShare nvarch 25 Y UNC path to the share where user data is
ar 5 stored.
UDDir nvarch 25 Y Existing computer name (used to make
ar 5 folder beneath UDShare).
UDProfiles nvarch 25 Y Name of user profile being migrated.
ar 5
SLShare nvarch 25 Y UNC path to the share where ZTI script
ar 5 creates log files.
TimeZone nvarch 50 Y Time zone where workstation will be
ar deployed
AdminPassword nvarch 50 Y Password to be assigned to local
ar administrator account on workstation.
DomainAdmin nvarch 50 Y Domain-based account name that is a
ar member of the Domain Administrators
group.
DomainAdminPasswo nvarch 50 Y Password for the domain-based account.
rd ar
JoinDomain nvarch 50 Y Domain name that the workstation will join.
ar
MachineObjectOU nvarch 25 Y Active Directory OU where the machine
ar 5 account will be created.
94 Solution Accelerator for Business Desktop Deployment

JoinWorkGroup nvarch 50 Y Workgroup name that the workstation will


ar join.
FullName nvarch 50 Y User name configured on the workstation.
ar
OrgName nvarch 50 Y Organization name to be configured on the
ar workstation.
Command0 nvarch 25 Y Obsolete field that is no longer used by the
ar 5 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 nvarch 25 Y Unique ID of the OS Deployment package
ar 5 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 nvarch 25 Y Name of the OS Deployment Program that
ar 5 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
OsdNewMachineNam nvarch 25 Y Name to assign to the computer when the
e ar 5 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 nvarch 25 Y Path where OSD stores user state migration
ar 5 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 nvarch 25 Y Indicates the username who added or last
ar 5 modified the record.
Zero Touch Installation Deployment Feature Team Guide 95

Appendix E: AdminDB .csv File Format


Reference
Table 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 Validate Description and Example
d
UpdateFlag nvarcha 1 Y For import:
r
• A = add a record.
• M = modify a record.
• D = delete a record
For export the value is blank.
ComputerName nvarcha 50 Y Computer name of the workstation.
r
MacAddress nvarcha 50 Y MAC address of the workstation
r
Example: 00:04:75:c2:f2:3e
AssetTag nvarcha 50 Asset tag of the workstation.
r
SerialNumber nvarcha 50 Serial number of the workstation
r
Make nvarcha 50 Manufacturer of the workstation
r
Model nvarcha 50 Model number of the workstation.
r
UDShare nvarcha 255 Y UNC path to the share where user data is
r stored.
UDDir nvarcha 255 Existing computer name (used to make folder
r beneath UDShare).
UDProfiles nvarcha 255 Name of user profile being migrated.
r
SLShare nvarcha 255 Y UNC path to the share where ZTI script
r creates log files.
TimeZone nvarcha 50 Time zone where workstation will be
r deployed
AdminPassword nvarcha 50 Password to be assigned to local
r administrator account on workstation.
DomainAdmin nvarcha 50 Domain-based account name that is a
r member of the Domain Administrators group.
DomainAdminPassword nvarcha 50 Password for the domain-based account.
r
96 Solution Accelerator for Business Desktop Deployment

JoinDomain nvarcha 50 Domain name that the workstation will join.


r
MachineObjectOU nvarcha 255 Active Directory OU where the machine
r account will be created.
JoinWorkGroup nvarcha 50 Workgroup name that the workstation will
r join.
FullName nvarcha 50 User name configured on the workstation.
r
OrgName nvarcha 50 Organization name to be configured on the
r workstation.
Command0 nvarcha 255 Obsolete field that is no longer used by the
r 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 nvarcha 255 Unique ID of the OS Deployment package
r 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 nvarcha 255 Name of the OS Deployment Program that
r 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 nvarcha 255 Name to assign to the computer when the
r 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 nvarcha 255 Path where OSD stores user state migration
r information.
OSInstall char 1 Flag monitored by Zerotouchinstallation.vbs
to determine of the script should continue to
run. If set to False,
Zertotouchinstallation.vbs
Zero Touch Installation Deployment Feature Team Guide 97

Appendix F: ZTI Scenario Process


Flowcharts
Figure 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


98 Solution Accelerator for Business Desktop Deployment

Figure 16. Process flowchart for the New Computer scenario


Zero Touch Installation Deployment Feature Team Guide 99

Figure 17. Process flowchart for the Replace Computer scenario


100 Solution Accelerator for Business Desktop Deployment

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
Zero Touch Installation Deployment Feature Team Guide 101

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 0
clean
create partition primary
assign letter=c:
active
exit
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.
102 Solution Accelerator for Business Desktop Deployment

Appendix H: Training Resources


The 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 Press
This 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


Professionals
Located 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 Center


Located 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.
Zero Touch Installation Deployment Feature Team Guide 103

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 TechNet
Located 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.
104 Solution Accelerator for Business Desktop Deployment

Appendix I: Resolving Common ZTI


Deployment Problems
The following describes how to resolve some common ZTI deployment problems.

Troubleshooting General Deployment Problems


Table 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 Workstations are not included in Verify that the workstations are in
receiving the OSD the appropriate SMS collection. the SMS collection used during
package advertisements the distribution of your OSD
package.
ZTI scripts do not run Workstations may not meet the Review workstation hardware and
properly hardware and software software requirements in
requirements. Verifying Correct Workstation
Software Versions and Verifying
Adequate Workstation Resources
earlier in this guide.
Appropriate permissions may not Log on as the appropriate account
be set on MigData, Logs, or and attempt to access files in the
distribution point shares. shares.
Updated packages and Scheduled distribution of updates Manually updated the distribution
programs are not to packages and programs may points by using SMS 2003
appearing on distribution be occurring longer than you Administrator.
points required.
Scanstate.exe returns an Task Scheduler service is running Modify the Sysfiles.inf to exclude
error code 32 on a that keeps the file SchedLog.txt in SchedLog.txt
workstation running use.
Windows NT SP6a

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 RIS


In 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
Zero Touch Installation Deployment Feature Team Guide 105

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 Configuration


Depending 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 Time


If 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.
106 Solution Accelerator for Business Desktop Deployment

Troubleshooting Failed New Computer Scenario


DeploymentFailure to Copy Log Files to Shared Folders
During 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.vbs
Table 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 This Error Code Indicates That…
Code
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">
.
Zero Touch Installation Deployment Feature Team Guide 107

.
.

Figure 19. Excerpt from the OSDAgent.log file that contains error code 5001
108 Solution Accelerator for Business Desktop Deployment

Appendix J: Deploying Windows XP Using


Windows Product Activation
You 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.
Zero Touch Installation Deployment Feature Team Guide 109

Appendix K: Sample Stored Procedure


Calls
Listing 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
GO
110 Solution Accelerator for Business Desktop Deployment

SET 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 BDDAdminCore


WHERE MacAddress = @MacAddress

/* No record? Add one. */

IF @Cnt = 0
BEGIN

/* 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 BDDAdminCore


WHERE MacAddress = @MacAddress

GO
SET QUOTED_IDENTIFIER OFF
GO
SET ANSI_NULLS ON
GO
Zero Touch Installation Deployment Feature Team Guide 111

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

You might also like