Understanding BDD rule processing
To truly unleash the potential of BDD 2007 you must first understand the concept of rule processing.
A rule is used to define the variables that drive the entire imaging process. They are used to define properties such as the computer name, the local administrator password, or how user data should be saved during an image deployment.
There are a number of methods by which rules can be used to define variables. The following sections review these methods and how to best use them to customize BDD 2007.
Rule processing overview
Before you look at how to define rules it is important to understand how BDD processes rules.
The values that BDD obtains from rules are called “properties”. Properties are similar to environment variables, and once defined can be used by all other scripts. There are two types of properties:
1. Standard properties – Default properties defined within BDD
2. Custom properties – Properties you can define and assign as required
Note: Properties can be single valued or lists
BDD uses a gathering mechanism to determine the values of the properties. It does this by running the script “ZTIGather.wsf”. The script performs the following steps:
1. Determines the standard properties by referring to the standard properties definition file “ZTIGather.xml”.
2. Parses the “CustomSettings.ini” file and determines what custom properties it should use.
3. The “CustomSettings.ini” file is then processed to gather values for all of the properties required to deploy the operating system to the client.
The rest of the post will explain how the rule gathering process works for each of the assignment methods.
Assigning values through rules
Values can be assigned to properties through a number of different methods.
1. You can use hard-coded values, for example you could statically define the logging share (SLShare) to point at the share “LOGS” on “SERVER”:
SLShare=\\SERVER\LOGS
2. You can use variable substitution, for example you could statically define your logging share (SLShare) to point at the share “LOGS” on the SMS deployment point that you are currently connected to:
SLShare=\\%SMSDP%\Logs
3. Rules can call script functions, for example you may want to assign the ComputerName based on information gathered from the Asset Tag, functions are recognized as being enclosed in “#”’s:
ComputerName=#MyFunction(‘%AssetTag%’)#
(See the Userexit script section below for further information)
4. Rules can be selected based on the value of dynamic keys, the following example will return the computer name “Computer1” if the MAC Address is “00:01:AB:34:CD:02”
[Settings]
Priority=MACAddress,…
[00:01:AB:34:CD:02]
ComputerName=”Computer1”
5. You can assign values based on database lookups. (See the database section below for further information)
The structure of the CustomSettings.ini
It is important to understand the structure of the customsettings.ini file before we look at the rule processing options. The file is structured into sections. These sections give you the ability to customize how properties are gathered.
Settings section
This section is divided into two lines, priority and properties which define properties to be gathered and the rule processing order.
Priority
The rules are processed according to the section they belong. This line determines the order in which rules should be processed. Values are assigned to a property on a first come first served basis.
For example with the priority line below if a value is specified in the “Default” and “CSettings” sections the “CSettings” section will take precedence.
[Settings]
Priority=CSettings,Default
[Default]
OSInstall=Yes
Computername=Computer1
[CSettings]
Computername=MyComputer
Note: When the property is a list then each subsequent value will be added to the list.
Properties
BDD defines its standard properties via the ZTIGather.xml file, these properties do not have to be explicitly defined. In some scenarios the standard properties may not be adequate for your requirements. In these cases you can define custom properties. These can be used within all BDD scripts. Custom properties are defined on the “Properties” line.
For example if you wanted to create a new disk partitioning script that would configure partitions according to custom partition sizes, you would define these properties in this section as follows.
[Settings]
Properties=Partition1Size,Partition2Size
These properties would then be available to use in all BDD scripts.
Rule Sections
Once you have defined the rules processing order and any custom variables you can then assign values to these properties.
Default
Rules that you wish to be applied to all computers are generally specified in the default section. These values could be values such as the time zone or the BDD Deployment Root.
Custom Sections
There are three custom section types, dynamic, database or static.
Dynamic sections
Using variables such as make model or default gateway you can dynamically specify rules.
For example if you specified “Priority=Make” and the make is “Dell Corporation” BDD will look for a section called “Dell Corporation” and will then process any rules in that section.
[Settings]
Priority=Make,…
[Dell Corporation]
ComputerName=”DellComputer”
Database sections
This will perform a database lookup and return a single record. It will then assign the values of any column that matches a BDD property to that property.
BDD automatically recognizes database sections based on the information they contain. The information is used to connect to the DB and construct a select statement which retrieves values from the DB.
The following variables are used to declare DB connectivity requirements:
- SQLServer - This is the SQL Server hosting the DB you wish to connect to.
- Instance – The name of the instance of SQL Server to be used for querying property values.
- Port – The number of the port to connect to the SQL server, if required
- Netlib –The protocol to be used in communicating with the SQL Server. DBNMPNTW – Named pipes, DBMSSOCN –TCP/IP Sockets
- Database – The name of the database to be used for querying property values
- Table – The name of the table or view to be queried for property values.
- Parameters – The list of parameters to pass to the database query
- Order - The sorting order for the result set on a database query.
- SQLShare – Any share on the SQL server. You need to connect to a UNC path to get a secure named pipes connection as WinPE is not a member of the domain.
The best way to explain this section is by an example:
[MSettings]
SQLServer=SERVER1
Instance=SQLEXPRESS
Port=1433
Netlib=DBNMPNTW
Database=BDDAdminDB
Table=MachineDetails
Parameters=AssetTag
SQLShare=Logs
This will connect to the machine using the share \\SERVER1\Logs , then establish a connection the DB using the first four properties. Once this has been established it will then execute the following dynamically created select statement.
SELECT * FROM MachineDetails WHERE AssetTag = ‘%AssetTag%’
This will perform a search for records where the AssetTag value is equal to that of the current machine. It will return any column values that match the standard properties or any custom properties declared in the properties section.
So for example if the column ComputerName had a value “Desktop1” it would update the ComputerName property within BDD with that value.
It is also possible to retrieve information from databases other than the BDD database. To make these database lookups more flexible it is possible to translate the column names. Say for example you want to perform a query of a table where the column name of the table does not match the value of that we want to retrieve. In this case we can create mappings that translate these values.
For example if we want to connect to an asset management database to retrieve the computer name. Unfortunately records within this table do not have a “ComputerName” column. However it does have a “computer” column. To retrieve this value we simply add a line to the database section which will translate the column value:
Computername=Computer
Static sections
This is simply a section that is defined in the priority line that is not a dynamic or database section.
User exit scripts
In some situations the standard rule processing options may not be sufficient to meet your requirements. To extend the capabilities of rules, you can create user exit script(s).
User exit scripts are specified in the customsettings.ini file, and are processed before and after the CustomSettings.ini rules for each section are processed. User exit scripts have full access to the global variables.
The user exit script is essentially a function library. You create the functions you need to extend the rule processing functionality and then place them in a user exit script. You then reference the functions within the user exit script from the customsettings.ini file.
For example you may want to use the MAC Address with the colons stripped out as the computer name. A function can be used to “clean” MAC address. The result of the function can then be assigned to the computer name.
The following is an example of a eser exit script that would perform this function.
Function UserExit(sType, sWhen, sDetail, bSkip)
UserExit = Successfs
End Function
Function CleanMac(sMac)
Dim re
Set re = new RegExp
re.IgnoreCase = true
re.Global = true
re.Pattern = ":"
CleanMac = re.Replace(sMac, "")
End Function
This function is then referenced from the CustomSettings.ini as follows:
ComputerName=#CleanMac("%MacAddress%")#
UserExit=UserExit.vbs
Note: The user exit script must be placed in the same folder as the CustomSettings.ini file.