Jump to content
Teeevv

Monitoring Windows Updates Health

Recommended Posts

As we all know managing windows updates can be a pain sometimes, and thanks to the report created by Gavsto (https://www.gavsto.com/free-report-get-a-second-opinion-on-your-patching/) we've discovered the patch compliance reporting within Automate can be very misleading. Using this report I started to dig into the anomalies and discovered two problems

  1. The report showed the last Cumulative Update and when the installation was attempted, whether it was successful or not
  2. I didn't want to rely on a manual task to review a report, I wanted automate to raise a ticket when a machine fell behind by 35 days so we can go fix the issue

Based on these issues, I decided the best way to proceed was to expand upon Gavsto's idea. Since we're trying to verify the actual current patch level of every computer, I didn't want to rely on the information already existing in Automate in case it was incorrect. I figured the most accurate source of the current patch level would be the computer itself. I created two new extra data fields and populated them with a small powershell script. The logic for the powershell script followed the same principal as the report, list out the latest cumulative update's that were installed but with the added condition of making sure the update was successful. The EDF's I created and the powershell scripts to populate them were

  • Last Successful Patch - The Title of the patch that was last installed
$Result = @();
$Session = New-Object -ComObject Microsoft.Update.Session;
$Searcher = $Session.CreateUpdateSearcher();
$HistoryCount = $Searcher.GetTotalHistoryCount();
$Result = (
	$Searcher.QueryHistory(0,$HistoryCount) | Where-Object {
		(
			$_.ResultCode -eq 2 -or 
			$_.ResultCode -eq 3
		) -and (
			$_.Title -like '*Security Monthly Quality*' -or 
			$_.Title -like '*Servicing Stack Update*' -or 
			$_.Title -like '*Cumulative Security Update*' -or 
			$_.Title -like '*Cumulative Update For*' -or 
			$_.Title -like '*Feature update to*'
		) -and (
			$_.Title -notlike '*Cumulative Security Update For Internet Explorer*' -and 
			$_.Title -notlike '*Cumulative Security Update for ActiveX*' -and 
			$_.Title -notlike '*Cumulative Update for .NET Framework*'
		)
	} | Sort-Object Date);
If ($Result.count -gt 0) {
	return ($Result[-1]).Title 
} Else { 
	Return "No CU Patching Information Available" 
};
  • Last Successful Patch Timestamp - The date and time this patch was installed, in a YYYYMMDD-HHMMSS format
$Result = @(); 
$Session = New-Object -ComObject Microsoft.Update.Session; 
$Searcher = $Session.CreateUpdateSearcher(); 
$HistoryCount = $Searcher.GetTotalHistoryCount(); 
$Result = (
	$Searcher.QueryHistory(0,$HistoryCount) | Where-Object {
		(
			$_.ResultCode -eq 2 -or 
			$_.ResultCode -eq 3
		) -and (
			$_.Title -like '*Security Monthly Quality*' -or 
			$_.Title -like '*Servicing Stack Update*' -or 
			$_.Title -like '*Cumulative Security Update*' -or 
			$_.Title -like '*Cumulative Update For*' -or 
			$_.Title -like '*Feature update to*'
		) -and (
			$_.Title -notlike '*Cumulative Security Update For Internet Explorer*' -and 
			$_.Title -notlike '*Cumulative Security Update for ActiveX*' -and 
			$_.Title -notlike '*Cumulative Update for .NET Framework*'
		)
	} | Sort-Object Date); 
If ($Result.count -gt 0) { 
	return ($Result[-1]).Date.ToString('yyyyMMdd-HHmmss') 
} Else {
	Return "No CU Patching Information Available" 
};

 

The added benefit from this approach was it didn't matter how the patch was installed, whether through automate, manually or by a third party, it should always appear which is great to get an accurate sense of patch level when on boarding a new client.

Now we had the latest patch information from the computer in Automate I simply created an internal monitor to compare the timestamp and log a ticket for anything that hasn't successfully patched in over 35 days.

image.png.f474594453c4f895442024ce8f75338c.png

 

So far this has been working for me, it's also highlighted a few machines that haven't been patched since last year that didn't show up in the report. A few ideas we've had so far to improve upon this

  • Add some verification to only log a ticket if the machine has been online during the past 35 days
  • Run some autofix actions prior to logging a ticket such as
    • Force the EDF's to update and revalidate
    • Attempt to run a patch job

I'd love to hear peoples feedback on this approach, any gotcha's you might see catching us out in future, or ideas to improve on the solution. If nothing else hopefully this posts helps some others detect systems that aren't patching properly.

 

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×