Zero Touch Installation Deployment Feature Team Guide

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.

Figure 2. Activities during the Planning Phase
See full-sized image

The following sections describe the planning process:

On This Page

	Roles and Responsibilities
	Milestones and Deliverables in the Planning Phase
	Selecting the Appropriate Deployment Scenario
	Ensuring That the Required Infrastructure Exists
	Determining the Appropriate ZTI Processing Rules
	Training Team Members
	Obtaining Consensus for Deployment Plans

Roles and Responsibilities

All six role clusters from the MSF Team Model play a role in the Planning Phase of the initiative. Table 4 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 4. Team Roles and Responsibilities in the Planning Phase

Top of page

Milestones and Deliverables in the Planning Phase

Table 5 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 5. Planning Phase Project Milestones and Deliverable Description

Top of page

Selecting the Appropriate Deployment Scenario

As the first step in the Planning Phase, choose the appropriate deployment scenario. Table 6 lists the deployment scenarios and provides a brief description of each scenario.

Table 6. Deployment Scenarios and Description

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.

Figure 3. Refresh Computer deployment process
See full-sized image

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:

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

Figure 4. New Computer deployment process
See full-sized image

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.

Figure 5. Replace Computer deployment process
See full-sized image

To perform a Replace Computer scenario, follow these steps:

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:

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:

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:

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:

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.

Top of page

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:

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:

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:

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:

You also need to know how long the user state migration data must be stored. You need to store 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:

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:

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.

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:

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:

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:

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:

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:

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:

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:

In addition, when you want to deploy to workstations through a firewall, you need to ensure that the appropriate TCP and UDP ports are opened on firewalls. For more information, see Ports that Systems Management Server 2003 uses to communicate through a firewall or through a proxy server in Additional Resources later in this guide.

Top of page

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:

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
See full-sized image

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

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

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:

Priority= MACADDRESS, DefaultGateway, Default
CustomKeysUserData=UDShare,UDDir,UDProfiles,SLShare,
OSInstall,JoinDomain
CustomKeysSysprep=ComputerName,TimeZone,JoinDomain,
MachineObjectOU
OSDVariableKeys=OSDINSTALLSILENT,OSDINSTALLPACKAGE,
OSDINSTALLPROGRAM,OSDNEWMACHINENAME
    .
    .
    .

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

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

Prioritizing the ZTI Processing 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:

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.

Note Some parts of the following code snippet have been displayed in multiple lines only for better readability. These should be entered in a single line.

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.

Note Some parts of the following code snippet have been displayed in multiple lines only for better readability. These should be entered in a single line.

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:

Supplying Global Configuration Settings

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

Priority= Default, DefaultGateway, SQL 
    .
    .
    .

Listing 4. Example of how to use Default to apply global configuration settings

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

Supplying Default Configuration Settings

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

Priority= DefaultGateway, SQL, Default
    .
    .
    .

Listing 5. Example of how to use Default to apply default configuration settings

By placing the Default keyword at the end of the Priority attribute list, the configuration settings in the [Default] section are used only if the configuration settings were not found in the [DefaultGateway] sections or in the configuration settings stored in ZTI Admin DB (as designated by the SQL keyword in Listing 5).

Determining the Group-Based ZTI Processing 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

You can group your workstations based on different criteria. Table 10 lists the predefined workstation groupings. In addition to these groupings, you can create custom workstation groupings.

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

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] as shown 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 Windows Management Instrumentation (WMI) call and look for the corresponding section, for instance [Dell Computer Corporation].

Example: Workstation Groupings Selected by Woodgrove

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

[DefaultGateway]
172.16.0.3=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 11 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 11. Common Group-Based Configuration Settings and Their Description

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:

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

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:

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

For workstations that:

You need to specify a method of uniquely identifying the workstation and the configuration settings that you want to apply to the workstation. Table 12 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 12. Methods for Identifying Individual Workstations and What the Grouping Determines

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

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 13 lists the common workstation-based configuration settings and the purpose of those settings.

Table 13. Common Workstation-Based Configuration Settings and Their Descriptions

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 14 lists the workstation-specific configuration settings applied to each workstation.

Table 14. Woodgrove Workstations and the Corresponding Configuration Settings

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 15 lists each method and the advantages and disadvantages of each method.

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

Store workstation-based configuration settings in the:

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

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.

Note Some parts of the following code snippet have been displayed in multiple lines only for better readability. These should be entered in a single line.

[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 functions in the [Settings] section

Note   You need to include any user exit scripts in the OldComputer package source directory so that they can be accessed when it is time for the user exit script to be run.

Another common user exit function is to determine the type of computer by using one of the computer chassis type variables provided by ZeroTouchInstallation.vbs listed in Table 16. The chassis type is determined through WMI by using the Win32_SystemEnclosure WMI class.

Table 16. Computer Chassis Type Variables and Their Description

Note   In previous versions of ZTI, the IsServer flag indicated that the existing operating system is a server operating system (such as Windows Server™ 2003, Enterprise Edition). This flag has been renamed to IsServerOS.

You can use these computer chassis type variables in any user exit function (or other application that you create) by using the dicLocalData() function. Listing 11 illustrates the use of these variables in a user exit function to install additional laptop utilities.

If dicLocalData(“IsLaptop”) Then
   AddtionalSMSPackages=” NYC00010-InstallLaptopUtilites
End If

Listing 11. User exit function selecting an additional SMS package based on the IsLaptop variable

Example: Custom Exit Function Selected by Woodgrove

The custom exit function in this example, ZTIUserExit.vbs, allows you to easily extend the functionality of ZeroTouchInstallation.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 F: 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 F: Sample User Exit Function are included as a part of the Solution Accelerator for 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 reference the information by accessing the workstation-specific settings you stored in the AdminDB database.

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

[Settings]
Priority= DefaultGateway, IdentifyComputer, SQL, Default
    .
    .
    .
 [IdentifyComputer]
 SQLDefault=DB_IdentifyComputer
  
 [DB_IdentifyComputer]
 SQLServer=SERVER1
 Database=BDDAdminDB
 StoredProcedure=IdentifyComputer
 Parameters=MacAddress, Make, Model

Example: Custom-Stored Procedure Selected by Woodgrove

Listing 12 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, IdentifyComputer stored procedure, and a setup script in Appendix J: Sample Stored Procedure Calls later in this guide.

Top of page

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:

Top of page

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:

Top of page

6 of 25