Patch Tuesday Operations for Intune and Windows Update for Business

Use this page for the parts of Patch Tuesday that do not change with the CVE list. Monthly briefings such as August 2026 and June 2026 should keep the month-specific KBs, exploited issues, and known issues, then link here for rings, Intune checks, monitoring, and exception logging.

Ring topology and quality-versus-feature ownership are covered in the Windows Update for Business rings guide. This page is the monthly operating loop that sits on top of that design.

Scope and verification basis: this is an operational model reviewed against current Microsoft Intune and Windows Update for Business documentation. It is not a claim that every check was executed in one named tenant on one Tuesday.

What stays on the monthly page

Keep on the month’s news article:

• CVE and exploit status for that release
• KB and build table for each supported Windows version
• that month’s priority order
• that month’s known issues
• lifecycle dates that fall inside the window
• product changes the Windows LCU does not fix

Do not paste the sections below back into every monthly briefing.

Ring promotion evidence

Use rings that produce evidence, not rings that exist only on a diagram.

Ring 0 — lab and recovery. Representative Windows versions, one identity-critical server role if you patch those this cycle, the image-deployment path you operate, backups, recovery keys, console access, and a named rollback owner.

Ring 1 — IT and pilot. Different hardware models, VPN clients, endpoint security agents, line-of-business applications, and at least one device from each active Windows build.

Ring 2 — early production. Expand only after installation, restart, application, and security telemetry from Ring 1 is clean.

Ring 3 — broad deployment. Promote only after failure codes, restart compliance, BitLocker events, service health, and the Microsoft known-issues pages have been checked again.

Do not expedite the whole estate because one local elevation of privilege is marked exploited. Expedite a named high-risk group after a focused pilot.

If ring timing does not match policy, use the WUfB deferral diagnosis.

Intune and Windows Update for Business checks

Check policy intent against device state:

• Ring assignments, exclusions, deadlines, grace periods, active hours, and restart settings
• Feature update policies that would move the same pilot devices to a new Windows release during the quality-update test
• Devices that have not synced recently
• Installed OS build, not only Intune policy deployment state
• Autopatch hotpatch eligibility, where that programme is in use
• Exclusions with owner, reason, compensating control, and review date

A device that did not restart is not automatically evidence of a missed quality update on a hotpatch path.

Validate the build on a sample

Intune compliance and WSUS reports are necessary. They are not sufficient. Confirm the OS build and the expected hotfix on a sample of each ring before you promote.

$cv = Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion'
'{0} {1}.{2}' -f $cv.DisplayVersion, $cv.CurrentBuild, $cv.UBR

Get-HotFix |
    Sort-Object InstalledOn -Descending |
    Select-Object -First 15 HotFixID, InstalledOn, Description

Compare CurrentBuild.UBR (for example 26100.xxxx) with the build in that month’s KB table. Do not use Get-ComputerInfo OsBuildNumber for this: it returns the base build (26100) without the revision, so it reads the same before and after every monthly update.

Get-HotFix will not list every combined servicing stack the same way on every OS. If the revision matches and the device is Autopatch hotpatch-eligible, treat the hotpatch artefact as the compliance evidence rather than forcing an LCU hotfix ID.

This is a sample check, not a fleet inventory. Keep Intune, Autopatch, WSUS, or ConfigMgr as the source of record.

Where to look: console and device

Portal paths as Microsoft documents them at the time of review. Blade names move between service releases; if one is missing, search the admin centre for the report name rather than trusting a bookmark.

On a sample device, from an elevated prompt:

Get-WinEvent -LogName 'Microsoft-Windows-WindowsUpdateClient/Operational' -MaxEvents 200 |
    Where-Object Id -in 19, 20, 43 |
    Select-Object TimeCreated, Id, Message -First 20

Success check before promoting a ring: on a sample from each hardware model in the ring, CurrentBuild.UBR equals the month’s target, event 19 names the month’s KB, no restart is pending, and the ring’s device status shows no single error code concentrated on one model or driver. Intune “Succeeded” without the revision check is not enough.

Known-issue watch

Before each ring promotion:

1. Re-read Windows release health and the KB pages in that month’s briefing.
2. Separate consumer-only issues from estate-matching hardware and roles.
3. Treat missing WSUS error detail as an observability limit, not proof that synchronisation failed, when Microsoft documents that behaviour.
4. Keep the BitLocker recovery key Entra backup guide available when PCR7 or recovery-prompt issues are in the notes.

Post-deployment monitoring

For the first 24 to 48 hours, group incidents by OS version, KB, hardware model, driver, security agent, and server role:

• Installation failures, rollback events, pending restarts, devices still below the target build
• BitLocker recovery prompts and recovery-key lookups
• Role-specific health for whatever you prioritised that month (identity, imaging, DHCP, DNS, HTTP.sys, and so on)
• Intune and WUfB reports for stale check-ins, download failures, install failures, and deadline behaviour
• VPN, EDR, printing, and line-of-business application health on pilot devices

A concentrated pattern is more useful than a raw failure total when deciding whether to pause a ring.

Exception log

Do not leave exclusions as unnamed policy filters. Record:

Hold and rollback criteria

Pause promotion when:

• A known issue matches hardware or roles in the next ring
• Failure codes concentrate on one model, driver, or security agent
• Recovery-key lookups or BitLocker prompts rise beyond the pilot baseline
• Identity or imaging roles fail their smoke tests

Rollback ownership belongs in the change record before Ring 0 starts. Console access, backups, and the previous known-good build are prerequisites, not afterthoughts.

Rollback mechanics

In order of blast radius, smallest first:

1. Pause the ring (quality updates) so devices that have not installed yet stop. A pause expires after 35 days. Put the resume date in the exception log when you press it.
2. Known Issue Rollback (KIR) when Microsoft publishes one for the issue. On managed devices a KIR is a policy you deploy, linked from the Windows release health entry. Target it at the affected ring only, and remove it once the fixed update ships.
3. Ring-level Uninstall in Intune for the latest quality update, when the issue has no KIR and the ring is small. Read Microsoft’s current Manage update rings guidance first for how Uninstall and Pause interact on that ring.
4. Per-device removal of the LCU for a named device. On current Windows, the monthly package combines the servicing stack update (SSU) with the latest cumulative update (LCU). Microsoft’s KB pages state that wusa.exe /uninstall does not remove the LCU from that package. Use DISM with the LCU package name, and remember the SSU cannot be removed (servicing stack updates):

DISM /Online /Get-Packages /Format:Table | findstr /i RollupFix
DISM /Online /Remove-Package /PackageName:<Package_for_RollupFix name from the line above>

After any rollback, check the revision again. A device that reinstalls the same update overnight means the pause or ring change did not reach it.

What not to run in production

These appear in forum threads as Patch Tuesday fixes. They are not fixes.

• Expedite to All devices. Expedite a named, piloted high-risk group. An expedite bypasses the deferral that gives the rest of the estate time to find the problem.
• Fleet-wide LCU removal through a remediation script or ConfigMgr package. Removing a security update from every device to fix a problem on one model creates an estate-wide exposure. Pause, apply the KIR, or remove the update from named devices.
• Resetting Windows Update components, including deleting SoftwareDistribution or catroot2, as a first response across a ring. It destroys the evidence and rarely addresses a policy or content problem. Keep it for one device after its logs have been saved.
• Deadline 0 with grace period 0 on a production ring. Users lose work, and the restart storm hides real install failures.
• Suspending BitLocker fleet-wide to get past a recovery-prompt known issue. Suspend only on named devices whose recovery keys you have confirmed are escrowed.
• An open-ended pause with no owner or resume date. It turns into a ring that silently misses next month’s security update as well.

Related resources

• Windows Update for Business rings in Intune
• Patch management hub
• August 2026 Patch Tuesday
• June 2026 Patch Tuesday
• October 2026 Windows servicing deadlines
• Windows release health

Correction record

29 September 2026 — Reviewed against documentation. The build check previously used Get-ComputerInfo OsBuildNumber, which has no revision number and cannot show whether the month’s update installed. It now reads CurrentBuild and UBR. Added console paths, Windows Update client events, rollback mechanics (pause, KIR, ring Uninstall, DISM removal of the LCU) and a list of commands not to run fleet-wide.