Understanding BDD rule processing

Article
03/17/2007

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

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use .

Comments

Anonymous
January 01, 2003
I have lost count of the number of times I have been asked to help some troubleshoot their database issues,
Anonymous
January 01, 2003
The comment has been removed
Anonymous
January 01, 2003
I have had recently had a couple of enquires from people having issues with setting multiple keyboard
Anonymous
January 01, 2003
When trying to manage drivers and hardware specific application with BDD 2007, I have found that with
Anonymous
January 01, 2003
BDD provides a scripting framework, by leveraging this framework you can write a custom script that can
Anonymous
January 01, 2003
The Settings within the MDT Database cover already a wide area of possibilities during a Deployment.
Anonymous
January 01, 2003
I am very happy with the progress of the deployment guys blog so far. Hopefully you all agree that we
Anonymous
January 01, 2003
Hi Jack, Thanks for this it looks great. Ben
Anonymous
January 01, 2003
Hi Rudolph, Are you wanting to assign static address to WinPE or withing Windows? If you want to do it within Windows then I suggest that you use MDT as it provides this functionality natively. Thanks, Ben
Anonymous
January 01, 2003
That would be great. I like t see other peoples ideas! Thanks, Ben
Anonymous
January 01, 2003
The comment has been removed
Anonymous
January 01, 2003
Start by creating an EventLog table on a SQL server (in this example - BDD). Then create a stored procedure in the database called WriteLogEntry which basically does a simple "INSERT INTO EventLog". The benefit of using a stored procedure is that you can let it stamp the log entries with the local time on the SQL server. When the SQL server is prepared you need to add the following code to ZTIUtility.vbs: 'Global constants in the header part of the file Public Const adOpenKeyset = 1 Public Const sSQLlogserver="MySQLserver",sLogDatabase="BDD",SQLUserID="User",SQLpwd="P@ssword!" Dim bWriteCentralLog bWriteCentralLog=True 'Find this function in the "class Logging" part Public Function CreateEntry(sLogMsg, iType) ...... 'Call to SQL log function inserted above 'oUtiltity.VerifyPathExists entry If bWriteCentralLog Then WriteCentralLog Component,sDate,sTime,iType,sLogMsg End If oUtility.VerifyPathExists LogPath ....... End Function 'New WriteCentralLog function Function WriteCentralLog(sSource,sDate,sTime,iType,sLogMsg) bWriteCentralLog=False 'To filter log to send to SQL you can use oEnvironment.Item("PHASE") 'or sSource content not ZTIgatherer... If iType>0 Then Dim sMACaddress,sSerialNumber,sIPaddress Dim dicMacAddresses Dim colBIOS Dim oWMI,oAdapters,oAdapter,oInstance If Not VarType(oEnvironment)=9 Then Set oWMI = GetObject("winmgmts:") Set oAdapters = oWMI.ExecQuery("select MacAddress,IPAddress from Win32_NetworkAdapterConfiguration where IPEnabled = 1") For Each oAdapter In oAdapters sMACaddress=oAdapter.MacAddress For Each sIPaddress in oAdapter.IPAddress If sIPaddress<>"0.0.0.0" And Left(sIPaddress,7)<>"169.254" And Len(sIPaddress)>0 Then Exit For End If Next 'Only use first adapter Exit For Next Set colBIOS = oWMI.InstancesOf("Win32_BIOS") For Each oInstance in colBIOS ' Get the serial number If Not IsNull(oInstance.SerialNumber) Then sSerialNumber = Trim(oInstance.SerialNumber) End if Next Else If oEnvironment.Exists("MacAddress") Then Set dicMacAddresses=oEnvronment.Item("MacAddress") For Each sMACaddress in dicMacAddresses.Keys 'Only use first adapter Exit For Next For Each sIPaddress in oEnvironment.ListItem("IPAddress").Keys Exit For Next sSerialNumber=oEnvironment.Item("SerialNumber") Else Set oWMI = GetObject("winmgmts:") Set oAdapters = oWMI.ExecQuery("select MacAddress,IPAddress from Win32_NetworkAdapterConfiguration where IPEnabled = 1") For Each oAdapter In oAdapters sMACaddress=oAdapter.MacAddress For Each sIPaddress in oAdapter.IPAddress If sIPaddress<>"0.0.0.0" And Left(sIPaddress,7)<>"169.254" And Len(sIPaddress)>0 Then Exit For End If Next 'Only use first adapter Exit For Next Set colBIOS = oWMI.InstancesOf("Win32_BIOS") For Each oInstance in colBIOS ' Get the serial number If Not IsNull(oInstance.SerialNumber) Then sSerialNumber = Trim(oInstance.SerialNumber) End if Next End If End If Dim sConnectString sConnectString="PROVIDER=SQLOLEDB;Data source=" & sSQLlogserver & _ ";Initial Catalog=" & sLogDataBase & ";User ID=" & SQLUserID & ";Password=" & SQLpwd Dim oDBconnect Dim oDBcommand Set oDBconnect = CreateObject("ADODB.Connection") On Error Resume Next oDBconnect.Open sConnectString If Err Then Dim oX For Each oX in oDBconnect.Errors wscript.echo "WriteCentralLog OLEDBERR: " & oX.Description Exit Function Next Exit Function End If On Error GoTo 0 Dim sQuery sQuery="EXECUTE WriteLogEntry '" & sSource & "'," & _ "'" & sSerialNumber & "'," & _ "'" & sMACaddress & "'," & _ "'" & sIPaddress & "'," & _ "'" & sDate & "'," & _ "'" & sTime & "'," & _ "'" & iType & "'," & _ "'" & Replace(sLogMsg,"'","''") & "'" Dim oRecordSet 'MsgBox sQuery On Error Resume Next Set oRecordSet=CreateObject("ADODB.Recordset") oRecordSet.Open sQuery,oDBconnect,adOpenKeySet If Err Then wscript.echo "WriteCentralLog ERR: 0x" & Hex(Err.Number) & vbCRLF & Err.Description wscript.echo "Command: " & sQuery Exit Function End If On Error GoTo 0 End If bWriteCentralLog=True End Function GOOD LUCK!! /Jack
Anonymous
January 01, 2003
When performing a refresh based deployment using Zero Touch BDD will retain the computers current SMS
Anonymous
January 01, 2003
The comment has been removed
Anonymous
January 01, 2003
Thanks Ben! The confirmation that properties should be available across the phases help me look at the problem from another angle. I discovered that the Variables.dat file is just one property store, another file - OSDenv.ini contains more properties. The loss of my value in Variables.dat threw me off. I have addded a feature to the logging class in ZTIutility to write logg entries to a SQL table. I could post it if you want it. Thanks again! Jack
Anonymous
January 01, 2003
Ben, I have a problem using custom properties in BDD 2007. I have designed a solution for replacing computers during the installation. The idea was to let the property "ReplaceComputerName" be populated by a user dialog during the first installation phase, and then use this property in the StateRestore phase to remove the old computer and inherit its AD memberships. But the property value doesn't seem to survive to the next phase. I can see that the value for the property is saved to the Variables.dat file on the client, but ZTIutility.vbs seemes to ignore reading the value back to the oEnvironment dictionary. Is it necessary to populate the CustomSettings.ini variables in each phase by the BDD rule processing? Thanks for any advice! Jack
Anonymous
January 01, 2003
When using BDD to deploy and OS one of the first things it does is detect information about the hardware
Anonymous
November 19, 2007
The comment has been removed
Anonymous
December 07, 2007
Ben, Thanks for the great blog and post. I'm having difficulty finding out how to assign a static IP address during the deployment process. I'm open to a user prompt in the wizard or a web service/or db call but I don't know how to integrate into the bdd process. Any advice would be appreciated. Thanks
Anonymous
February 04, 2008
Hi,Jack Can you give me more details about your script and store procedure?
Anonymous
March 01, 2008
Ben, My company defined our Model Aliases according to the post at: http://blogs.technet.com/benhunter/archive/2007/03/28/bdd-2007-tips-creating-model-aliases.aspx We also want to selectively use Computer Roles that define the RoleApplications result set in [RApps] which override the MakeModelApplications result set in [MMApps] with the following priority settings: Priority=SetModel, CRoles, RSettings, RApps, MMSettings, MMApps, Default Properties=ModelAlias Unfortunately this does not appear to work when both the serial number matches in the Roles database, and the ModelAlias matches the Make and Model database. Instead, the combined result sets of all the applications in both RoleApplications and MakeModelApplications for the corresponding Role and ModelAlias for the computer are selected. Can this be forced to use just one of these result sets, as defined in the priority setting?

Share via