Everyone knows that Intune’s strength is not in reporting.
Getting concrete data can be hard, so I built my own reporting tool to do just that.
Here’s how I did it.
The Problem:
Some Windows 11 devices in our fleet were falling behind on Windows Updates. This is an issue as the further behind they get, the more vulnerable they become, increasing our exposure level.
Reviewing the environment, everything looked correct:
- The affected devices were recently active
- Our Windows Update policies were properly configured
- Devices had successfully received the policies
But despite all of that, dozens of devices still weren’t installing patches.
Some of them were running months behind on security updates.
We needed a clear reason why each device was falling behind, and we needed to pull that information centrally.
Reviewing our options..
In this case I’m working with a pretty simple tech stack.
- Entra Joined Devices.
- Intune managed.
- Defender for Endpoint.
- Windows 11 Enterprise.
Surely, we can get the data from Intune right?
I came across Microsoft’s feature update monitoring documentation, and at first it looked close to what I needed (even if it just covered feature updates).
There was just one problem… the report it referenced didn’t exist.
I was however able to find an entirely different “quality update report” under Autopatch reports, but it does not give me any error codes or clues on why devices aren’t updating.
Sadly, Defender does not help us much here either, only revealing what updates devices are missing and begging me to patch them.
The closest thing to real update reporting seems to be Windows Update for Business Reports, which uses Log Analytics in Azure Monitor.
If we look at screenshots from WUfB reporting, we can see it does give some status messages and “alerts” but it doesn’t seem like there’s enough data here to really explain why a device is behind.
Community Solutions
One thing that kept coming up was this script from Reddit user hahman14.
I took a look at the script and it’s a nice design, it focuses on DISM repairs, cleaning up old update policies, even schedules a reboot around midnight.
But I wanted something more reporting focused that was safe to run at scale, this way I could split devices up into categories and plan out remediation based on the individual issues.
The reality is too, Intune alone is unlikely to be able to fix all of the devices, there will be a few more involved issues that make sense to go to onsite teams for device replacement/re-imaging.
This gave me an idea.
I made my own reporting script
Similar to hahman14, I decided to take advantage of Intune’s Remediation Script function to push a powershell script to each device.
Remediation scripts aren’t really meant for reporting in this way, so I had to keep in mind that my output might be truncated or hard to export cleanly from Intune.
Still, I was able to piece something together that met my needs fairly well.
There’s 2x parts to this
- Local logging – The detection script gathers endpoint information and drops it to a JSON file under:
C:\ProgramData\Remediations\WindowsUpdate\UpdateHealth.json- Intune error output – this parses the data from the .json file and truncates it down to only the key bits of information and then logs it to Intune. See the example output below:
I’ve released the script as-is on my github below, which also includes instructions on how to use it :
While this serves my needs fine, there is definitely some room for improvement, so if anyone wants to contribute I’ll happily review any PR’s.
Working with the data
The first step is to make sure that you’ve got the “Pre-remediation detection output” column enabled in Intune.
Once you’ve done that you can review each output individually from the Device status page.
You can even use the export button to open the data in Excel.
As you can see this gives you a lot of information to go off, in my example I’ve got a few different error codes that reveal exactly what is going on with my machines.
However, if you want even more data, you can use Microsoft Defender Live Response (or another remote access tool) to retrieve the full .json file directly from an endpoint for analysis.
The .json file gives you a lot more info, historical update installs, Network test results, service statistics, it’s all there.
Perhaps someone out there might be able to ingest this into Log Analytics/Azure Monitor or something similar to get some cool looking reports from it, but that’s out of scope for me today.
Next Steps.
With my script, I now know that there aren’t any patterns with update failures, I’ve literally got different hex error codes for each device in my list.
In this case it all seems to point to Windows Update Servicing issues on the devices themselves, not disk space issues, low activity or force shutdowns interrupting updates.
The next step for me is to explore repairing Windows Update components with another Intune remediation script.
For the stubborn devices that can’t be resolved remotely I’ll assign our onsite guys to take a look and provide them the error codes directly from the endpoint.
Once we get all our devices up to date we can explore setting a Minimum required OS version using Conditional Access/Compliance Policies to immediately block access to devices that are vulnerable.
This would also ensure that any devices with patching issues receive attention from IT before falling multiple months behind.
Problem solved.
I hope this helped.
Leave a comment down below if you have any tips or even if you just have different ways that you are handling this in your organisation, I’m curious!
Cheers,
Chris
Leave a Reply