SCCM Collection Based on Baseline Compliance

select SMS_R_System.ResourceId,
SMS_R_System inner join SMS_G_System_CI_ComplianceState on SMS_G_System_CI_ComplianceState.ResourceID = SMS_R_System.ResourceId
SMS_G_System_CI_ComplianceState.ComplianceStateName = "<ComplianceState>"
and SMS_G_System_CI_ComplianceState.LocalizedDisplayName = "<BaselineName>"
and SMS_G_System_CI_ComplianceState.CI_UniqueID = "<CI Unique ID>"

<ComplianceState> can be ‘compliant’ or ‘non-compliant’

<BaselineName> is the displayname of the Configuration Baseline

<CI Unique ID> is the unique ID e.g. ‘Scope_xxxx’



Timing how long each group in a Task Sequence is Taking

I wanted a way to determine how long steps in an OS deployment TS were taking, until recently I thought the only window we had into this was running scripts as part of OSD or looking at Status Messages.

Then I found this view in the SCCM DB – v_TaskExecutionStatus

Like most views and tables in SCCM, each row has a ResourceID and contains information which looks very similar to the status messages. However, I have noticed that the Action Output is sometimes truncated (cut-off), and there are multiple rows for some steps.

Each row has fields called ActionName, GroupName, and ExecutionTime. Using these fields we should be able to build up a picture of how long each step and group is taking.

Initially, I started by querying all rows for a specific client which I knew had run a TS lately. This gave me all the information I needed, but if the client had run multiple task sequences it had entries for all the runs.

	v_TaskExecutionStatus AS ts
	inner join
	v_R_System AS s
		ON ts.ResourceID = s.ResourceID
	s.Netbios_Name0 = '#HOSTNAME#'
	ExecutionTime ASC

I then noticed that some steps would be listed incorrectly as Step 0, this was messing up the script I wrote to compare the time between one row and the next. I noticed each type of step was accompanied by a LastStatusMessageID field, using these IDs we can limit the query down to something more useful :

	v_TaskExecutionStatus AS ts
	inner join
	v_R_System AS s
		ON ts.ResourceID = s.ResourceID
	inner join
	v_AdvertisementInfo as a
		on ts.AdvertisementID = a.AdvertisementID
	s.Netbios_Name0 = '#HOSTNAME#'
	(LastStatusMessageID IN (11124,11127,11143)
	(LastStatusMessageID = 11140 AND step = 0))

	ExecutionTime ASC

If the hostname / client has only run 1 TS, this query will return data on when it started (11140 & Step 0) as well as when each group started and completed. Using this and a bit of powershell we can establish the duration that each group takes to run.

This is just a snippet of the script on GitHub :

$table = (invoke-sql -dataSource $sccmsqlserver -database $sccmsqldb -sqlCommand $query).Tables[0]

$hash = DataTableToHashTable -table $table

$groupoutput = @()
foreach ($line in $hash)
    $thisgroupname = $line.GroupName
    if($line.LastStatusMessageID -eq 11124)
        ## Start of Group
        $obj = [pscustomobject]@{
            GroupName = $line.GroupName
            ParentGroup = $null
            StartTime = $line.ExecutionTime
            EndTime = $null
            Duration = $null
            DurationSeconds = $null
        $groupoutput += $obj
    } elseif ($line.LastStatusMessageID -eq 11127)
        ## End of Group
        $findgroup = $groupoutput | ?{$_.GroupName -eq $line.GroupName}
        $findgroup.EndTime = $line.ExecutionTime

## Calculate Duration of Each Group
$groupoutput | % {$_.Duration = $_.EndTime - $_.StartTime}

## Calculate Duration in Seconds
$groupoutput | % {$_.DurationSeconds = $_.Duration.TotalSeconds}

If you output $groupoutput to a gridview you should see something like this :


This is just an initial script, which I will improving in the future. Groups are often nested in a TS and we need to be able to see and understand this in the output. I also want to extend the extend the script to show the duration of individual steps.

Cireson ConfigMgr Ticker WMI Permissions Fix

We encountered an issue with the Cireson ConfigMgr Ticker App recently where it stopped working on some clients. The log was reporting WMI permissions issues…

ConfigMgr Ticker WMI Log Errors
Errors in the log caused by WMI permission problems.

I had a quick look on the product forum and found someone with the same issue.

The problem is the Ticker App install adds a permission to the following WMI Class, which at times SCCM resets back to default.


You can check the permissions on this class using “wmimgmt.msc” -> right click on “WMI Control (local)” -> Properties -> Security Tab -> Expand tree to the class above -> Security. It should look like the screenshot below with the “HOSTNAME\Users” group having the “Enable Account” permission.

Screenshot of wmimgmt.msc permissions for Cireson ConfigMgr Ticker
Screenshot of wmimgmt.msc permissions for Cireson ConfigMgr Ticker

In certain circumstances, SCCM client repair and Windows 10 In-Place upgrade changes the permissions on this WMI class and it reverts back to default (the Users group is removed.) This breaks the Cireson Ticker App client.

Using a few blog posts I created a script to detect and remediate these permissions using a Configuration Manager Baseline.

Create a Configuration Item with a discovery script and remediation script

Discovery Script :
$namespace = "ROOT\ccm\Policy\Machine\RequestedConfig"
$computer = "localhost"
$compliance = "No"

Function Get-PermissionFromAccessMask($accessMask) {
    $WBEM_ENABLE            = 1
    $WBEM_FULL_WRITE_REP           = 4
    $WBEM_WRITE_PROVIDER          = 0x10
    $WBEM_REMOTE_ACCESS            = 0x20
    $READ_CONTROL = 0x20000
    $WRITE_DAC = 0x40000

    $WBEM_RIGHTS_STRINGS ="Enable","MethodExecute","FullWrite","PartialWrite","ProviderWrite","RemoteAccess","Subscribe","Publish","ReadSecurity","WriteSecurity"

    $permission = @()
    for ($i = 0; $i -lt $WBEM_RIGHTS_FLAGS.Length; $i++) {
        if (($accessMask -band $WBEM_RIGHTS_FLAGS[$i]) -gt 0) {
            $permission += $WBEM_RIGHTS_STRINGS[$i]


$invokeparams = @{Namespace=$namespace;Path="__systemsecurity=@";Name="GetSecurityDescriptor";ComputerName=$computer}

if ($credential -eq $null) {
    $credparams = @{}
} else {
    $credparams = @{Credential=$credential}

$output = Invoke-WmiMethod @invokeparams @credparams
if ($output.ReturnValue -ne 0) {
    throw "GetSecurityDescriptor failed: $($output.ReturnValue)"

$acl = $output.Descriptor
$usercoll = @()
foreach ($ace in $acl.DACL) {
    $user = New-Object System.Management.Automation.PSObject
    $user | Add-Member -MemberType NoteProperty -Name "Name" -Value "$($ace.Trustee.Domain)\$($ace.Trustee.Name)"
    $user | Add-Member -MemberType NoteProperty -Name "Permission" -Value (Get-PermissionFromAccessMask($ace.AccessMask))
    $user | Add-Member -MemberType NoteProperty -Name "Inherited" -Value (($ace.AceFlags -band $INHERITED_ACE_FLAG) -gt 0)
    if (($user.Name -eq "BUILTIN\Users") -and ($user.Permission -eq "Enable"))
        $compliance = "Yes"
Remediation Script :
$namespace = "ROOT\ccm\Policy\Machine\RequestedConfig"
$operation = "Add"
$account = "BUILTIN\Users"
$allowInherit = $false
$deny = $false
$computer = "localhost"
[string[]] $permissions = "Enable"

$ErrorActionPreference = "Stop"

Function Get-AccessMaskFromPermission($permissions) {
 $READ_CONTROL = 0x20000
 $WRITE_DAC = 0x40000

 $WBEM_RIGHTS_STRINGS ="Enable","MethodExecute","FullWrite","PartialWrite","ProviderWrite","RemoteAccess","ReadSecurity","WriteSecurity"

 $permissionTable = @{}

 for ($i = 0; $i -lt $WBEM_RIGHTS_FLAGS.Length; $i++) {

 $accessMask = 0

 foreach ($permission in $permissions)
 if (-not $permissionTable.ContainsKey($permission.ToLower())) {
 throw "Unknown permission: $permission`nValid permissions: $($permissionTable.Keys)"
 $accessMask += $permissionTable[$permission.ToLower()]

if ($PSBoundParameters.ContainsKey("Credential")) {
 $remoteparams = @{ComputerName=$computer;Credential=$credential}
} else {
 $remoteparams = @{}

$invokeparams = @{Namespace=$namespace;Path="__systemsecurity=@"} + $remoteParams

$output = Invoke-WmiMethod @invokeparams -Name GetSecurityDescriptor
if ($output.ReturnValue -ne 0) {
 throw "GetSecurityDescriptor failed: $($output.ReturnValue)"

$acl = $output.Descriptor

$computerName = (Get-WmiObject @remoteparams Win32_ComputerSystem).Name

if ($account.Contains('\')) {
 $domainaccount = $account.Split('\')
 $domain = $domainaccount[0]
 if (($domain -eq ".") -or ($domain -eq "BUILTIN")) {
 $domain = $computerName
 $accountname = $domainaccount[1]
} elseif ($account.Contains('@')) {
 $domainaccount = $account.Split('@')
 $domain = $domainaccount[1].Split('.')[0]
 $accountname = $domainaccount[0]
} else {
 $domain = $computerName
 $accountname = $account

$getparams = @{Class="Win32_Account";Filter="Domain='$domain' and Name='$accountname'"} + $remoteParams

$win32account = Get-WmiObject @getparams

if ($win32account -eq $null) {
 throw "Account was not found: $account"

switch ($operation) {
 "add" {
 if ($permissions -eq $null) {
 throw "-Permissions must be specified for an add operation"
 $accessMask = Get-AccessMaskFromPermission($permissions)

 $ace = (New-Object System.Management.ManagementClass("win32_Ace")).CreateInstance()
 $ace.AccessMask = $accessMask
 if ($allowInherit) {
 } else {
 $ace.AceFlags = 0

 $trustee = (New-Object System.Management.ManagementClass("win32_Trustee")).CreateInstance()
 $trustee.SidString = $win32account.Sid
 $ace.Trustee = $trustee


 if ($deny) {
 } else {

 $acl.DACL += $ace.psobject.immediateBaseObject

 "delete" {
 if ($permissions -ne $null) {
 throw "Permissions cannot be specified for a delete operation"

 [System.Management.ManagementBaseObject[]]$newDACL = @()
 foreach ($ace in $acl.DACL) {
 if ($ace.Trustee.SidString -ne $win32account.Sid) {
 $newDACL += $ace.psobject.immediateBaseObject

 $acl.DACL = $newDACL.psobject.immediateBaseObject

 default {
 throw "Unknown operation: $operation`nAllowed operations: add delete"

$setparams = @{Name="SetSecurityDescriptor";ArgumentList=$acl.psobject.immediateBaseObject} + $invokeParams

$output = Invoke-WmiMethod @setparams
if ($output.ReturnValue -ne 0) {
 throw "SetSecurityDescriptor failed: $($output.ReturnValue)"

Settings for the CI :


Remove annoying Cortana Audio after 1703 OSD

When you build a W10 1703 machine with SCCM OSD, you may notice that once its complete you hear an audile voice saying something like ‘OK I got connected let’s check for updates’.

You can disable this with a simple command line task sequence step  :

reg add "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\OOBE" /v DisableVoice /t REG_DWORD /d 1 /f

Filter SMSTS.logs to view only the main action steps (using cmtrace)

If you have a long Task Sequence with lots of steps and want to pinpoint when specific actions ran, you can filter the log using Entry Text contains “The action (” in cmtrace.

If some steps are missing you may need to merge in the rolled over logs which are named smsts-xxxxx.log

SMSTS Filter

SMBIOS Chassis Type Table

Table I use for reporting on ratio of Desktop / Laptops using Chassis Types. Derived from the DMTF SMBIOS Spec November 2016 :

Hex Value Dec Value Meaning Laptop-Desktop-Other
1 1 Other Other
2 2 Unknown Other
3 3 Desktop Desktop
4 4 Low Profile Desktop Desktop
5 5 Pizza Box Desktop
6 6 Mini Tower Desktop
7 7 Tower Desktop
8 8 Portable Laptop
9 9 Laptop Laptop
A 10 Notebook Laptop
B 11 Hand Held Laptop
C 12 Docking Station Other
D 13 All In One Desktop
E 14 Sub Notebook Laptop
F 15 Space-saving Desktop
10 16 Lunch Box Desktop
11 17 Main Server Chassis Other
12 18 Expansion Chassis Other
13 19 SubChassis Other
14 20 Bus Expansion Chassis Other
15 21 Peripheral Chassis Other
16 22 RAID Chassis Other
17 23 Rack Mount Chassis Other
18 24 Sealed-case PC Desktop
19 25 Multi-system chassis Other
1A 26 Compact PCI Other
1B 27 Advanced TCA Other
1C 28 Blade Other
1D 29 Blade Enclosure Other
1E 30 Tablet Laptop
1F 31 Convertible Laptop
20 32 Detachable Laptop
21 33 IoT Gateway Other
22 34 Embedded PC Desktop
23 35 Mini PC Desktop
24 36 Stick PC Desktop