· 10 min read

September Patch Tuesday Broke RDS on Windows Server 2019, 2022, and 2025: A Playbook for Solo IT Consultants

Tools Lessons

A law firm's terminal server looks perfectly healthy at 9 a.m., installs its Patch Tuesday updates overnight like it's supposed to, and then around 1 p.m. every remote session starts hanging at "Connecting..." Nobody can log off, nobody new can log in, and the only fix left on the table is a hard reset. That's the actual shape of the bug Microsoft shipped on September 8, 2026: KB5122876 for Windows Server 2019, KB5122882 for Server 2022, and KB5122871 for Server 2025 all deadlock Remote Desktop Services, and they do it hours after the update looks like it went fine.

What actually broke, and why it's not obvious right away

The failure traces to a deadlock between Remote Desktop Services and the Local Session Manager that gets triggered on logoff. Administrators debugging the issue found the service hanging at a routine called RDPSERVERBASE!WDLIB_Close during session teardown, with no timeout set on the wait. Because the Local Session Manager serializes session-state changes through a single critical section, one stuck logoff is enough to jam every subsequent connection, disconnect, and broker request behind it. Microsoft hasn't published its own root-cause writeup, but the pattern is consistent across reports: a session host reboots clean, RDS works normally, and then somewhere in the first several hours, as real users start logging off for lunch or end of shift, the whole stack wedges.

That delay is the reason this bug is more dangerous than a patch that just fails outright. A server that's obviously broken at 9 a.m. gets caught before anyone's working on it. A server that's fine at 9 a.m. and locks up at 1 p.m. catches your client mid-workday, mid-invoice, mid-deposition prep, whatever they're doing on that box. You find out about a bad patch that fails immediately from your monitoring. You find out about this one from a client calling you in a panic because their whole remote staff just got locked out.

Why "wait it out" is the wrong call here

The instinct with a bad cumulative update is often to sit tight until next month's Patch Tuesday quietly supersedes it. That instinct is wrong here for two reasons. First, the failure is time-bomb-shaped: a server that patched clean overnight can still detonate the next afternoon, so "it hasn't broken yet" tells you nothing about a given client's server. Second, the same September update also carries the fix for a critical Remote Desktop Services remote-code-execution flaw, tracked as CVE-2026-69525 with a CVSS score of 9.8, plus other actively exploited issues. Rolling back the update to dodge the RDS bug means reopening that hole, which is a worse trade for a client with an internet-facing RDS box than a scheduled maintenance window.

Waiting a month means one of two bad outcomes: the client eats an unpredictable outage during business hours, or you talk them into rolling back a patch that fixes a 9.8-severity RCE. Neither is a position you want to be defending after the fact.

The five-minute check for every client server you manage

Before you touch anything, find out who's actually exposed. Run this against each RDS or terminal server you manage:

  • Check whether the September update is installed: Get-HotFix -Id KB5122876 on Server 2019, swapping in KB5122882 for 2022 or KB5122871 for 2025. A result means the box is exposed once it hits the multi-hour window.
  • If a server has already started misbehaving, check Event Viewer for the two signatures tied to this specific bug: Event ID 20498 under Microsoft-Windows-TerminalServices-RemoteConnectionManager, and Event ID 6005 from Winlogon referencing a stuck SessionEnv disconnect notification.
  • Check the TermService state with Get-Service -Name TermService. A status of StopPending instead of Running is a strong sign the deadlock is already active on that host.

Run this across your whole client list in one sitting, not one server at a time as tickets come in. The point is to know, today, which of your accounts are ticking rather than finding out when the first one goes down.

How to tell a client about a bug that hasn't hit them yet

This is the part that actually pays for the retainer. Once you know which servers installed the affected update, email or call those clients before anything breaks: tell them Microsoft shipped a Patch Tuesday update with a known Remote Desktop Services bug, that their server is a match, that it may cause remote sessions to fail sometime in the coming days, and that you're scheduling a short maintenance window to apply Microsoft's permanent fix. Give them a specific window, not "soon."

That message does two things a break-fix ticket never can. It shows up as proactive monitoring instead of a surprise invoice, which is exactly the value a recurring retainer is supposed to buy. And it means that if the deadlock does hit before your window, the client already knows why and that you're on it, instead of hearing about a mystery outage from an angry office manager. A client who gets that email a day ahead of the outage renews the retainer. A client who finds out you knew and didn't say anything does not.

The fix: install the out-of-band update, not a workaround

Microsoft has released permanent out-of-band updates for all three affected versions: KB5129238 for Server 2019, KB5129237 for Server 2022, and KB5129235 for Server 2025, all released September 14, 2026. These are cumulative, meaning each one includes the original September 8 fixes, so there's no need to install KB5122876 first if you haven't already, you can go straight to the OOB update. Installing it is the whole fix, with no registry workaround or Known Issue Rollback policy left over to manage afterward.

These updates don't come down automatically through Windows Update, so download the .msu for each server version from the Microsoft Update Catalog, copy it to the host, and run wusa.exe .\<filename>.msu /quiet /norestart. Plan for a reboot: it will disconnect active sessions, so schedule it outside business hours the same way you would any other maintenance window. After the reboot, RDS should behave normally through a full logoff cycle, which is the thing to actually watch for before you close the ticket, not just that the server came back up.

What I'd Actually Do

If you manage RDS boxes for clients, I'd run the KB check today, not this week. Then I'd batch every exposed client into one evening or early-morning maintenance window per site, apply the out-of-band update, and send the heads-up email before you touch anything, even for clients you plan to patch within hours. The sequence matters: proactive notice, then the fix, in that order.

The honest limit here is that you can't out-consultant every silent regression Microsoft ships. This bug took roughly a week from Patch Tuesday to a permanent fix, and for that week the only real options were rollback, a Known Issue Rollback most admins never heard about because Microsoft gated the notification to certain licensing tiers, or an undocumented registry flag that at least one admin reported didn't hold. You can't promise a client zero-outage patching in a world where vendor updates ship with regressions like this. What you can build is the muscle: a standing habit of checking install status against public advisories a few times a week, and a client relationship where "I caught this before it hit you" is a normal message, not a rare one. That's the actual product a solo operator is selling here. Not immunity from Microsoft's mistakes, just a much shorter gap between the mistake happening and someone catching it.

Author

Lukas

Sources

More Tools articles →

Stay in the Loop

Get new posts delivered to your inbox. No spam, unsubscribe anytime.

Newsletter coming soon. Set PUBLIC_CONVERTKIT_FORM_ID in .env to activate.

Related Posts