Zero Touch Installation Deployment Feature Team Guide
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:
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. On This PageConfiguring the [Settings] SectionThe [Settings] section is the section that determines how the remainder of the Customsettings.ini file is processed. A typical [Settings] section is illustrated in Listing 36. 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, 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 36. [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:
The UserExit value is optional. Each of these sections is described in further detail later in this guide. PriorityThe Priority value determines the sequence and section of where to find configuration values. Each section will be searched in the order specified. Once all the required custom key values are found, the remaining sections are not used. The supported values for Priority are listed in Table 46. Table 46. Priority Key Values and their Description
Example:Priority=MacAddress, DefaultGateway, Default CustomKeysUserDataThis value defines the custom user data keys that must be populated for the ZTI process. The supported values for CustomKeysUserData are listed in Table 47. Table 47. CustomKeysUserData and Their Description
Example: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. CustomKeysUserData=UDShare, UDDir, UDProfiles, SLShare, OSInstall, Packages(*), Administrators(*), PowerUsers(*), DriverPath, ImageSize CustomKeysSysprepThis value defines the data keys that will be used to update the Sysprep.inf file, which controls how the machine is initially configured when the operating system first starts up. Each value specified should correspond to a value in the Sysprep.inf file. The [SysprepInfMapping] section must contain one entry for each of these values which specifies the section of the Sysprep.inf file that contains the specific value. A list of common values for CustomKeysSysprep are listed in Table 48. Any value can be supported; it just needs to be to defined on the CustomKeysSysprep line and in the [SysprepInfMapping] section. Table 48. CustomKeysSysprep and Their Description
Example: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. CustomKeysSysprep=ComputerName, TimeZone, JoinDomain, MachineObjectOU OSDVariableKeysThis value defines the data keys that are needed to automate or control the SMS 2003 OSD Feature Pack image installation process. The supported values for OSDVariableKeys are listed in Table 49. Table 49. OSDVariableKeys and Their Description
Example: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. OSDVariableKeys=OSDINSTALLSILENT, OSDINSTALLPACKAGE, OSDINSTALLPROGRAM, OSDNEWMACHINENAME ScanStateArgsThis value specifies the arguments that should be passed to the USMT Scanstate process. The ZTI script will determine which version of Scanstate to call (Scanstate.exe for Unicode systems, Scanstatea.exe for ANSI systems) and will insert the appropriate logging, progress, and state store parameters. If this value is not included in the settings file, the user state backup process will be skipped. Example: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. ScanStateArgs=/i:miguser.inf /i:migapp.inf /i:migsys.inf /i:sysfiles.inf /i:updateuser.inf /v:7 /x /s /f /o /c LoadStateArgsThis value specifies the arguments that should be passed to the USMT Loadstate process. The ZTI script will insert the appropriate logging, progress, and state store parameters. If this value is not included in the settings file, the user state restore process will be skipped. If the Loadstate process completes successfully, the user state information is deleted. In the event of a Loadstate failure (or non-zero return code), the local state store is moved to %WINDIR%\StateStore to prevent deletion and ensure that no user state information is lost. Example:LoadStateArgs=/v:7 /c UserExitThis value specifies the name of a script that should be called as part of the phase processing. This enables custom script functions to be called during the ZTI processing without modifying the main ZeroTouchInstallation.vbs script. It will be called twice:
A sample user exit function written in VBScript can be seen in Appendix F: Sample User Exit Function, later in this guide. 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. Example:UserExit=MyUserExit.vbs Configuring the [SysprepInfMapping] SectionThe [SysprepInfMapping] section, as illustrated in Listing 37,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 37. [SysprepInfMapping] section in Customsettings.ini In each case the syntax is as follows and described in Table 50: <CustomKeyName>=<SysprepInfSection> Table 50. [SysprepInfMapping] Values and Their Description
Configuring the [DefaultGateway] SectionThe [DefaultGateway] section, as illustrated in Listing 38, 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 38. [DefaultGateway] section in Customsettings.ini In each case the syntax is as follows and described in Table 51: <DefaultGatewayAddress>=<CustomSection> Table 51. [DefaultGateway] Values and Their Description
Customizing Deployment Based On the Chassis TypeYou can customize your deployment based on the chassis type of the computer (such as laptop, desktop, or server). The ZeroTouchInstallation.vbs script creates local variables that can be processed in the CustomSettings.ini file or in the AdminDB database. The local variables IsLaptop, IsDesktop, and IsServer indicate whether the computer is a laptop, desktop, or server, respectively. 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. The method for implementing these variables in the CustomSettings.ini file is as follows:
Configuring Custom SectionsCustom sections, as illustrated in listing, are used to specify the actual custom key values that should be used, to specify the database that should be used to retrieve the custom key values, or both. A typical custom section may look like this: [00:03:FF:CB:4E:C2] UDShare=\\SERVER\MigData SLShare=\\SERVER\Logs OSDINSTALLSILENT=1 OSDINSTALLPACKAGE=SMS00001 OSDINSTALLPROGRAM=ZTI Install OSDNEWMACHINENAME=WasWIN2000PRO ComputerName=WasWIN2000PRO TimeZone=004 Listing 40. [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:
In each case the syntax is as follows and described in Table 52: [<CustomSection>] SQLDefault=<SQLSection> UserExit=<UserExitScriptFile> Subsection=<CustomSectionWithVariables> <CustomKeyName>=<KeyValue> Table 52. CustomSection Values and their Description
Configuring Database SectionTo offer the greatest level of flexibility, the ZTI scripts can query SQL Server to obtain values for custom key settings specified in the [Settings] section. To query SQL Server, more information is needed such as the name of the server, the database on that server, the name of the table, and details of the table structure. All of these values can be specified in a database section. Multiple database sections can be specified, each with different SQL Server information, further enhancing the flexibility. One special database section, named “[SMS]” must be defined if packages are specified above; this special section is used to resolve SMS package IDs and program names to command lines. For OSD to install packages during the post-install phase, OSD needs the following information for each package:
The package ID and program name values are specified when populating the "Packages(*)" custom key. The ZeroTouchInstallation.vbs script can use those values to query the SMS database for the package installation command line. For the script to do this, the script reads the SMS database information from the [SMS] database section in the CustomSettings.ini file, as shown in Listing 41. Packages deployed in this manner are known as dynamic packages. If the [SMS] section is not present, it is not possible to install dynamic packages. [SMS] SQLServer=SMSSERVERNAME Database=SMS_XXX Table=v_Program Parameters=PackageID,ProgramName SQLShare=Logs Listing 41. Example of the [SMS] database section The [SMS] section needs to include the appropriate server name, database name, and share name (as SQLServer, Database, and SQLShare variables, respectively. The Table and Parameters values should always be the values illustrated in Listing 41. Note You need to ensure the appropriate permissions are granted to the SMS database and the v_Program view. (The Table and Parameters should not be changed.) In each case the syntax is as follows and described in Table 53: [<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: 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. 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: 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. 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> 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 53. DatabaseSection Values and Their Description
|
In This Article
|
![Configuring the [Settings] Section](/library/gallery/templates/MNP2.GenericArticle/../MNP2.Common/images/arrow_px_down.gif){kind=icon}
