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”:


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:


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:


(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”


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.


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.








Note: When the property is a list then each subsequent value will be added to the list.


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.



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.


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.

[Dell Corporation]

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:



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:


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:



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 (21)
  1. Anonymous says:

    I have lost count of the number of times I have been asked to help some troubleshoot their database issues,

  2. Anonymous says:

    I am often asked how I install and configure BDD 2007. So I thought now was a good time detail at a high

  3. Anonymous says:

    I have had recently had a couple of enquires from people having issues with setting multiple keyboard

  4. Anonymous says:

    When trying to manage drivers and hardware specific application with BDD 2007, I have found that with

  5. Anonymous says:

    BDD provides a scripting framework, by leveraging this framework you can write a custom script that can

  6. Anonymous says:

    The Settings within the MDT Database cover already a wide area of possibilities during a Deployment.

  7. Anonymous says:

    I am very happy with the progress of the deployment guys blog so far. Hopefully you all agree that we

  8. Ben Hunter says:

    Hi Jack,

    Thanks for this it looks great.


  9. Ben Hunter says:

    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.



  10. Ben Hunter says:

    That would be great. I like t see other peoples ideas!



  11. Ben Hunter says:

    Hi Chris,

    BDD will gather the WMI value for you automatically. You can then use these values within scripts or in the customsettings.ini file. You can also use the database to dynamically install applications based on the hardware type.

    For information on how to write a customscript have a look at the following post:


    For information on how to create and use model aliases have a look at the following post:


    You will also find lots of good information on myitforum.com:




  12. Ghost says:

    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


    ‘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)


               ‘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


                           For Each sIPaddress in oAdapter.IPAddress

                               If sIPaddress<>"" And Left(sIPaddress,7)<>"169.254" And Len(sIPaddress)>0 Then

                                   Exit For

                               End If


                           ‘Only use first adapter        

                           Exit For


                       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



                       If oEnvironment.Exists("MacAddress") Then

                           Set dicMacAddresses=oEnvronment.Item("MacAddress")

                           For Each sMACaddress in dicMacAddresses.Keys

                               ‘Only use first adapter

                               Exit For


                           For Each sIPaddress in oEnvironment.ListItem("IPAddress").Keys

                               Exit For




                           Set oWMI = GetObject("winmgmts:")

                           Set oAdapters = oWMI.ExecQuery("select MacAddress,IPAddress from Win32_NetworkAdapterConfiguration where IPEnabled = 1")

                           For Each oAdapter In oAdapters


                               For Each sIPaddress in oAdapter.IPAddress

                                   If sIPaddress<>"" And Left(sIPaddress,7)<>"169.254" And Len(sIPaddress)>0 Then

                                       Exit For

                                   End If


                               ‘Only use first adapter

                               Exit For


                           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          


                       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


                       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


           End Function



  13. Anonymous says:

    When performing a refresh based deployment using Zero Touch BDD will retain the computers current SMS

  14. Ben Hunter says:

    Hi Jack,

    If you are going to use a non-standard variable then you need to specify it using the properties line in the customsettings.ini file, for example:



    This will then be available across all phases.

    How are you referencing the  variable in your script?



  15. Ghost says:

    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!


  16. Ghost says:


    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!


  17. Anonymous says:

    When using BDD to deploy and OS one of the first things it does is detect information about the hardware

  18. Chris says:


    I have setup a build which has several applications installing through the task sequence method, and id believe it is possible to create rules so that certain applications can be installed or not depending on the make and model of the machine, when interogated though WMI.

    Ive seen several blogs on how to do this, but really cant see how the wmi query is put together within the "options" of the task.

    What i am having trouble with is working out how to do a WQL query (as im not a programmer), assign it or them to variables and use them to determine whether or not to install specific applications.

    So far i have this tried this from some code i found in a vbscript to get model info, not my code as i cant program.

    – WQL Query=p_model = trim(p_WMIObj.model)

    – If ALL Condiotns are true

      – Task sequence variable p_model equals 2374PG2

    Ive run the TS.xml for an applications only build as described elsewhere and nothing happens. What should happen is a hardware specific app installation.

    Please Help

    Im sure this is possible, and would really like some guidance on this.

    Many Thanks

    Chris Snell

  19. Rudolph says:


    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.


  20. amoschb says:


    Can you give me more details about your script and store procedure?

  21. Alan.1 says:


    My company defined our Model Aliases according to the post at:


    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


    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?

Comments are closed.

Skip to main content