Zero Touch Installation Deployment Feature Team Guide

Appendix K: Automating Application Deployment Scenarios

Published: August 27, 2005

The SMS 2003 OS Deployment Feature Pack supports the installation of applications as part of the deployment process but does not provide a way to dynamically build this list. Using only the OS Deployment Feature Pack, it would be necessary to define a different program, collection, and advertisement for each unique combination, a process that would quickly become unmanageable. As an alternative, standard SMS 2003 software distribution, based on inventory-driven collections, could be used, but this method would introduce delays ranging from minutes to hours before these applications would be installed.

To work around these limitations, the Solution Accelerator for Business Desktop Deployment Enterprise Edition includes the ability to install a dynamically generated list of applications

This appendix discusses the following scenarios:

Scenario 1: Role-based application installation. Each computer can be assigned a role, which is used to select the packages that should be installed on the computer.

Scenario 2: Location-based application installation. Based on the computer’s location on the computer network, location-based packages can be selected.

Scenario 3: Hardware-specific application installation. Packages can be installed based on the make and model of the computer.

Scenario 4: Computer-specific application installation. Packages are installed based on a specific computer attribute such as computer name or MAC address.

Scenario 5: Dynamic computer-specific application installation. Using the SMS 2003 inventory for the original operating system, a list of packages to be installed on the new operating system can be constructed. If newer versions of the package are available, they can be substituted for the previous versions.

Scenario 6: User self-provisioned hardware-specific application installation. Using Zero Touch Provisioning, users or appropriate surrogates can build the application list prior to the operating system deployment.

Scenario 7: Customized dynamic computer-specific application installation. This is a variation on the dynamic computer-specific application installation scenario described above. It allows users or appropriate surrogates to use Zero Touch Provisioning to customize the list of applications determined using SMS 2003 inventory; applications can be added to (if additional applications are needed) or removed from (if some applications are no longer used) the list as necessary.

Scenarios 1-4 assume that the application package list is manually specified, either through a configuration file (CustomSettings.ini) or database queries. This places the burden on IT administrators to determine which applications should be installed. Scenarios 5-7 describe how to help make the process of specifying the application package easier.

Scenarios 1-4 can be used independently of or in combination with other scenarios. Scenario 6 is dependent on information described in Scenario 4. Scenario 7 is dependent on the information described in Scenario 4 and Scenario 6.

In all cases, the application package is specified using the SMS package ID and program name as shown in Listing 47.

XXX00001-Program name

Listing 47. Example of SMS package ID and program name

In Listing 47, “XXX00001” is the SMS package ID and “Program name” is the program defined for the package that should be installed. When specifying these values directly in the CustomSettings.ini file, you should specify each value on a separate line as illustrated in Listing 48. Notice that the numeric suffix just differentiates between the values listed in a particular section.

[AppSection]
Packages1=XXX00001-Program name
Packages2=XXX00002-Program name

Listing 48. Excerpt from the Customsettings.ini file that illustrates the use of the SMS package ID and program name

When retrieving a list of packages from a database, the recordset (returned either from a simple query or from a stored procedure) should include at least one column called Packages (using the same XXX00001-Program Name syntax described above); each row returned will be added to the list of application packages.

On This Page
Scenario 1: Role-Based Application InstallationScenario 1: Role-Based Application Installation
Scenario 2: Location-Based Application InstallationScenario 2: Location-Based Application Installation
Scenario 3: Hardware-Specific Application InstallationScenario 3: Hardware-Specific Application Installation
Scenario 4: Computer-Specific Application InstallationScenario 4: Computer-Specific Application Installation
Scenario 5: Dynamic Computer-Specific Application InstallationScenario 5: Dynamic Computer-Specific Application Installation
Scenario 6: User Self-Provisioned Computer-Specific Application InstallationScenario 6: User Self-Provisioned Computer-Specific Application Installation
Scenario 7: User-Customized Dynamic Computer-Specific Application InstallationScenario 7: User-Customized Dynamic Computer-Specific Application Installation

Scenario 1: Role-Based Application Installation

The biggest challenge with installing application packages on a computer based on the role of that computer is determining what that computer's role should be. It is assumed that the administrator will specify this manually for each computer.

As with all ZTI customization, this role information can be specified in the configuration file, CustomSettings.ini, or retrieved from a database. In both cases, the CustomSettings.ini file needs to be modified to include the new Role custom key as shown in Listing 49.

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]
...
CustomKeysUserData=UDShare, UDDir, UDProfiles,
SLShare, OSInstall, Packages(*), Administrators(*),
PowerUsers(*), DriverPath(*), Role
...

Listing 49. Excerpt from the Customsettings.ini file that illustrates addition of the Role custom key

With this modification, the ZTI rules engine will attempt to establish the value of the Role custom key using the remaining rules in the CustomSettings.ini file.

Using Role Values Directly in CustomSettings.ini

To select packages based on the default gateway values of the computer:

1.

Modify the CustomSettings.ini file to include the Role literal value in the Priority line (as illustrated in Listing 50).

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=MacAddress, DefaultGateway, Role, Default
CustomKeysUserData=UDShare, UDDir, UDProfiles,
SLShare, OSInstall, Packages(*), Administrators(*),
PowerUsers(*), DriverPath(*), Role
...

Listing 50. Excerpt from the Customsettings.ini file that illustrates addition of the Role custom key

2.

Create a value for the Role custom key in a section based on the computer’s MAC address as illustrated in Listing 51).

[00:03:FF:CB:4E:C2]
Role=Accounting

Listing 51. Excerpt from the Customsettings.ini file that illustrates computer-specific section that contains Role

This would assign the value “Accounting” to the Role custom key. That value would then be used (based on the inclusion of “Role” on the Priority list) to find a section in the CustomSettings.ini file named Accounting (as illustrated in Listing 51).

3.

Create a section based on the value specified in the previous step, and populate the section with the packages to be deployed (as illustrated in Listing 52)

[Accounting]
Packages1=XXX00001-Program name 1
Packages2=XXX00002-Program name 2
Packages3=XXX00003-Program name 3

Listing 52. Excerpt from the Customsettings.ini file that illustrates the application packages installed for the Accounting role

The packages specified (XXX00001-Program name 1, XXX00002-Program name 2, and XXX00003-Program name 2) would be installed on the computer during the State Restore Phase of the deployment process.

Using Role Values to Query a Database

In more complex environments, maintaining all configuration information in the CustomSettings.ini file may be too difficult. As an alternative, database access information can be specified. As described above, the Role custom key must be added to the CustomSettings.ini file CustomKeysUserData line to instruct the rules engine to attempt to find the value. Then, instead of using the retrieved value directly to find a matching section, the value can be used as part of a database query.

To configure Role values to query a database, complete the following steps:

1.

Create a database table to query (as illustrated in Listing 53).

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.

use [BDDAdminDB]
go
 
if exists (select * from dbo.sysobjects where
id = object_id(N'[dbo].[RolePackages]') and
OBJECTPROPERTY(id, N'IsUserTable') = 1)
drop table [dbo].[RolePackages]
go
 
CREATE TABLE [dbo].[RolePackages] (
    [Role] [nvarchar] (50),
    [Packages] [nvarchar] (50)
)
go

Listing 53. Sample SQL Script to create a table used to associate packages with roles

2.

Populate the table with data that associates the appropriate package with the appropriate roles (illustrated in Listing 54).

For example, you could insert a row for each package that needs to be installed (XXX00001-Program name 1, XXX00002-Program name 2, and XXX00003-Program name 2) for the Accounting role. Compare this to the information in Listing 52.

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.

use [BDDAdminDB]
go
 
insert into RolePackages (Role, Packages) 
values('Accounting', 'XXX00001-Program name 1')
go 
insert into RolePackages (Role, Packages) 
values('Accounting', 'XXX00002-Program name 2')
go
insert into RolePackages (Role, Packages) 
values('Accounting', 'XXX00003-Program name 3')
go

Listing 54. Sample data entered to associate packages with roles

3.

Configure the CustomSettings.ini file to query this database table by specifying the name of a section (in the Priority list) that points to the database information (as illustrated in Listing 55).

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=MacAddress, DefaultGateway, RoleQuery,
Default
CustomKeysUserData=UDShare, UDDir, UDProfiles,
SLShare, OSInstall, Packages(*), Administrators(*),
PowerUsers(*), DriverPath(*), Role
...

Listing 55. Excerpt from Customsettings.ini that illustrates modified Priority list

4.

Create a RoleQuery section to specify the name of a database section (as illustrated in Listing 56).

[RoleQuery]
SQLDefault= DB_RoleQuery

Listing 56. Excerpt from Customsettings.ini that illustrates RoleQuery section with the name of a database section

5.

Create the database section.

This section includes the database connection information and query details (as illustrated in Listing 57).

[DB_RoleQuery]
SQLServer=SERVER1
Database=BDDAdminDB
Table=RolePackages
Parameters=Role
SQLShare=Logs

Listing 57. Excerpt from Customsettings.ini that illustrates the database section

In the example in Listing 57, the BDDAdminDB database on the computer running SQL Server named SERVER1 will be queried. The database contains a table named RolePackages (created in step 1).

When ZeroTouchInstallation.vbs runs, a SQL SELECT statement is automatically generated, and the value of the Role custom key is passed as a parameter to the query (as shown in Listing 58).

SELECT * FROM RolePackages WHERE Role = ?

Listing 58. Sample SQL query created automatically based on the database section

The actual value of the Role custom key will be substituted for the “?” in Listing 58. This query would return a recordset with the rows entered in step 2. Each row specifies a package to be added to the list of packages to be installed during the State Restore Phase.

Retrieving the Role Value from the Database

In the previous example, the role value was determined from the CustomSettings.ini file. Alternatively, you can retrieve the value from the BDDAdminCore table defined by the default BDDAdminDB database setup. Because the BDDAdminCore table does not include a Role column, you need to add this column to the table. Listing 59 illustrates a SQL query that can add the Role column to the BDDAdminCore table.

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.

use [BDDAdminDB]
go
 
ALTER TABLE [dbo].[BDDAdminCore] 
ADD COLUMN [Role] [nvarchar] (50)
go
ALTER TABLE [dbo].[BDDAdminBackup]
ADD COLUMN [Role] [nvarchar] (50)
go

Listing 59. Sample SQL query to add the Role column to the BDDAdminCore table

Once the Role column has been added, you need to add it to the AdminDB hypertext application (HTA). This allows the Role column to be displayed while editing the contents of the BDDAdminCore database table. You can add the Role column to the HTA by editing the included BDDAdminDB.config file to include the new Role column in the list of columns included in the ColumnsHeaders list.

Scenario 2: Location-Based Application Installation

Often you want to install a specific list of application packages based on the location of the computer. (In effect, each location has its own “role.”) The list of application packages to be installed can be specified in the CustomSettings.ini file or be retrieved from a database.

You can use the default gateway of the target computer to designate the location of the computer. You can assign multiple default gateways to a location. ZeroTouchInstallation.vbs uses the default gateway information to determine the location of the computer.

Using Default Gateway Values Directly in CustomSettings.ini

To select packages based on the default gateway values of the computer:

1.

Modify the CustomSettings.ini file to include the DefaultGateway literal value in the Priority line (as illustrated in Listing 60).

[Settings]
...
Priority=MacAddress, DefaultGateway, Default
...

Listing 60. Excerpt from Customsettings.ini that illustrates the database section

The DefaultGateway value causes the ZTI rules engine to look for a section named [DefaultGateway]. The [DefaultGateway] section contains pointers to other sections that have the actual application package settings.

2.

Create the [DefaultGateway] section (as illustrated in Listing 61).

[DefaultGateway]
192.168.0.1=HOUSTON
11.1.1.11=REDMOND
172.28.20.1=REDMOND
...

Listing 61. Excerpt from Customsettings.ini that illustrates [DefaultGateway] section

As illustrated in Listing 61, in the “REDMOND” section there are two different default gateway values (11.1.1.11 and 172.28.20.1). In the “HOUSTON” section there is only one default gateway value (192.168.0.1). You can use this method to deploy location-specific packages to REDMOND and HOUSTON.

3.

Create a section for each default gateway specified in the [DefaultGateway] section (as illustrated in Listing 62).

[REDMOND]
Packages1=XXX00004-Program name 4
Packages2=XXX00005-Program name 5
 
[HOUSTON]
Packages1=XXX00006-Program name 6
Packages2=XXX00007-Program name 7
Packages3=XXX00008-Program name 8

Listing 62. Excerpt from Customsettings.ini that illustrates package selection based on the default gateway

Based on configuration settings in Listing 62, different packages (and a different number of packages) are installed on computers in REDMOND compared with HOUSTON.

Using Default Gateway Values to Query a Database

You can achieve the same results by performing queries on a database, instead of the CustomSettings.ini file.

Retrieve default gateway values from a database by performing the following steps:

1.

Create a table in the BDDAdminDB database to relate location-specific packages with default gateways (as illustrated in Listing 63).

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.

use [BDDAdminDB]
go
 
if exists (select * from dbo.sysobjects where
id = object_id(N'[dbo].[LocationPackages]') and
OBJECTPROPERTY(id, N'IsUserTable') = 1)
drop table [dbo].[LocationPackages]
go
 
CREATE TABLE [dbo].[LocationPackages] (
    [DefaultGateway] [nvarchar] (50),
    [Packages] [nvarchar] (50)
)
go

Listing 63. Excerpt from Customsettings.ini that illustrates creating a table to use in database query

2.

Populate the table with data that associates the appropriate package with the appropriate default gateway (as illustrated in Listing 64).

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.

use [BDDAdminDB]
go
 
insert into LocationPackages (DefaultGateway, Packages) 
values('11.1.1.11', 'XXX00004-Program name 4')
go 
insert into LocationPackages (DefaultGateway, Packages) 
values('11.1.1.11', 'XXX00005-Program name 5')
go
insert into LocationPackages (DefaultGateway, Packages) 
values('172.28.20.1', 'XXX00004-Program name 4')
go 
insert into LocationPackages (DefaultGateway, Packages) 
values('172.28.20.1', 'XXX00005-Program name 5')
go
insert into LocationPackages (DefaultGateway, Packages)
values('192.168.0.1', 'XXX00006-Program name 6')
go
insert into LocationPackages (DefaultGateway, Packages) 
values('192.168.0.1', 'XXX00007-Program name 7')
go
insert into LocationPackages (DefaultGateway, Packages)
values('192.168.0.1', 'XXX00008-Program name 8')
go

Listing 64. Sample data entered to associate packages with default gateways

3.

Configure the CustomSettings.ini file to query this database table by specifying the name of a section (in the Priority list) that points to the database information (as illustrated in Listing 65).

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=MacAddress, DefaultGateway, LocationQuery, 
Default
CustomKeysUserData=UDShare, UDDir, UDProfiles, 
SLShare, OSInstall, Packages(*), Administrators(*),
PowerUsers(*), DriverPath(*)
...

Listing 65. Excerpt from Customsettings.ini that illustrates LocationQuery section in the Priority list

4.

Create a LocationQuery section to specify the name of a database section (as illustrated in Listing 66).

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.

This new LocationQuery section must then
specify the name of a database section.
[LocationQuery]
SQLDefault= DB_LocationQuery

Listing 66. Excerpt from Customsettings.ini that illustrates LocationQuery section with the name of a database section

5.

Create the database section that contains the database connection and query details (as illustrated in Listing 67).

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.

Then that section specifies the database 
connection information and query details.
[DB_LocationQuery]
SQLServer=SERVER1
Database=BDDAdminDB
Table=LocationPackages
Parameters=DefaultGateway

Listing 67. Excerpt from Customsettings.ini that illustrates the database section

In the example in Listing 67, the BDDAdminDB database on the computer running the SQL Server named SERVER1 will be queried. The database contains a table named LocationPackages (created in step 1).

When ZeroTouchInstallation.vbs runs, a SQL SELECT statement is automatically generated, and the value of the DefaultGateway custom key is passed as a parameter to the query (as shown in Listing 68).

SELECT * FROM LocationPackages WHERE DefaultGateway = ?

Listing 68. Sample SQL query created automatically based on the database section

The actual value of the DefaultGateway custom key will be substituted for the “?” in Listing 68. If there are multiple default gateways, an “IN” clause will be built instead. This query returns a recordset with the rows entered in step 2. Each row specifies a package to be added to the list of packages to be installed during the State Restore Phase.

Using Default Gateway Values to Query a Database by Site

When using the CustomSettings.ini file, it is possible to map multiple default gateways to one settings section in order to use the same settings for each. The previous example does not support this, though, so the package list needs to be duplicated for each default gateway. This can be avoided by creating a more complex database structure.

Retrieve default gateway values from a database by performing the following steps:

1.

Create the tables in the BDDAdminDB database to relate location-specific packages with default gateways (as illustrated in Listing 69).

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.

use [BDDAdminDB]
go
 
if exists (select * from dbo.sysobjects where
id = object_id(N'[dbo].[SitePackages]') and 
OBJECTPROPERTY(id, N'IsUserTable') = 1)
drop table [dbo].[SitePackages]
go
if exists (select * from dbo.sysobjects 
where id = object_id(N'[dbo].[GatewayToSite]') and
OBJECTPROPERTY(id, N'IsUserTable') = 1)
drop table [dbo].[GatewayToSite]
go
if exists (select * from dbo.sysobjects where
id = object_id(N'[dbo].[LocationPackages]') and
OBJECTPROPERTY(id, N'IsView') = 1)
drop view [dbo].[LocationPackages]
go
 
CREATE TABLE [dbo].[SitePackages] (
    [Site] [nvarchar] (50),
    [Packages] [nvarchar] (50)
)
go

CREATE TABLE [dbo].[GatewayToSite] (
    [DefaultGateway] [nvarchar] (50),
    [Site] [nvarchar] (50)
)
go

CREATE VIEW [dbo].[LocationPackages] AS
SELECT a.Site, Packages, DefaultGateway FROM 
SitePackages a, GatewayToSite b
WHERE a.Site = b.Site
go

Listing 69. SQL query to create the tables and view

2.

Populate the table with data that associates the appropriate package with the appropriate location (as illustrated in Listing 70).

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.

use [BDDAdminDB]
go

insert into GatewayToSite(DefaultGateway, Site)
values ('192.168.0.1', 'HOUSTON')
go
insert into GatewayToSite(DefaultGateway, Site)
values ('11.1.1.11', 'REDMOND')
go
insert into GatewayToSite(DefaultGateway, Site)
values ('172.28.20.1', 'REDMOND')
go

insert into SitePackages(Site, Packages) 
values('REDMOND', 'XXX00004-Program name 4')
go

insert into SitePackages(Site, Packages)
values('REDMOND', 'XXX00005-Program name 5')
go

insert into SitePackages(Site, Packages) 
values('HOUSTON', 'XXX00006-Program name 6')
go
insert into SitePackages(Site, Packages) 
values('HOUSTON', 'XXX00007-Program name 7')
go
insert into SitePackages(Site, Packages) 
values('HOUSTON', 'XXX00008-Program name 8')
go

Listing 70. Excerpt from Customsettings.ini that illustrates the database section

3.

Configure the CustomSettings.ini file to query this database table by specifying the name of a section (in the Priority list) that points to the database information (as illustrated in Listing 71).

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=MacAddress, DefaultGateway, LocationQuery,
Default
CustomKeysUserData=UDShare, UDDir, UDProfiles,
SLShare,OSInstall, Packages(*), Administrators(*),
PowerUsers(*), DriverPath(*)
...

Listing 71. Excerpt from Customsettings.ini that illustrates LocationQuery section in the Priority list

4.

Create a LocationQuery section to specify the name of a database section (as illustrated in Listing 72).

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.

This new LocationQuery section must then
specify the name of a database section.
[LocationQuery]
SQLDefault= DB_LocationQuery

Listing 72. Excerpt from Customsettings.ini that illustrates LocationQuery Section with the name of a database section

5.

Create the database section.

This section includes the database connection information and query details (as illustrated in Listing 73).

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.

Then that section specifies the database
connection information and query details.
[DB_LocationQuery]
SQLServer=SERVER1
Database=BDDAdminDB
Table=LocationPackages
Parameters=DefaultGateway

Listing 73. Excerpt from Customsettings.ini that illustrates the database section

In the example in Listing 73, the BDDAdminDB database on the computer running the SQL Server named SERVER1 will be queried. The database contains a table named LocationPackages (created in step 1).  

When ZeroTouchInstallation.vbs runs, a SQL SELECT statement is automatically generated, and the value of the DefaultGateway custom key is passed as a parameter to the query (as shown in Listing 74).

SELECT * FROM LocationPackages WHERE DefaultGateway = ?

Listing 74. Sample SQL query created automatically based on the database section

The actual value of the DefaultGateway custom key will be substituted for the “?” in Listing 74. If there are multiple default gateways, an “IN” clause will be built instead. This query returns a recordset with the rows entered in step 2. Each row specifies a package to be added to the list of packages to be installed during the State Restore Phase.

Note   The LocationPackages view has the same basic structure as the LocationPackages table in the previous example.

Scenario 3: Hardware-Specific Application Installation

Because different hardware configurations may require different software packages to support specific hardware (CD burning software, DVD players) or vendor-specific functionality (management tools, Basic Input/Output System (BIOS) configuration tools), and because placing these in the computer image would result in significantly larger images (especially if you have many different types of hardware to support), it is useful to be able to install packages based on the type of computer being used. Three separate values are retrieved from the computer’s SMBIOS structures using WMI to assist with this process:

Make. This specifies the make (or manufacturer) of the computer. For example, on a Dell Latitude D600 laptop, the value of Make is “Dell Computer Corporation.”

Model. This specifies the specific model name or part number (depending on the vendor) of the computer. On the same Dell Latitude D600, the Model value is “Latitude D600.”

Product. With some computer vendors, the make and model may not be sufficient to uniquely identify the characteristics of a particular configuration (for example, hyperthreaded or nonhyperthreaded chipsets). The Product value might be useful to differentiate. On the Dell Latitude D600, the value of Product is “0X2034.”

For the example below, the first two values will be used. As in the previous scenarios, the list of application packages to be installed can be specified in the CustomSettings.ini file or be retrieved from a database. Unlike the previous scenarios, the mechanism of selecting the values is a little more complicated since two different values (Make and Model) are needed to select the appropriate list of packages.

Using Make and Model Values Directly in CustomSettings.ini

Complete the following steps to select packages based on the make and model of the computer:

1.

Modify the CustomSettings.ini file to include the Make literal value in the Priority list (as illustrated in Listing 75).

[Settings]
...
Priority=MacAddress, Make, Default
...

Listing 75. Excerpt from Customsettings.ini that illustrates adding Make to the Priority list

This will cause the ZTI rules engine to look for a section matching the current Make value (for example, Dell Computer Corporation).

2.

Create a section for the computer manufacturer, and create subsection values for each model of (as illustrated in Listing 76).

[Dell Computer Corporation]
Subsection=Dell-%Model%

Listing 76. Excerpt from Customsettings.ini that illustrates adding a manufacturer section and subsections

Because these settings do not yet uniquely identify a particular make/model combination, further specification is required for each potential %Model% variable.

3.

Create a section for each potential %Model% value, and include the packages to be installed in that section (as illustrated in Listing 77).

[Dell-Latitude D600]
Packages1=XXX00009-Program name 9
Packages2=XXX0000A-Program name 10

Listing 77. Excerpt from Customsettings.ini that illustrates the database section

In this example, the current Model value (for example, Latitude D600) will replace the %Model% string. Then a section matching the full Subsection value is located. In this example, two packages are installed on all Dell Latitude D600 models.

Note   You need to create similar sections for other make/model combinations.

Using Make and Model Values to Query a Database

Querying a database table to retrieve the list of packages to install may be more useful than hard-coding this list in the CustomSettings.ini file. The table structure for doing this based on the computer make and model is slightly more complicated as it needs to include two identifying columns (Make and Model).

To use Make and Model values to query a database:

1.

Create the tables in the BDDAdminDB database to relate specific packages with make and model of computers (as illustrated in Listing 78).

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.

use [BDDAdminDB]
go

if exists (select * from dbo.sysobjects where 
id = object_id(N'[dbo].[MakeModelPackages]') and
OBJECTPROPERTY(id, N'IsUserTable') = 1)
drop table [dbo].[MakeModelPackages]
go

CREATE TABLE [dbo].[MakeModelPackages] (
    [Make] [nvarchar] (50),
    [Model] [nvarchar] (50),
    [Packages] [nvarchar] (50)
)
go

Listing 78. SQL query to create the tables

2.

Populate the table with data that associates the appropriate package with the appropriate makes and models (as illustrated in Listing 79).

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.

Now you can populate that table with rows
for the sample Dell Latitude D600.
use [BDDAdminDB]
go

insert into MakeModelPackages (Make, Model, Packages)
values('Dell Computer Corporation', 'Latitude D600',
'XXX00009-Program name 9')
go 
insert into MakeModelPackages (Make, Model, Packages)
values('Dell Computer Corporation', 'Latitude D600',
'XXX0000A-Program name 10')
go

Listing 79. SQL query to populate the tables

3.

Configure the CustomSettings.ini file to query this database table by specifying the name of a section (MakeModelQuery in the Priority list) that points to the database information (as illustrated in Listing 80).

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=MacAddress, DefaultGateway, MakeModelQuery,
Default
CustomKeysUserData=UDShare, UDDir, UDProfiles, 
SLShare, OSInstall, Packages(*), Administrators(*),
PowerUsers(*), DriverPath(*)
...

Listing 80. Excerpt from Customsettings.ini that illustrates MakeModelQuery section in the Priority list

4.

Create a MakeModelQuery section to specify the name of a database section (as illustrated in Listing 81).

[MakeModelQuery]
SQLDefault= DB_MakeModelQuery

Listing 81. Excerpt from Customsettings.ini that illustrates MakeModelQuery section with the name of a database section

5.

Create a database section to specify the database information and query details (as illustrated in Listing 82).

[DB_MakeModelQuery]
SQLServer=SERVER1
Database=BDDAdminDB
Table=MakeModelPackages
Parameters=Make, Model
SQLShare=Logs

Listing 82. Excerpt from Customsettings.ini that illustrates the database section

In the example in Listing 82, the BDDAdminDB database on the computer running the SQL Server named SERVER1 will be queried. The database contains a table named MakeModelPackages (created in step 1).  

When ZeroTouchInstallation.vbs runs, a SQL SELECT statement is automatically generated, and the value of the MakeModelQuery custom key is passed as a parameter to the query (as shown in Listing 83).

SELECT * FROM MakeModelPackages WHERE Make = ? AND Model = ?

Listing 83. Sample SQL query created automatically based on the database section

The actual value of the Make and Model custom key will be substituted for the corresponding “?” in Listing 83. This query returns a recordset with the rows entered in step 2. Each row specifies a package to be added to the list of packages to be installed during the State Restore Phase.

Scenario 4: Computer-Specific Application Installation

There may be some situations where it would be useful to specify different application packages that should be installed on individual computers. This computer-specific information can be included directly in the CustomSettings.ini file or can be retrieved from a database. In either case, it is easiest to retrieve this information using the MAC address (or list of MAC addresses, if the computer has multiple network adapters) of the computer.

Using MAC Address Values Directly in CustomSettings.ini

To use the MAC address values to select the packages to deploy:

1.

Modify the CustomSettings.ini file to include the MacAddress literal value in the Priority list (as illustrated in Listing 84).

[Settings]
...
Priority=MacAddress, DefaultGateway, Default
...

Listing 84. Excerpt from Customsettings.ini that illustrates adding MacAddress section in the Priority list

This causes the ZTI rules engine to look for a section based on the MAC address of the current computer.

2.

Create a section for the MAC Address of each computer, and add the packages to the section (as illustrated in Listing 85).

[00:03:FF:CB:4E:C2]
Packages1=XXX0000B-Program name 11
Packages2=XXX0000C-Program name 12

Listing 85. Excerpt from Customsettings.ini that illustrates the MacAddress section for a specific computer

In this case, the two packages listed would be installed during the State Restore Phase on the computer with MAC address 00:03:FF:CB:4E:C2.

Using MAC Address Values to Query a Database

As in the previous scenarios, querying a database to retrieve a list of computer-specific packages is a three-step process:

Define a table to hold the computer-specific information.

Populate the table with the required computer-specific records.

Modify the CustomSettings.ini file to cause the database table to be queried.

In this scenario, the following table can be created in the BDDAdminDB database.

To use the MAC address of the computers to query a database:

1.

Create the table in the BDDAdminDB database to relate specific packages with the MAC address of the computers (as illustrated in Listing 86).

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.

use [BDDAdminDB]
go
 
if exists (select * from dbo.sysobjects where 
id = object_id(N'[dbo].[ComputerPackages]') and
OBJECTPROPERTY(id, N'IsUserTable') = 1)
drop table [dbo].[ComputerPackages]
go
 
CREATE TABLE [dbo].[ComputerPackages] (
    [MacAddress] [nvarchar] (50),
    [Packages] [nvarchar] (50)
)
go

Listing 86. SQL query to create the table

2.

Populate the table with data that associates the appropriate package with the appropriate MAC addresses (as illustrated in Listing 87).

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.

use [BDDAdminDB]
go

insert into ComputerPackages (MacAddress, Packages)
values('00:03:FF:CB:4E:C2', 'XXX0000B-Program name 11')
go 
insert into ComputerPackages (MacAddress, Packages)
values('00:03:FF:CB:4E:C2', 'XXX0000C-Program name 12')
go

Listing 87. SQL query to populate the table

3.

Configure the CustomSettings.ini file to query this database table by specifying the name of a section (ComputerQuery in the Priority list) that points to the database information (as illustrated in Listing 88).

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=MacAddress, DefaultGateway, ComputerQuery,
Default
...

Listing 88. Excerpt from Customsettings.ini that illustrates ComputerQuery section in the Priority list

4.

Create a ComputerQuery section to specify the name of a database section (as illustrated in Listing 89).

[ComputerQuery]
SQLDefault= DB_ComputerQuery

Listing 89. Excerpt from Customsettings.ini that illustrates ComputerQuery section with the name of a database section

5.

Create a database section to specify the database information (as illustrated in Listing 90).

[DB_ComputerQuery]
SQLServer=SERVER1
Database=BDDAdminDB
Table=ComputerPackages
Parameters=MacAddress
SQLShare=Logs

Listing 90. Excerpt from Customsettings.ini that illustrates the database section

In the example in Listing 90, the BDDAdminDB database on the computer running the SQL Server named SERVER1 will be queried. The database contains a table named ComputerPackages (created in step 1).  

When ZeroTouchInstallation.vbs runs, a SQL SELECT statement is automatically generated, and the value of the MacAddress custom key is passed as a parameter to the query (as shown in Listing 91).

SELECT * FROM ComputerPackages WHERE MacAddress IN (?,?,?)

Listing 91. Sample SQL query created automatically based on the database section

The actual value of the MacAddress custom key will be substituted for the corresponding “?” in Listing 91 (in this case, assuming there are three values—one for each of three network cards). This query returns a recordset with the rows entered in step 2. Each row specifies a package to be added to the list of packages to be installed during the State Restore Phase.

Scenario 5: Dynamic Computer-Specific Application Installation

Often when installing an operating system on an existing computer, it is desirable to install the same applications that were previously on the computer. This can be achieved using the ZTI rules engine querying two separate sources of information:

The SMS 2003 hardware inventory database, which contains one record for each application package, in this case Add/Remove Programs information, installed as of the last time SMS 2003 inventoried the computer.

A mapping table, describing which SMS 2003 package and program should be installed for each record (since the Add/Remove Programs records do not specify exactly which package installed the application, making it impossible to automatically select the package based on inventory alone).

To perform a dynamic computer-specific application installation:

1.

Create the table in the BDDAdminDB database to relate specific packages with applications listed in Add/Remove Programs (as illustrated in Listing 92).

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.

use [BDDAdminDB]
go
 
if exists (select * from dbo.sysobjects where
id = object_id(N'[dbo].[PackageMapping]') and
OBJECTPROPERTY(id, N'IsUserTable') = 1)
drop table [dbo].[PackageMapping]
go
 
CREATE TABLE [dbo].[PackageMapping] (
    [ARPName] [nvarchar] (50),
    [Packages] [nvarchar] (50)
)
go

Listing 92. SQL query to create the tables

2.

Populate the table with data that associates the appropriate package with the application listed in Add/Remove Programs (as illustrated in Listing 93).

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.

use [BDDAdminDB]
go
INSERT INTO [PackageMapping] (ARPName, Packages)
VALUES('Office8.0', 'XXX0000F-Install 
Office 2003 Professional')
go

Listing 93. SQL query to populate the table

In Listing 93, the inserted row relates any computer that has the “Office8.0” entry in Add/Remove Programs with the SMS Office 2003 Professional package. This means that Office 2003 Professional will be installed on any computer currently running Office 97 (Office 8.0). Similar entries can be added for any other packages; any Add/Remove Programs for which there is no entry will be ignored. (No package will be installed.)

3.

Create a stored procedure to simplify joining the information in the new table with the SMS inventory data (as illustrated in Listing 94).

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.

use [BDDAdminDB]
go

if exists (select * from dbo.sysobjects where
id = object_id(N'[dbo].[RetrievePackages]') and
OBJECTPROPERTY(id, N'IsProcedure') = 1)
drop procedure [dbo].[RetrievePackages]
go

CREATE  PROCEDURE [dbo].[RetrievePackages]
@MacAddress CHAR(17)
AS

SET NOCOUNT ON

/* Select and return all the appropriate records
based on current inventory */
SELECT * FROM PackageMapping
WHERE ARPName IN
(
  SELECT ProdID0 FROM 
SMS_SMS.dbo.v_GS_ADD_REMOVE_PROGRAMS a,
SMS_SMS.dbo.v_GS_NETWORK_ADAPTER n
  WHERE a.ResourceID = n.ResourceID AND
  MACAddress0 = @MacAddress
)
go

Listing 94. SQL query to create a stored procedure to simplify joining the information with SMS inventory data

The stored procedure in Listing 94 assumes the SMS central primary site database resides on the same computer running SQL Server as the BDDAdminDB database. If the SMS central primary site database resides on a different computer, the appropriate modifications need to be made to the stored procedure. In addition, the name of the SMS database (SMS_SMS in Listing 94) needs to be updated. You may also need to grant additional accounts read access to the v_GS_ADD_REMOVE_PROGRAMS view in the SMS database.

4.

Configure the CustomSettings.ini file to query this database table by specifying the name of a section (DynamicPackages in the Priority list) that points to the database information (as illustrated in Listing 95).

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=MacAddress, DefaultGateway, DynamicPackages,
Default
...

Listing 95. Excerpt from Customsettings.ini that illustrates DynamicPackages section in the Priority list

5.

Create a DynamicPackages section to specify the name of a database section (as illustrated in Listing 96).

[DynamicPackages]
SQLDefault= DB_DynamicPackages

Listing 96. Excerpt from Customsettings.ini that illustrates DynamicPackages section with the name of a database section

6.

Create a database section to specify the database information and query details (as illustrated in Listing 97).

 [DB_DynamicPackages]
SQLServer=SERVER1
Database=BDDAdminDB
StoredProcedure=RetrievePackages
Parameters=MacAddress
SQLShare=Logs

Listing 97. Excerpt from Customsettings.ini that illustrates the database section

In the example in Listing 97, the BDDAdminDB database on the computer running the SQL Server named SERVER1 will be queried. The database contains a stored procedure named RetrievePackages (created in step 3).  

When ZeroTouchInstallation.vbs runs, a SQL SELECT statement is automatically generated, and the value of the MakeModelQuery custom key is passed as a parameter to the query (as shown in Listing 98).

EXECUTE RetrievePackages ?

Listing 98. Sample SQL query created automatically based on the database section

The actual value of the MacAddress custom key will be substituted for the corresponding “?” in Listing 98. This query returns a recordset with the rows entered in step 2.

You cannot pass a variable number of arguments to a stored procedure. As a result, when a computer has more than one MAC address, you cannot pass all MAC addresses to the stored procedure. As an alternative, you could replace the stored procedure with a view that would allow you to query the view with a SELECT statement with an IN clause to pass all the MAC address values.

Based on the scenario presented here, if the current computer has the Office8.0 value inserted into the table (step 2), the one row will be returned (“XXX0000F-Install Office 2003 Profession”). This indicates that package “XXX0000F-Install Office 2003 Profession” will be installed by the Zero Touch Installation process during the State Restore Phase.

Scenario 6: User Self-Provisioned Computer-Specific Application Installation

In Scenario 4, the IT administrator populated the ComputerPackages table in advance of the operating system deployment to that computer. An alternative approach would be to set up a Zero Touch Provisioning (ZTP) service to allow users themselves to populate the tables.

The process for populating the tables is as follows:

1.

Users request applications to be installed on their computers.

2.

Approval is obtained for each application requested.

3.

A RunScript building block or equivalent business rule can be used to store a record on the ComputerPackages table.

You can retrieve the MAC address of the computer from the SMS database, as the provisioning request would only know the name of the computer.

You could create a similar service to allow the user to remove existing applications from the table.

In effect, this service would be the equivalent of the software delivery sample services included with ZTP except that instead of telling SMS to deliver the package to the computer now (by adding the computer to the appropriate collection for the package requested), it stores the request in a table where the Zero Touch Installation process can act on the request during the deployment process.

The actual implementation of these services is beyond the scope of this document.

Scenario 7: User-Customized Dynamic Computer-Specific Application Installation

In Scenario 6, services were described to allow users to add and remove application packages from the list to be installed on existing computers during the ZTI deployment process. These services can be combined with the process described in Scenario 5 to create a process that is initially based on the SMS inventory for the existing computers but allows for the users to make adjustments to the list. This allows the removal of applications that are no longer required and adding new applications that are not on the current computer.

In this scenario, the following steps occur:

1.

The SMS inventory is used to insert records into the ComputerPackages table based on the current SMS inventory and contents of the PackageMapping table. This would be a one-time process.

2.

The ZTP services described in Scenario 6 can be used to allow the user to make the needed modifications (subject to the same approvals described).

You can also combine this process with automated e-mails. Those emails notify users of the packages that will be installed on their computers if they do not take any action and provide a link to the Zero Touch Provisioning Web site that allows them to make changes. This helps ensure that users are aware of which applications they can expect to be on the new operating system after it is deployed.

The actual implementation of these services and processes is beyond the scope of this document.


Top of pageTop of pagePrevious22 of 25Next
**
In This Article
**