7 min read

ConfigMgr - Using a Configuration baseline to check PackageID deployment state

ConfigMgr - Using a Configuration baseline to check PackageID deployment state

Sometimes you'd might want to create an collection based on the execution state of eg. an App, Pkg or Task Sequence deployment, maybe in order to tell if some pre-work is done and the device is ready for the next step.

In my case i worked this out because i had an task sequence which pre-cached drivers prior to having an Inplace upgrade task sequence deployed.

First i'd thought that i would create an Registry Key at the end of the task sequence that i could check and base an collection on, but, i thought that there must exist some information on the device that can tell me if it the TS has executed as expected, and as it turns out, there is.

Using this Powershell script below, as an Discovery Script, in an "Configuration Item" you can then create an compliant collection based on the state you wish to lookup.

  [string]$PackageID = "PS10000B"

#Get PackgeID execution history Registry key
$ExecutionHistoryKey = "HKLM:\SOFTWARE\Microsoft\SMS\Mobile Client\Software Distribution\Execution History\System\$PackageID"

#Determine SubKey to get Values
$ExecutionHistorySubKey = Get-ChildItem $ExecutionHistoryKey | Select -ExpandProperty Name
$PackageExecutionHistoryKey = $ExecutionhistorySubKey -Replace "HKEY_LOCAL_MACHINE","HKLM:"

#Get the execution state from "_State" value data 
$_State = (Get-ItemProperty $PackageExecutionHistoryKey)._State
Write-Output $_State

Breaking it down

The execution information can be found in the registry on each device, under:

"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Mobile Client\Software Distribution\Execution History\System"

Looking at this device in my lab, which has recently run the Win10 OSD TS.

"PS10000B"  - is the PackageID of my Task Sequence.

"8b9de860-73a3-11ec-8f4d-00155de5b10a" - is a generated GUID, which i'm not really sure if its based on anything, or if it's just generated in order to be uniqe, the problem with it, is that it can differ on each device, even if you look up the same PackgeID executionstate.

Another device which has run the same deployment, at the same time shows


And thats why don't go "directly" to this key using the powershell script, but instead just the PackgeID and let the script to the rest, so that you wont have to define anything else.

You can find the state of the deployment by looking at the "_State" value, as the image show, its "Success" ... (phew..)

This is also the value which Configuration Manger check to determine if a deployment has successfully run on an device or not, so that you can eg. deploy an required app or task sequence to a collection of devices, and be sure that it's only run once if it successfully deployed, if you don't configure it to run again and again.

To put it together into an Configuration Item / Configuration baseline which you can deploy

The Configuration Item

In the configuration manager console, go to

"\Assets and Compliance\Overview\Compliance Settings\Configuration Items"

- Right-click "Configuration Item" and select "Create Configuration item"

- Enter a name
- Add a description (so that not only you know what this is)
- Select type of CI, i usually just use "Windows desktops and Servers (custom)"

- Select Windows versions, i usually just let them all be selected.

On the next page, "Specify settings for this operating system", click "New", to bring up the "Create Setting" window.

Here is where we will specify the details and script to be used for the Compliance Item.

- Enter a name
- Enter a description
- Change "Setting type" -> "Script" and "Data type" -> "String"
- Click " Add Script"

- Copy the Powershell script from above, and paste it in to the "Edit Discover Script" window.
Remember to change the paramter "$PackageID" to the ID that you want to lookup

- Review and then click "OK"

- Back at the "Create Setting" windows, click the "Compliance Rules"-tab, we don't need no "Remedation Script" as this CI will just look and not do anything.

- Click "New"
- Enter name
- Enter description
- Make sure that "Rule Type" is "Value"
- The script will use "Write-Output" to output/return the data of the "_State" value and this is what we will use to identify if the device is compliant, or not, by entering "Success" in "For the following values" box as what the operator to check for
- Select you desired "noncompliance severity for reports", i usually set "information" or "none", but this really depends on what you are checking for and what severity it has.
- When you reviewed it all, click "OK"

- Back at "Create Setting" window, review the "General" tab again, and when your pleased with it all, click "OK".
- At the "Create Configuration item Wizard" we should now see our newly created setting. Click "Next"

- At "Compliance Rules", it should  show the rule we created earlier

- Review the Summary, then click "Next" and wait for it to create everything, then "Close"

The Configuration Baseline

Now it's time to create the Configuration Baseline, this is the baseline we deploy and what contains the newly created configuration item. An baseline can contain many different Items and together they will each check and determine if the device is compliant to the baseline, but for this we will only use one item.

We do this at almost the same place as the Configuration Item, the section is just under "Configuration Item" where we started the creation of the item.

As before
- Enter name
- Enter Description
- Add category
- Then click "Add" and select "Configuration Items"

- Select the "Configuration Item" that you want to include in the baseline
- Click "Add"
- Click "OK"

- Review the "Create Configuration Baseline" window, then click "OK"

Now the Configuration Baseline has been created! You want to deploy it to a collection of devices that has the PackageID deployed to it, and you want to check the compliance.

- Right-click the configuration baseline we just created, and select "Deploy"

- Leave "Remediate noncompliant rules when supported" unchecked
- You can check "Generate an alert" if you want and specify your preferences
- Click "Browse" and select the collection you want it deployed to
-Setup what schedule you want it to run on, how often you want it to evaluate
-Click "OK" to deploy it.

At an Device within the collection go to -> Control panel -> Configuration Manager -> Configurations tab, you should now (or soon) see the baseline, and its compliance. (if it havent shown up, go to "Actions" and run the "Machine policy retrieval & Evaluation cycle"

Now it will go to work and evaluate your devices according to the settings rule we created in the Configuration Item, but, as nice that is, we also want an "dynamic" collection based on compliant devices as well, so, with the configuration baseline selected in the console, we look at the bottom of the screen and select the "Deployments" tab

Here you can see the deployment that you created earlier, and some info about its compliance. Right-click the deployment and select "Create new collection" -> "Compliant"

This will bring up a new "Create Device Collection Wizard" windows, which is more or less pre-configured for your needs in this case.

- Click "Next"

You will find that its pre-setup with a query, this query will create an collection of devices which has reported compliant to your configuration baseline.

- Setup the evaluation schedule as you wish and the hit "next -> Review, "next" -> "Close"

Now if you go back to your Device Collections, to level, you should find yourself with an newly generated/created device collection, compiled of compliant devices.

And that's how you can use CI/CB's to check compliance of PackageID executionhistory!

Of course you can also create collections for non-compliant as well, eg. if you maybe want to automate some kind of remediation against those who fail in the deployment.


In order to run scripts with Configuration baselines, you need to be aware of your "Client Settings" deployed, as by default, as for the setting for running powershell scripts, this is set to "All Signed".  So, if you don't sign your scripts, this needs to be changed to "bypass".

Below show the "Default Client Setting" as an example: