SCCM – Deploy Unknown Computers with Assettag as computername

January 5, 2017


In a recent Windows 10 deployment project (with SCCM) a customer of mine wanted to use the Serialnumber as the computername within Active Directory. The customer is using Unknown Computers so they don’t the need to import them first. Also there was the need to identify if a computer was a desktop or laptop, this was needed to make sure the computer was joined in the right OU depending of that type and to make sure Bitlocker was only applied to laptop computers.  To provide this functionality I’ve created a vbs script:

Part 1: Set Computername variable

Set objOSD = CreateObject(“Microsoft.SMS.TSEnvironment”)

Set SWBemlocator = CreateObject(“WbemScripting.SWbemLocator”)
Set objWMIService = SWBemlocator.ConnectServer(strComputer,”root\CIMV2″,UserName,Password)
Set colItems = objWMIService.ExecQuery(“Select * from Win32_SystemEnclosure”,,48)

For Each objItem in colItems
strOSDComputername = objItem.SerialNumber

objOSD(“OSDComputerName”) = strOSDComputerName

The variable OSDComputerName is a default task sequence variable. Therefore no further actions need to be taken in the task sequence to make sure it is used to name the computer.

Part 2: Set Chassis variable

Set colChassis = objWMIService.ExecQuery(“Select * from Win32_SystemEnclosure”,,48)
For Each objChassis in colChassis
    For  Each strChassisType in objChassis.ChassisTypes
        Select Case strChassisType

            Case 3
                  StrType = “Desktop”
            Case 4
                   StrType = “Desktop”
            Case 6
                   StrType = “Desktop”
            Case 7
                  StrType = “Desktop”
            Case 8
                StrType = “Laptop”
            Case 9
                 StrType = “Laptop”
            Case 10
                  StrType = “Laptop”
            Case 11
                  StrType = “Laptop”
            Case 12
                   StrType = “Laptop”
            Case 14
                  StrType = “Laptop”
            Case 15
                  StrType = “Laptop”
            Case Else
    StrType = “unknown”
            End Select

objOSD(“Chassis”) = StrType

The variable “Chassis” can now be used like any other task sequence variable to make sure certain steps only run for a laptop or desktop.

Save the above codesnippets into a vbs file and create an SCCM package containing the script.

Afterwards add a “Run Command Line” step to the task sequence, provide the package details and the following command line: cscript.exe “…vbs”

That should do the trick.

Obviously this is one solution among others, there are many other ways to accomplish the same but this seemed the easiest to me.

A little remark: When reinstalling a computer with Bitlocker enabled, make sure the Run Command Line step is located after the partition disk step, otherwise the script will fail as WMI cannot be accessed from WinPE. I’ve experienced this the hard way.

Hope this helps!


Best regards,









SCCM 2007 + MDT 2010: Application in multiple roles

December 13, 2012


Today I had a little discussion about how MDT handles duplicate applications within roles. The environment consists of SCCM 2007 and MDT 2010 where MDT is used to store the configuration of client computers mainly to use MDT roles for software installation during task sequences.

The situation at that customer is that some applications can be member of multiple MDT roles which (I thought) would result in the fact that the application would also be installed multiple times. Let’s put this theory to the test.


–          3 roles:

  • Role 1: contains 23 applications
  • Role 2: contains 1 application
  • Role 3: contains 3 applications. All 3 applications are already member of Role 1 or Role 2

If MDT reacts to duplicate applications as I except I would see during the task sequence that all 27 applications will be installed. To see how many applications would be installed the ZTIGather.log can be checked on the client device during the execution of the task sequence.


When we open the logfile and check for the array containing all applications we expect to see PACKAGES001 up to PACKAGES027. But surprise was great when we only saw PACKAGES001 up to PACKAGES024. The difference is 3 which means that MDT has filtered out the 3 duplicate applications from role 3.

When checking the ZTIGather.log we can also see that the returned records count of the SQL query for all Packages in the Roles associated to the computer is 27.


This means that MDT detects that there are 27 applications in the 3 roles but at some point sees that there are a number of duplicates which are ignored while filling up the packages array.

Nothing can be found int the ZTIGather.log which states that the duplicates are ignored. That’s why I went deeper into investigating the ZTIGather.wsf script which contains all intelligence in processing the MDT data.

After some digging in the script I’ve found a function called QuerySQL which obviously will be used to get the right information from the SQL database and put it in the BDD.log. In that function there is a routine that processes the output of the SQL query.


While looking in more detail at the above code I noticed there is a line which has been put in comment stating:

“oLogging.CreateEntry “Value ” & oRS.Fields(cStr(sColumn)).Value & ” already found for ” & sElement, LogTypeInfo”

The statement ‘already found for’ made me suspicious so I’ve put this line of code out of comment and when I ran the script another time the ZTIGather.log showed the following output:


So basically the ZTIGather.wsf has the intelligence to detect duplicate applications, packages,… but doesn’t show this in the various logfiles, which is rather weird in my opinion.

I hope this gives you guys a better insight in how MDT handles applications.