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,









Configuration Manager 2012 R2 SP1 IBCM WSUS #RDPROUD

August 5, 2015

Hi all,

For some time I’ve been busy configuring Internet Based Client Management (IBCM) at a customer of mine. The infrastructure consists of System Center 2012 Configuration Manager R2 SP1 and has one primary site. One management server was already present for the intranet clients and I wanted to add the necessary means to support IBCM.

The most straightforward method was to add an additional management server which would be occupied with everything related to internet clients.

The general setup can be found here: and is quite straight forward.

Now the tricky part: How to make sure the infrastructure can be reached from the internet? First of all I needed a public IP adress which I could use for the CNAME eg. Then I needed to add the necessary components in the reverse proxy solution available (in this case: Citrix NetScaler). There I added a virtual server on port 443 configured using Protocol SSL_BRIDGE. This makes sure the connection gets passed through the NetScaler directly to the backend server.

When this was configured deploying software, requesting policies, etc. worked like a charm.

Additionally I wanted to make sure internet client could also use SCCM to check for updates (not directly to Windows Updates).

Therefore some extra configuration was needed:

  • Install WSUS on the new management server (sharing the same database as the WSUS that is already present in the Configuration Manager infrastructure.
  • Install SUP on the new management server (with SSL enabled + Internet only traffic allowed)
  • Configure IIS to use the SSL certificate (additional information here)
  • Make sure URL can be resolved on the internet ( therefore an additional virtual server can be added to the NetScaler: port 8531 protocol TCP)

Now when a computer is connected to the internet, the SCCM agent will detect that and will replace the existing WSUS URL (eg. http://sccminternal.customer.local:8530) by the one available from the internet ( One of the places to check this is in registry: HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate. This should point to the internet available FQDN. Also the Locationservices.log should show some information.




When the computer checks for updates it will connect to the published URL to see what updates are missing. Afterwards the deployment of updates will be checked to see what updates are “Actionable” (see UpdatesDeployment.log)


For the download itself the agent will use Windows Update. These downloads are done over HTTP and can be followed in the DataTransferServices.log on the computer.


The user experience is the same. Everything is listed properly in the Software Center


If Windows Update isn’t available then a fallback will happen to But because HTTP traffic isn’t redirected through the reverse proxy this will fail. Nevertheless I prefer the direct download from Windows Update as this minimizes bandwidth constraints in the customer infrastructure.


Hope this helps.


Best regards,



Configuration Manager 2012 R2 Powershell Application Detection Method #RDProud

July 2, 2015

Hi all,

This blog post describes how to enable .NET Framework 3.5 on Windows 8.1 after the computers already have been deployed.This can be quite annoying because the SXS source folder is needed when installing + this bug ( can also kick in.

The installation is done using an SCCM application containing an installation powershell script and powershell detection method. An easier alternative is using a package and task sequence to run the powershell script (no detection method needed here). Using the application has the advantage that it can be used as dependency and requirements can be added.

The installation script contains different phases

  • Downloading the source to a local folder in C:\windows\temp\NetFX3
    • This folder contains the installation powershell script and the SXS folder from the Windows 8.1 PRO ISO
  • Installing KB2966828 (to avoid the bug)
  • Enable .NET Framework using the downloaded SXS folder as source
  • Detect if .NET Framework was installed successfully
  • Delete temp folder C:\windows\temp\NetFX3

First of all a little thing about using Powershell as an Application Detection Method

The main purpose is to make sure the detection method exits with exit code = 0 (no errors during the script)  + Depending on the value of STDOUT (Write-Output) the detection method will return that the application is installed or not installed.

Script exit code Data read from STDOUT Data read from STDERR Script result Application detection state
0 Empty Empty Success Not installed
0 Not empty Empty Success Installed

Additional details:

Now we’ll try to apply this to the .NET Framework 3.5 feature we want to get installed here, the script I use is this:

$Framework = Get-windowsoptionalfeature -FeatureName NetFx3 -Online | Select-Object -ExpandProperty State

if ($Framework -eq “Disabled”)


  exit 0




  Write-Host “.NET Enabled”

  exit 0


This script is quite easy to understand and does the following

  • If .NET is not installed (disabled): exit script with exit code 0 –> Detection method sees this as “Application Not Installed”:
    • Exit code = 0
    • STDOUT (Write-Host) = Empty
  • If .NET is installed (enabled): exit script with exit code 0 –> Detection method sees this as “Application Installed”:
    • Exit code = 0
    • STDOUT (Write-Host) = Not Empty

Now let’s start adding this into SCCM: Create an Application and give it a suitable name. When creating a Deployment type give in the path to the source and the commandline. This is the commandline I used: “Powershell.exe -executionpolicy Bypass -file .\install.ps1” (without quotes)


When prompted for the detection method, select “Use a custom script to detect the presence of this deployment type and Click Edit, Select powershell and copy the detection method script in here


Finish creating the deployment type adding needed requirements (here I have added Operating System = Windows 8.1 x64)

After the application is created, update distribution points, deploy it to a test machine and see the result

Using the “Retrieve Machine Policy” on the test client we should rapidly see the new deployment, but this didn’t happen. I went to look into the ConfigMgr Client logs and found something interesting in the AppDiscovery.log

The Detection method couldn’t be run because it was not signed “CScriptHandler::DiscoverApp failed (0x87d00327).” I stumbled upon this post by someone who experienced the same error So I did what he highlighted: Enabling the Powershell Bypass option for the ConfigMgr Client.

A next test should result in the application being successfully added in the Software Center doesn’t it? Yes, it’s there but it says “Installed” while the .NET Framework wasn’t installed . Let’s go back to the AppDiscovery.log. Now no errors were listed but only warnings stating the script returned some error message (The application is detected as shown in the log “Detected App Deployment Type…”, but the application is not installed)


This one was tackled by disabling by unchecking “Run script as 32-bit process on 64-bit clients” on the detection method


After this little adjustment and another try everything looked good. The application was listed as “Available” in Software Center and the AppDiscovery.log showed the following: The App Deployment type was not detected.


Great! Hope this helps in helping you guys out!

Best regards,


Quick Tip ! Redistribute failed packages in ConfigMgr #RDProud

May 26, 2015


We were having issues with several packages not being distributed correctly in a large sccm 2012 environment. If we redsitribute the failed packages on a specific dp then the issue is resolved.

We’ll perform a root cause analysis next time, let’s focus on getting our content to the DP’s for now.

So I have created a powershell script ( based on ) that will take all the failed distributions on a specifc DP and refresh them.

Here it is ( replace XXX with your site code):


$failures = Get-WmiObject -Namespace root\sms\site_XXX -Query “SELECT packageid FROM SMS_PackageStatusDistPointsSummarizer WHERE (State = 3 AND SourceNALPath like ‘$fileserver’ )”

foreach ( $failure in $failures )


$id = $failure.PackageID

write-host $id

$DP = Get-WmiObject -Namespace root\sms\site_XXX -Query “SELECT * FROM SMS_DistributionPoint WHERE (ServerNALPath like ‘$fileserver’ and PackageID=’$id’ )”

write-host $DP




If you combine this with content validation on a schedule and the report ->

Software Distribution -> Content -> All active content distribution -> failed


You can export to csv and have a nice filtered excel that can be used as in order to select the correct DP.



Gino D

Quick Tip: Configuration Manager 2012 R2 + SQL 2014

May 6, 2015

Hi everyone,

A quick tip for all you guys wanting to install the Configuration Manager 2012 R2 site database on a server hosting SQL 2014.

When launching the installation and pointing to the SQL 2014 server, that version will be treated as unsupported and the installation won’t continue.

To get the installation to work you should do the following:

  • Download this Microsoft KB:
  • The KB contains 2 DLL files:
    • prereqcore.dll
    • setupcore.dll
  • Replace the 2 DLLs located in the Configuration Manager 2012 R2 installation source in the folder SMSSETUP\BIN\X64 with the 2 updated DLLs from the KB
  • Launch the installation from the modified installation source

The installation will now continue and you will be able to install the Configuration Manager 2012 R2 site database on SQL 2014.

Hope this helps!

Best regards,


Configuration Manager Client Push include Cumulative Update

April 29, 2015

Hi everyone,

I’ve always been wondering how it’s possible to easily include the latest Cumulative Updates with for example the Configuration Manager client push from the console.

A colleague of mine came up with an elegant solution, in this post I’ll describe shortly how the Cumulative Update can be included in the client push mechanism.

The latest Cumulative Update (CU4 for Configuration Manager 2012 R2) can be downloaded here: 

After installing the CU on the Primary Site Server there is an extra folder created under the installation folder on the Configuration Manager site server, this folder is called hotfix and it contains some automatically created folders visible in the below screenshot


In this post I’ll be focusing on the Client folder which contains 2 subfolders, one for the i386 patch and one for the x64 patch.

I’ll start with the x64 patch, copy the msp file from the directory Client\x64.

Browse to the source of the client package that is used for client push. By default this is the path \\[FQDN Primary Site Server]\SMS_[SiteCode]\Client. There again you have 2 folders (i386 en x64). In the x64 folder create a folder named “ClientPatch” and copy the msp file into this folder.

For the i386 msp file repeat the previous steps and copy the other msp file to the “ClientPatch” folder in the i386 folder

The structure of the client package should look similar like this:


After the necessary files and folders are added make sure you update the package on the distribution points so the next time a client push is done the most recent files are used. All content located in the “ClientPatch” subfolders will be automatically installed.

The ccmsetup.log on the client should show extra info about the update being installed. Also an extra log is created, in this case called: “configmgr2012ac-r2-kb3026739-x64.msp”


In the future, when new CU’s are released simply follow the same procedure and replace the “old” msp-files with the “new” ones.

Extra benefit: When using the same package in your task sequences, the CU will also be applied automatically, without extra parameters. So after the task sequence has completed the client will be on the latest CU without having to update afterwards.

Hope this helps!

Best regards,




Managing Windows 8 Apps in an Enterprise

May 10, 2014

With Windows 8, a new type of applications was introduced, Windows 8 APPS.
These APPS behave different than the Windows applications we all know.
Users can install any App from the Windows Store.
In an enterprise, we don’t want certain APPS to be installed.

This article discusses how we can manage these APPS.


Today I’m going to discuss how to:

  1. Manage Start Screen Layout
  2. Restrict Windows 8 Apps with AppLocker
  3. Deploy Windows 8 Apps with SCCM


  • Windows 8 Enterpise version
  • Microsoft Live Account


1. Manage Windows 8 Start Screen Layout

You can preconfigure a Start Screen for your users in Windows 8.

First you need to manually configure the Start Screen Layout:

Then you need to export the Start Menu with Powershell

You can manage Windows 8 Start Screen in 3 ways:

  • Group Policy:
  • Sysprep CopyProfile setting
    • The user can modify the Start Menu Layout, but it’s not possible to update 
  • Copy exported Start Menu Layout in SCCM Task Sequence:
    • The user can modify the Start Menu Layout, but it’s not possible to update


2. Restrict Windows 8 Apps with AppLocker

New with Windows 8 Group Policies is the ability to block or allow certain Apps with AppLocker.
This is configured by Group Policy.

In this example, we will create a white list of applications that are allowed.

On a Windows 8.1 computer with RSAT installed, open the Group Policy Console.
Create a new Group Policy and configure the following policy
Computer Configuration\Policies\Windows Settings\Security Settings\Application Control Policies\AppLocker\Pacakged App Rules –> Automatically Generate Rules…

Click Next

Click Select

Click Next

Click Review the Apps…

Select the default Apps you want to allow

Click Create

The Allow list has been created:


3. Deploy Windows 8 APPS with SCCM

There are 2 different ways to deploy Windows 8 Apps with SCCM:

  • Deploy inhouse developped APP
  • Deploy a Store APP 

Deploy inhouse developped APP
If you want to deploy an inhouse developped APP, you just need to import the APPX file into SCCM

Deploy a Store APP
If you want to deploy a Store APP (also called Deeplink), you need to import the APP from a computer that has this APP installed, and deploy it.

In this article, we’re going to DeepLink a Store APP.

First you need to manually install the APP on a Windows 8.1 reference client by using the Windows Store.
In this example, we will install the Lync APP.

Remark: You have to exclude the AppLocker policy on this computer

Import this new APP in the AppLocker Group Policy.
We need to add this APP to the Allow List.
In the AppLocker Group Policy, click “Create New Rule…”

Select the installed Lync APP

If you slide up the bar as in the screenshot , all versions of this APP are allowed
Click Next Next Create…

Lync has been added to the allow ist

Once the APP has been installed, import this APP in SCCM.

In the SCCM Console, go to Software Library –> Application Management –> Applications –> Create Application

Select “Windows app package (in the Windows Store) –> Click Browse

Enter the computer name where Lync is installed, click Connect.
Select the Microsoft Lync APP, click OK
Click Next

Click Next

You can change the name to a more readable name for the end user, click Next

Click Next

Click Close

Now the APP can be deployed to a usergroup.
If the deployment is set to available, the user can install it from the SCCM Application Catalog:

Click Yes

The Windows Store will automatically open to the correct APP, the user just needs to click Install