BDD 2007 Tips - Creating Model Aliases

 

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:

1. Create aliases for Hardware types in the “Make and Model” section of the Database. In this example I truncate the Model type at the “(“ in the model name. (eg. "HP D530" rather than “Hp D530 (XY12345)")
2. Update the rules in the following manner
   • Add the custom variable “ModelAlias” to the “[settings section]”
   • Create a new “SetModel” section.
   • Add the “SetModel” section to the Priority settings in the “Settings” section
   • Add a line to the “ModelAlias” section to refer to a user exit script that will truncate the model name at the “(“
   • Create a “MMApplications” DB lookup where the “Model” column is matched with the “ModelAlias”
3. Create a “User Exit” script and place it in the same directory as the CustomSettings.ini file to truncate the Model name.

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

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

          End Function

I you would like further information regarding the functionality of database lookups and user exit scripts please refer to the following blog:

https://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 .

Comments

• Anonymous
  January 01, 2003
  Hi Alan, I use exactly the method you describe, atcept I call it generic rather than unknown :). The reason I assign the value back to the model column is because BDD will perform a lookup on the model column using the value from ModelAlias. This is the key to how this process works. Thanks, Ben

• Anonymous
  January 01, 2003
  The property oEnvironment.Item("Make") is used to identify this information. What you might want to do is update your function to return two aliases, "ModelAlias" and "MakeAlias". You would then need to update your customsettings.ini file to use these aliases. To do this simply following the usage pattern in my example. Thanks, Ben

• Anonymous
  January 01, 2003
  Yes that is the exact reason why I created this script. Thanks, Ben

• Anonymous
  January 01, 2003
  Hi Kim, This is just an example. I tend to use both MakeModelSettings and MakeModelApplications. I use MakeModelSettings to set things like display resolutions for a laptop and then I use MakeModelApplications to install applications that are specific to a to a particular model type, for example fingerprint reader drivers. This approach is also very useful for those annoying drivers that must be installed via an EXE or MSI rather than via PnP.  I find this approach very common, in fact I use MakeModelApplications a lot more than MakeModelSettings. I use this approach equally for both ZTI and LTI. Thanks, Ben

• Anonymous
  January 01, 2003
  Hi Alan, My previous answer was a little cryptic! This is not assigning the modelalias value to model. This is used in the construction of the database lookup. So what it is really saying is - look for records where the model column has the same value as modelalias. Thanks, Ben

• Anonymous
  July 09, 2007
  Great blog post, but using the makemodelapplications view is not the best choice IMHO. These view only has your models listed if each model also has an application linked to it. Which is pretty uncommon to the zti process. Makemodelsettings on the other hand, makes this more useful for both lti and zti deployments.

• Anonymous
  September 07, 2007
  I got a question regarding this. HP can be really annoying with those makes :S. For example I got a nc6320 laptop wich reads out as a "nc6340". The other 6320 says "HP Compaq nc6320 (EY395ET#ABH)". Seems like every HP is different. Only solution is to make a huge SetModelAlias script which filters all these out I presume?

• Anonymous
  September 07, 2007
  Hewlett-Packard can be so annoying :D thnx tho I will see what I can do. Worst part is figuring out all the model names of all the pc's.

• Anonymous
  September 13, 2007
  Is there something similar to oEnvironment.Item("Model") for the system manufacturer such as oEnvironment.Item("Make") ro oEnvironment.Item("Manufacturer")? I would like to create something similar to this: Function SetModelAlias() Select Case oEnvironment.Item("Make") Case "IBM", "Lenovo" SetModelAlias = Left(oEnvironment.Item("Model"),4) oLogging.CreateEntry "USEREXIT - ModelAlias has been set to " & SetModelAlias, LogTypeInfo Case "Matsushita Electric Industrial Co.,Ltd."                 SetModelAlias = "Toughbook" oLogging.CreateEntry "USEREXIT - ModelAlias has been set to " & SetModelAlias, LogTypeInfo Case Else SetModelAlias = oEnvironment.Item("Model") oLogging.CreateEntry " USEREXIT - ModelAlias has not been changed." , LogTypeInfo End Select End Function

• Anonymous
  March 02, 2008
  Ben, Using this method there appears to be a tendency of BDD 2007 to fail over in various ZTI scripts if the Model environment doesn't get recognized in the Userexit.vbs script. Instead, if we make the ELSE branch of SetModelAlias() define ModelAlias as an alternate model called "Unknown", this can be defined in the Make and Model database (with at least one MakeModelApplication defined for that model, to force the result set). Otherwise the ELSE branch could be used to halt Userexit.vbs entirely, i.e. with a popup method in that script which reports the match filed. What is the reason for re-assigning the value ModelAlias back to the Model column after the database lookup?

• Anonymous
  March 02, 2008
  Ben, I'm still confused as to what affect the "ModelAlias=Model" directive has on the database lookup. If it's nothing more than a variable assignment, then we're simply passing the unmodified Model environment straight back into ModelAlias, which was truncated earlier by Userexit.vbs in [SetModel].  Doing so would be contraindicated since of course we actually want the custom Model name that's been added as the truncated version in our Make and Model database. For this to work it means that ModelAlias was already consumed by the database lookup before this gets re-assigned in [MMSettings] to the value of Model which, for all appearances, would preclude the lookup in [MMApps] defined in the next lower priority. This means the truncated ModelAlias value is capable of surviving the MakeModelSettings lookup so it matches the MakeModelApplications table.  Could you describe how this happens?

• Anonymous
  March 03, 2008
  The comment has been removed