Hardware Inventory after SCCM OSD Task Sequence

August 4, 2017


I like using a lot of custom collections based on data from Hardware Inventory: Operating System Version, Hardware Manufacturer, Hardware Model, etc.

However to make sure the properties are available the Hardware Inventory needs to run at least once, using this information you will be able to start the hardware inventory right after the OSD task sequence completes. We will be using the Task Sequence Variable SMSTSPostAction:

Somewhere in the task sequence add “Set Task Sequence Variable” step. Give it an appropriate name and fill in the information as seen in the screenshot below:

If you want to copy/paste, here’s the value: %windir%\System32\wbem\WMIC /namespace:\\root\ccm path sms_client CALL TriggerSchedule “{00000000-0000-0000-0000-000000000001}” /NOINTERACTIVE

When the task sequence completes, this action will occur.

When processing was succesfull you should see something like this in the dataldr.log (on the Configuration Manager site server)

Also locally on the computer where the task sequence was run, information can be found in the smsts.log and in the Inventoryprovider.log. Both logs located under C:\windows\ccm\logs

Hope this helps!


Best regards,






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: https://technet.microsoft.com/en-us/library/gg682023.aspx#BKMK_webserver2008_cm2012 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. sccm.customer.com. 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 https://sccm.customer.com:8531 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 (https://sccm.customer.com:8531). 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 http://sccm.customer.com. 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 (https://support.microsoft.com/en-us/kb/3005628) 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: http://blog.kloud.com.au/2014/08/12/powershell-detection-method-for-sccm-2012-application-compliance-management/

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 http://www.petervanderwoude.nl/post/deployment-of-configuration-baseline-failed-with-error-script-is-not-signed-in-configmgr-2012/. 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 http://www.david-obrien.net/2013/11/redistribute-failed-packages-configmgr-dps/ ) 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:  https://support.microsoft.com/en-us/kb/3020755
  • 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: https://support.microsoft.com/en-us/kb/3026739 

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,