Enhancing Windows Update Catalog metadata Accessibility

Microsoft has recently released a major update to the Windows Update catalog back-end, adding crucial information such as CVEs (Common Vulnerabilities and Exposures) addressed by the update and the CVE Score directly info API. This information is essential for Threat and Vulnerability Management decisions as well as Patch management and many organizations pay $$ for tools exist, that query and cross-reference such data in order to identify endpoints that need to be urgently patched, isolated or double-checked for signs of exploitation. Adding this info straight into the catalog means a great deal of simplification of this process, which could be now accomplished with something as simple as PowerBI Query or a PowerAutomate flow right now, and it is reasonable to expect to see it in Intune and Autopatch someday on a “checkbox” level. (but don’t quote me on that, I don’t influence the process and don’t have insider info).

What’s the problem?

But what you have now in that article is a set of low-level ODATA REST calls to MS Graph API for programmers. If you understand the importance of the first part, but don’t feel like programming for it – I might have something for you! It is not [yet] a fully automated solution, but you already can view the security security information from the catalog in a human-friendly way and use it for decision-making right now, while more goodness is being developed. And if you are good with Flow / PowerBI and the like – there’s enough for you to close the loop (I bear no responsibility, but will happily get a share of the kudos :))

What now?

For now I have created a PowerShell script that takes some intuitive (hopefully) parameters and presents data in a variety of ways (there is a big comment at the beginning of the code – check it out).

Parameters:

• Update Type: feature or quality (default)
• Quality update parameters such as Classification (security/non-security) and Cadence (standard monthly or emergency out-of-band). By default everything will be included.
• CVE related parameters such as CVSS score and Comma-separated list of CVE names
• Sorting and limiting parameters such as Order By and Top X results
• -Verbose for troubleshooting

Output formats:

• PowerShell Grid View (with search, filter, sorts etc) – this is the default
• PScustomObject (for piping into other PS Scripts)
• JSON (for integration with other solutions)
• [not yet] CSV (have encountered issues and crashed and must learn the best practices for unfolding multi-level objects into flat tables)

Here are examples of what comes out in Grid View mode.

Output Example for GridView and quality updates

Feature updates contain a lot less metadata
Get-WindowsUpdateCatalogDetails.ps1 -Type Feature

Example with filtering by Classification and CVSS

You can grab the script here: https://github.com/apcsb/PSscripts-public/blob/master/WindowsUpdateTools/Get-WindowsUpdateCatalogDetails.ps1

Setting up

Working with Graph API is not straightforward, unfortunately, and requires some setup.

Permissions:

The script will ask you to authenticate against your M365 tenant (check out a default you can add to the code to simplify the process) and your account must have access to a Graph permission “Windows Updates.ReadWrite All“, this, unfortunately is a requirement I cannot circumvent, so ensure your account is Device Admin or better, or create a custom Role.

App registration:

If for some reason MS Graph PowerShell or MS Graph Command Line Tools applications are not available in your tenant, or you are not able to consent to them using the above permission – you will have to create a custom app registration and pass the Client ID as a parameter. This is actually not that hard (follow the tutorial here) – let me know in the comments if I should add more details on this.

What’s next?

What I have on my todo list is to explore 3 paths from there:

• Act on insights:
  • Leverage the info in this article (https://learn.microsoft.com/en-us/windows/deployment/update/deployment-service-expedited-updates ) to close the loop and auto-expedite updates. For instance, expedite deployment of a specific updates or all update with VSS >=X for all devices or a specific device group (ring model).
• Enrich with device data
  • Use info from WuFB Reports (which is basically a workbook visualizing Log Analytics logs) to report devices that are missing a specific update or devices that are vulnerable to a CVSS Scope > X.
• Automate it
  • One thing I really like about PowerShell, is that it is incredibly easy to turn it info a microservice by hosting the script with minimal changes as an Azure Function. So hosting it there and they using as part of LogicApp or Flow to send alerts to Teams Channels, auto-generate and email reports, call Graph APIs for Intune or Defender to isolate the device becomes quite easy.

In general, my experience with Intune, AAD (now MS Entra ID) and generally M365 shows that the admins who treat M365 as a platform (that has a rich set of APIs that are waiting to be used in Scripts, Flows, LogicApps etc) get at least 10x more from it than those who confine themselves to what’s available in off-the-shelf GUI. And if you think that programming is hard – 60%+ of the “grunt work” on this script was done by GitHub Copilot, and you can have the same for Flow, PowerBI, PowerApps and many other things. So whenever I hear “we miss this option in a dropdown” or “we wish this report looked a bit differently” – it has never been a better time to get that 10x bonus for 0.5x work!

What do you hink?

Do you find such content useful? What do you want to see next? Do you want to see a post on ODATA and MS Graph API in general? Or on how I use Copilot to do most of the legwork for me? Or you have taken this script as a basis and improved upon it? Let me know in the comments!