Blog Post

Windows IT Pro Blog
2 MIN READ

Classifying Windows updates in common deployment tools

Rashid_Siddiqui's avatar
Feb 05, 2019

If you utilize automated update deployment tools, such as Windows Server Update Services (WSUS) or System Center Configuration Manager, you likely use automatic rules to streamline the approval and deployment of Windows updates. Using the correct update classification is, therefore, an important component of your organization’s device update process. For some industries, it can even be a requirement as, if properly configured, it will ensure that devices across your environment receive the most current update available.

Some Windows enterprise-level customers opt to take only security updates (aka the “B” release, or “Patch Tuesday”) to reduce the impact to their network, their personnel, and their devices. To accomplish this, they configure automatic rules to deliver only updates with a classification of “Security Update.”

But what if there is an issue with the security update itself? When this occurs, depending on the severity, we (the Windows Servicing & Delivery group) may choose to mitigate the issue through an additional security update or an out-of-band release—or we may choose to resolve the issue in the following month’s security update.

Unlike regularly scheduled monthly security updates, non-security and out-of-band updates are classified simply as “Update” in both WSUS and Configuration Manager. That means, if you are using auto-update rules set to receive updates classified as “Security Update” only, you will not receive a more recent update should one be produced and, thus, will miss the earliest opportunity to acquire a necessary fix for their environment.

So, what options are available for WSUS and Configuration Manager customers?

  1. You can opt to configure your automatic rules to include updates classified as “Update” temporarily, or longer-term if preferred. Here are instructions for updating these rules:
  2. You can opt to wait for the next security update, which will include all previous fixes.

If you’re interested in learning more, or would like to see how you can use tools like Configuration Manager, WSUS, or Windows Update for Business to manage updates, see the Quick guide to Windows as a service. To learn more about Windows as a service, check out the Windows as a service gateway on Docs.

Updated Feb 06, 2019
Version 5.0
  • BruceRoberts's avatar
    BruceRoberts
    Steel Contributor
    Why can't you classify updates for security updates as security updates?
  • If you utilize automated update deployment tools, such as Windows Server Update Services (WSUS) or System Center Configuration Manager, you likely use automatic rules to streamline the approval and deployment of Windows updates.

    No. I don't. Triaging WSUS updates is much more complex. The only updates I have set to auto-approve are malware definition updates. I use a PowerShell script to:

    • Decline updates released for ARM64, Itanium and IA-32, because we only have x64 systems. Declining updates for IA-32 is truly difficult because they are either not marked or marked incorrectly.  Sometimes they have "32-bit" or "x86" in their names.
    • Decline tens of gigabytes worth of Windows 10 updates too. We do not want updates for Windows 10 version 1507 (OEM), 1511 (November Update), 1607 (Anniversary Update), 1703 (Creators Update), 1709 (Fall Creators Update), or 1809 (fall destroyer update). Just Windows 10 version 1803.
    • Decline cluster updates, farm updates, "security-only" updates "security-only quality" (🙄) updates, and preview updates.

    In addition:

    • Any "package" released for .NET Framework needs manual case-by-case approval too.
    • From time to time, I go down to a random computer and run a LOB tool that I've written myself. It connects to Microsoft Update service and checks for updates but does not download them. (It uses Microsoft's own WSUS API. No tricks.) Occasionally, I find that there are updates that somehow failed to appear on WSUS.
  • wroot's avatar
    wroot
    Silver Contributor

    I agree. WSUS needs LOTS of manual triaging. Or you have to have a peta byte disk to hold all the unneeded updates. It always annoyed me, that i can't just get rid of x86, or older versions of updates for say Windows 10 and not having to look through them every time. I don't think WSUS/SCCM can be changed that way, but i envision a system, that will poll every PC/server connected to it and sync only updates missing on these machines. I guess Windows Update for Business policies are kind of this way, but no visual console to monitor. Windows Analytics for Azure probably can be that console, but that's only for newest OSs and an additional cost.

  • vsterkin's avatar
    vsterkin
    Iron Contributor
    Instead of giving the customers a pretty much useless advice, why don't you get together with other PGs and clean up your update classification mess? Servicing stack updates are being classified as security, cumulative updates as security, etc, etc. Fix the culprit.
  • wroot's avatar
    wroot
    Silver Contributor

    On my previous job we were syncing Critical Updates, Security Updates, Service Packs, Update Rollups, Upgrades in WSUS (Upgrades were added for Win10 feature updates). I guess we were not getting fixes for broken security updates. Though i don't remember Windows update breaking something that often. In 10 years span i can count a few probably. Most recent was with Office update actually and it was retracted via WSUS quite fast.