When trying to manage drivers and hardware specific application with BDD 2007, I have found that with some model types (HP D530) return many variations on the same model number. While these have slight variations to their model names they have virtually no difference to their driver set. This means that I end up wasting heaps of time duplicating database entries for each of these model types.
There is however a solution to this issue., here it is….
I use it to cater for all the HP machine types which have slight variations to their model names but virtually no difference to their driver set. These names are composed of a model name and then a code, for example “Hp D530 (XY12345)”. This solution simply truncates the names at the “(“.
To implement this solution perform the following steps:
Here are samples of the userexit script and CustomSettings.ini.
Customsettings.ini:
[Settings] Priority=SetModel, MMApplications, Default Properties= ModelAlias [SetModel] ModelAlias=#SetModelAlias()# Userexit=Userexit.vbs [MMApplications] SQLServer=AHSL99 Database=BDD2007AdminDB Netlib=DBNMPNTW SQLShare=logs Table=MakeModelApplications Parameters=Make, ModelAlias ModelAlias=Model Order=Sequence
[Settings]
Priority=SetModel, MMApplications, Default
Properties= ModelAlias
[SetModel]
ModelAlias=#SetModelAlias()#
Userexit=Userexit.vbs
[MMApplications]
SQLServer=AHSL99
Database=BDD2007AdminDB
Netlib=DBNMPNTW
SQLShare=logs
Table=MakeModelApplications
Parameters=Make, ModelAlias
ModelAlias=Model
Order=Sequence
User Exit script:
Function UserExit(sType, sWhen, sDetail, bSkip)
UserExit = Success
End Function
Function SetModelAlias()
if Instr(oEnvironment.Item("Model"), "(") <> 0 then
SetModelAlias = Left(oEnvironment.Item("Model"),Instr(oEnvironment.Item("Model"), "(") - 1)
oLogging.CreateEntry "USEREXIT - ModelAlias has been set to " & SetModelAlias, LogTypeInfo
else
SetModelAlias = oEnvironment.Item("Model")
oLogging.CreateEntry " USEREXIT - ModelAlias has not been changed." , LogTypeInfo
End if
I you would like further information regarding the functionality of database lookups and user exit scripts please refer to the following blog:
Http://blogs.technet.com/benhunter/archive/2007/03/17/understanding-bdd-rule-processing.aspx
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.
Many of my customers want to prompt information during a ZTI deployment. For example if for some reason the computer name is not available then they you like the user to be prompted for this information.
An elegant way to provide this information is by using the Lite Touch wizard within ZTI.
To do this you must copy the following files to your ZTI deployment point (\\<server>\zti$\BuildID):
You then need to create a cut down version of the "DeployWiz_Definition_ENU.xml" file and place it in the same folder. To prompt for the computer name only you would simply remove all panes accept the computer naming pane (Notepad.xml is a good tool for editing this file).
Next you need to add a task to the task sequence in the "New Computers only" folder within the "Preinstall" phase.
mshta.exe "%SCRIPTROOT%\Wizard.hta" /definition:DeployWiz_Definition_ENU.xml
This should hopefully get you started, you could also add other screens to gather further information if required.
This process can be extended to capture any information you need for the build process. For example the computer role or the MachineObjectOU.
This script can also be called from "bootstrap.ini" using a user exit script. This way you could gather information from users and then update the database with this information. This approach is also popular with customers who are not able to pre-populate the database with computer details.
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.
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
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.
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.
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)
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.
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.
[Settings] Priority=CSettings,Default [Default] OSInstall=Yes Computername=Computer1 [CSettings] Computername=MyComputer
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.
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
Properties=Partition1Size,Partition2Size
These properties would then be available to use in all BDD scripts.
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.
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:
The best way to explain this section is by an example:
[MSettings] SQLServer=SERVER1Instance=SQLEXPRESSPort=1433Netlib=DBNMPNTWDatabase=BDDAdminDBTable=MachineDetailsParameters=AssetTagSQLShare=Logs
[MSettings]
SQLServer=SERVER1Instance=SQLEXPRESSPort=1433Netlib=DBNMPNTWDatabase=BDDAdminDBTable=MachineDetailsParameters=AssetTagSQLShare=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.
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
UserExit = Successfs
Function CleanMac(sMac)
Dim re
Set re = new RegExp
re.IgnoreCase = true
re.Global = true
re.Pattern = ":"
CleanMac = re.Replace(sMac, "")
This function is then referenced from the CustomSettings.ini as follows:
ComputerName=#CleanMac("%MacAddress%")# UserExit=UserExit.vbs
ComputerName=#CleanMac("%MacAddress%")#
UserExit=UserExit.vbs
Note: The user exit script must be placed in the same folder as the CustomSettings.ini file.
When creating rules within BDD I find that it can take alot of time to tune them to provide the results that I am looking for. Each time I make a change I need to restart the entire build process to see if rules have the desired effect.
It is however possible to run BDD rule processing manually on a computer without needing to completely rebuild a machine. The following process is invaluable in configuring and troubleshooting rule processing within BDD.
The rules that are applied to a particular computer are gathered together using a script called “ZTIGather.vbs” in conjunction with “ZTIGather.xml”. These scripts can be run directly without the needing to launch the entire BDD process.
The steps below detail this process. These can be run when the computer is running the host operating system or WinPE.
Note: The process does not make any changes to the client computer.
I have found that creating a batch file with the following commands helps speed up this process.
rmdir c:\minint /s /q
cscript ZTIGather.wsf /debug:true