In the past, we detected the hardware type of a computer with WMI queries in a Task Sequence step. When you deploy multiple Operating Systems or Task Sequences, you have to manage the WMI Query on many locations. Andreas Kuperschmied and Roman Andres have created an abstraction layer for this problem. Now we only have to maintain one xml in which we define how to detect the manufacturer and model for each type. According to these finding we can define task sequence variables per manufacturer and model. These variables can be dynamically extended in the XML file. The whole script can be downloaded here.
XML Config File
<?xml version = "1.0" encoding = "ISO-8859-1"?> <mappings> <manufacturers> <mapping searchString="Dell Inc."> <HwManufacturer>Dell</HwManufacturer> </mapping> </manufacturers> <models> <mapping searchString="Latitude D620"> <HwModel>D620</HwModel> <OSEngineeredWinXP>True</OSEngineeredWinXP> <OSEngineeredWin7>False</OSEngineeredWin7> <ComputerType>NB</ComputerType> </mapping> <mapping searchString="Latitude E6400"> <HwModel>E6400</HwModel> <OSEngineeredWinXP>True</OSEngineeredWinXP> <OSEngineeredWin7>True</OSEngineeredWin7> <ComputerType>NB</ComputerType> </mapping> </models> </mappings>
The searchString attribute in the mapping elements defines the string for which the script searches in the Win32_ComputerSystem WMI Class (model respectively manufacturer property).For Example, when the script detected a Dell D620 with the above Config file, the script defines the following variables:
- HwManufacturer: Dell
- HwModel: D620
- OSEngineeredWinXP: True
- OSEngineeredWin7: False
- ComputerType: NB
This could be used to block a Windows 7 Installation on devices where it’s not supported.
It is also possible to define variables which could be used for Software Installation or the OSDAutoApplyDriverCategoryList for an Auto Apply Drivers Task Sequence Action:
With these Variables it’s possible to reduce the Task Sequence Steps for Driver Management to two steps. One for Applications or Software Packages and one Auto Apply Driver Step, but still with the advantages of exactly specified Drivers, like with the Install Driver Package Step.
For troubleshooting purposes it’s also possible to run the script from a share with first connecting a network folder (With Modify Permission) and then running the script from the networking share. This enables the script to write a logfile on the network share with all important information. With this approach you can also run the script during WinPE.
Latest posts by Thomas Kurth (see all)
- Office 365 DLP – Add detection of the swiss social id to detect personal data - February 8, 2019
- Take action: Default permissions in the Microsoft Compliance Manager gives all users full access - February 2, 2019
- Test connectivity to various Azure and O365 services - January 9, 2019