Ben Hunter

Architect - Microsoft Enterprise Services - Redmond

Understanding BDD rule processing

Understanding BDD rule processing

  • Comments 21
  • Likes

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.

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
  • When trying to manage drivers and hardware specific application with BDD 2007, I have found that with

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

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

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

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

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

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

  • Hi

    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

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

    http://blogs.technet.com/benhunter/archive/2007/04/15/bdd-2007-ndash-tips-and-tricks-ndash-how-to-write-a-custom-script.aspx

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

    http://blogs.technet.com/benhunter/archive/2007/03/28/bdd-2007-tips-creating-model-aliases.aspx

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

    http://www.myitforum.com/myITWiki/BDD2007Config_ConfigureModels.ashx

    Thanks,

    Ben

  • 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

  • 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

  • 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

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

        [Settings]

        Properties=ReplaceComputerName

    This will then be available across all phases.

    How are you referencing the  variable in your script?

    Thanks,

    Ben

  • 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

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

    Thanks,

    Ben