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,










Rename and set password for local admin using configmgr #rdproud

May 19, 2015



As you all know 🙂 -> Modification of local user password no longer possible using preference. When did this happen ?

You can find additional info here

Solution could be to reuse a sccm task sequence in order to rename the local admin and set the password.

We will use a task sequence variable as the password that should be applied.

We’ll create a powershell script.

# Change_passwords.ps1



# Author = Gino D’hoker


# Will be used in SCCM task sequence for renaming and setting password of local admin

# requires task sequence variable named vPassword with the required password



# Version 1.0

$computerName = $env:COMPUTERNAME

$computer = [ADSI] “WinNT://$computerName,Computer”

foreach ( $childObject in $computer.Children ) {

# Skip objects that are not users.

if ( $childObject.Class -ne “User” ) {



$type = “System.Security.Principal.SecurityIdentifier”


$childObjectSID = new-object $type($childObject.objectSid[0],0)


if ( $childObjectSID.Value.EndsWith(“-500”) ) {

“Local Administrator account name: $($childObject.Name[0])”

“Local Administrator account SID: $($childObjectSID.Value)”

$username = $($childObject.Name[0])




$tsenv = New-Object -COMObject Microsoft.SMS.TSEnvironment

$strPassword = $tsenv.Value(“vPassword”)

$user = [ADSI]”WinNT://./$username”




Now create a task sequence in order to deploy the task.

First create the required variable


Second run a posh script


Now deploy in on a scheduled base


And you have a worthy replacement of your preference !



Gino D

Interactive Task sequence

March 22, 2014


Task sequences in sccm provide a great mechanism for executing several steps, for example during complex application or operating system deployment.

One of the features, by design, is that task sequences allways run without interaction of the end-user, logic in most circumstances.

In order to show what we mean we have created a simple ts, running notepad.exe

If we run the ts this is what we see :

The TS is running but the user does not see the process notepad.exe

The notepad is running but the user can’t see it , it’s running in the system context without user interaction.

Now we create another ts using serviceui.exe, this executable is part of the MDT2010 installation. Just create a package with the executable.

Remember that you have a X86 and X64 edition and if you want to test, the process needs to be executed under system credentials ( so use psexec -s cmd.exe )

The interactive ts looks like this.

Run a custom command line :
serviceui.exe -process:TSProgressUI.exe %windir%\notepad.exe

Now if we run this task sequence :

Oh … great ! Now you can run your favorite powershell wrappers interactively in a task sequence.

serviceui.exe -process:TsProgressUI.exe %windir%\System32\WindowsPowerShell\v1.0\powershell.exe -executionpolicy Bypass -file .\MyFavoriteWrapper.ps1

Update ! There is a problem with running the serviceui.exe if there is no active user logged on. The executable returned an error in our environment at this moment. In order to workaround this issue you can use a WMI query as a condition for the serviceUI.exe task.

select * from win32_computersystem where username IS NOT NULL

Use this so the serviceui task will only run if there is a logged on user. If not the task will be skipped and the rest of the ts will run.

Enjoy …