Windows Update for Business Custom Reporting
In this guide I'll walkthrough a custom solution I created for reporting with Windows Update for Business using Azure automation, Log Analytics and Power BI.
When we first moved from deploying software updates with ConfigMgr to using Windows Update for Business with Intune, we naturally depended on Microsoft's Update Compliance (now WUfB Reports) solution for reporting. However, for us, I found it didn't really meet our reporting needs, so I set out to develop my own reporting solution.
It was a bit of work to get everything figured out, but the resulting report is much more satisfying to us and displays most of the data we want to see in a user friendly way.
Particular benefits include:
- A reduction in (and control over) the data latency, meaning fresher data in the report
- The ability to report on other kinds of updates, including drivers, .Net framework updates, .Net core updates and many others
- Superior (in my opinion) reporting views and filtering options by reporting with Power BI☺
- Compliance charts for the latest CUs, including the monthly security, non-security preview and out of band updates
- Installation states for the latest monthly security update, such as installed, pending reboot, started, failed, quality updates paused, deferred x days etc
- Compliance against the previous and previous -1 monthly updates
- Trend charts for the above for viewing compliance over time
- Compliance table for viewing compliance counts against individual updates
- A filterable devices list for viewing compliance data for a device or group of devices
- Feature update adoption trend chart
- Windows upgrade readiness for viewing devices capable or not capable of Windows 11 upgrade, including safeguard holds and other blocking reasons
- Successful feature update installations
- Failed feature update installations, including error codes, their descriptions (where known) and SetupDiag results (where applicable)
- OS version, edition, SKU and support status charts, including support start and end dates and days remaining for each release
- Cumulative update release history including update type, build number, KB and release date
- Windows Update for Business MDM policy settings
- Windows Update policy state, including deferral periods and devices that are currently paused for feature or quality updates
- An overview of installation states for all types of updates, including top failing updates
- A filterable list of devices that have failed to install an update with the error codes and descriptions (where available)
- A filterable list of devices that are out-of-date for the latest monthly security update, to aid in troubleshooting
There are several filters in each of the report pages to allow focused reporting on specific updates, OS versions, devices, data freshness etc.
Intune Proactive remediations is used to run a client-side script on a regular cadence, gathering and sending various software update-related data to a log analytics workspace in Azure.
Azure automation runbooks are used to summarize compliance, trend the data, and gather supplementary data from various Microsoft public sources.
A Power BI report connects to the log analytics workspace and presents the data.
There is no dependency on or connection to the Microsoft provided reporting solution, however there is no reason not to use both if you wish. If you use the same log analytics workspace for both solutions, you could use data from both solutions in your own customized reports.
My solution may not be suitable for all, and there are some things to consider if you want to implement it:
- The solution comes with no support, so you must assume any risk. Since I use the solution myself I will be maintaining it, however.
- Intune proactive remediations are required. You could also use local scheduled tasks as an alternative.
- Azure resources are required, so you'll need to be able to create them and have some basic familiarity with them.
- Power BI licenses are required as well as some familiarity with creating Power BI reports
- The solution uses the log analytics data collector and query APIs and is subject to their service limits. For most, this should not be an issue, but in very large environments it could be.
- The primary key of the log analytics workspace is stored in the client-side script, which is a security concern for some as it is cached on disk (albeit only accessible to administrators). There are ways around that though, including this from Damien van Robaeys which deletes the script from the client after it has run.
- The solution supports the English language. If any of your devices have a different OS display language than English, some minor adjustments may need to be made for all parts of the report to work correctly (I have documented the required changes).
- The report does not include Delivery Optimization data; I use a separate solution for that as its a thing in itself.