The Cure For Your SSU FeverThe Cure For Your SSU Fever

The Cure For Your SSU Fever

The Cure For Your SSU Fever

I’m going to try to keep this one short, and sweet. My previous posts show that I’m not very good at that…

There are a lot of us who are responsible for patches in our environments. A pain point has come up centering around Servicing Stack Updates (SSU). These updates are commonly marked as a ‘prerequisite’ for the months Cumulative Update (CU), unless Microsoft decides it isn’t…. (see link above). This quickly becomes an issue depending on your enterprise’s patch strategy. If you simply deploy all your patches in one shot you’ll likely see that the SSU installs…. and that’s it. No followup scan for updates happens because the update does not require a reboot. Eventually your scan cycle will happen, and the CU appears and will install during your next maintenance window and all is right with the world.

The above checkbox is great! IF your machine reboots after the SSU. That is not the case, as has been demonstrated by a lot of relatively upset people. Thankfully, the SCCM product team is very receptive of feedback. There is a user voice requesting this issue to be addressed. Toss some votes at it!!!

In the mean time, some people are deploying the SSU in advance to ‘prepare’ machines for the CU. Some are using a configuration baseline to determine machines that are ready for the CU. Others take a hands off approach and are just letting everything roll out and it happens when it happens.


powershell.exe -command "&{$TimeFrame=(Get-Date).AddMinutes(-17);$Filter=@{LogName='System';StartTime=$TimeFrame;Id='19';ProviderName='Microsoft-Windows-WindowsUpdateClient';};$Events=Get-WinEvent -FilterHashtable $Filter;foreach($Event in $Events){switch -Regex ($Event.Message){'Servicing Stack Update'{foreach($Schedule in @('108','113')){$ScheduleString = [string]::Format('{{00000000-0000-0000-0000-000000000{0}}}',$Schedule);$invokeWmiMethodSplat=@{Name='TriggerSchedule';Namespace='root\ccm';Class='sms_client';ArgumentList=$ScheduleString;ErrorAction='Stop';};Invoke-WmiMethod @invokeWmiMethodSplat;}}}}}"

It’s beautiful isn’t it? Kidding… it is hard to read. But, the above line of code lets us create a scheduled task without having to invoke a script file, bonus! So, let’s show you the pretty version below, and then discuss implementation.

$TimeFrame = (Get-Date).AddMinutes(-17)
$Filter = @{
LogName = 'System'
StartTime = $TimeFrame
Id = '19'
ProviderName = 'Microsoft-Windows-WindowsUpdateClient'
$Events = Get-WinEvent -FilterHashtable $Filter
foreach ($Event in $Events) {
switch -Regex ($Event.Message) {
'Servicing Stack Update' {
foreach ($Schedule in @('108', '113')) {
$ScheduleString = [string]::Format('{{00000000-0000-0000-0000-000000000{0}}}', $Schedule)
$invokeWmiMethodSplat = @{
Name = 'TriggerSchedule'
Namespace = 'root\ccm'
Class = 'sms_client'
ArgumentList = $ScheduleString
ErrorAction = 'Stop'
Invoke-WmiMethod @invokeWmiMethodSplat

The script above (expanded from the command line) searches the event logs for event ID 19 (Installation Successful: Windows successfully installed the following update) in the Microsoft-Windows-WindowsUpdateClient provider. We use a timeframe of -17 minutes based on the settings of the scheduled task we will create. Once we find the events, we are going to check if the event is a “servicing stack” and if so trigger the software update scan and eval.

The schedule task we have implemented has a 1 minute delay set, and will run once every 5 minutes for 15 minutes. I initially was running one scan cycle after the SSU install, but I was not seeing consistent results in terms of the CU appearing. The intended result is below.

  1. MW Starts
  2. SSU Installs
  3. Event ID 19 created
  4. Scheduled Task triggered – 1 minute delay
  5. Scans initiated every 5 minutes for 15 minutes
  6. CU found now that pre-requisite is met
  7. CU Installs
  8. Computer reboots according to your settings and MW
  9. Problem solved!

The goal here is to trigger some software update scans after a SSU is installed. Our solution, until the product group and Microsoft solves this for us, is a scheduled task triggered by event creation. Below is a screenshot of the trigger. The action for this scheduled task will be the long ugly command above.

You can GIT the detection and remediation code here which we are using as a configuration baseline in SCCM to distribute this scheduled task. We simply expect a boolean true as the return value for compliance. A CAB File for the configuration item is also on github.

You could also create this task with a GPO as well.

That’s All Folks

Hopefully this helps some others that are struggling with SSU being a prerequisite.


Cody Mathis


I am a 'Senior Systems Engineer' who has an odd level of enthusiasm for SCCM, PowerShell, Automation, and SQL as well as many other things. I am always willing to take a bit of extra time (if it isn't an emergency) to figure out how to do something in PowerShell, shave off a few seconds of run time, make a process easily repeatable, or simply make it look pretty.

Add comment

5 × 5 =

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Follow us

Don't be shy, get in touch. We love meeting interesting people and making new friends.