Useful articles

Microsoft closes the RDP bug in Windows Server 2022 and 2019: KB5129237 and KB5129238 are out

A week after September's RDP-hanging fiasco (see the article below), Microsoft shipped out-of-band cumulative updates that close the issue at the patch level rather than through a workaround.

What's fixed

Both packages are cumulative — they include everything from the September CU (KB5122882 for 2022, KB5122876 for 2019), so there's no need to install that separately first. The main fix is the same deadlock in Remote Desktop Services introduced by the September security update: RDP connections hanging, sign-in failures, and in some cases the server becoming completely unresponsive during Remote Desktop configuration. Related tools — MMC, RDS Licensing Diagnoser, File Explorer, and the Windows Update page — hang along with it. The 2022 build also picks up a fix for USB Audio Class 1.0 multichannel audio failures.

Download

• KB5129237 for Windows Server 2022 — Microsoft Update Catalog →
• KB5129238 for Windows Server 2019 — Microsoft Update Catalog →
• Official KB5129237 support page →

How to install

Download the x64 .msu package → install → a reboot is required, this is a full servicing restart, not a no-reboot hotfix. After it comes back, check the build:

$cv = Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion"
"$($cv.CurrentBuild).$($cv.UBR)"

Expect 20348.5631 on 2022, 17763.9247 on 2019. Test fresh RDP logons specifically, not just existing sessions — that's where the bug showed up first.

Our take

To put it bluntly: they shipped an update that breaks RDP on servers with no RDS role installed at all, then spent a week patching it over with a half-official KIR that plenty of admins never even saw, because the notification didn't reach everyone. For a security patch meant to close a critical RCE, that's not exactly a showcase of engineering discipline.

That said, credit where it's due: this time Microsoft moved fast. The issue status flipped to Mitigated in under a week, and a proper servicing fix landed just two days after the KIR. For a company shipping updates at this scale, that's about as fast as it gets.

If you're running 2022 or 2019 boxes still sitting on the September CU without a KIR, now's the time to close this out properly instead of relying on a stopgap. If you'd rather not deal with it yourself — get in touch, we'll roll it out, verify it, and keep an eye on it for a couple of days so you know it stuck.

Windows Server 2022's fatal September update: what broke and how to fix it

September 2026 Patch Tuesday delivered KB5122882 (build 20348.5622), which breaks Remote Desktop. Not immediately: the host runs fine for a few hours after a reboot, then new RDP connections hang forever at "Connecting…", users can't log off, and Task Manager and query user freeze right alongside them. A graceful restart hangs too — only a hard reset recovers the box, until next time.

Confirmed on a live server. Below is what actually happens, how to identify it, and how to fix it without stripping the September security patches.

Who's affected

An important detail: the RDS role is not required for the bug to trigger. Plain administrative RDP — the default two sessions — dies exactly the same way on a bare Server 2022 with no RDSH installed. Domain controllers and standalone servers are in scope.

Root cause

A deadlock in the session teardown path. RDPSERVERBASE!WDLIB_Close calls RtlWaitOnAddress with no timeout when internal feature flag 3802373433 is active. The thread waits indefinitely, and because Local Session Manager serializes all session state changes through a single critical section, everything queues up behind it: new connections, logoffs, broker requests.

The reversing was done by an independent researcher on a live Server 2022 host. Microsoft never publicly confirmed the cause, but on September 13 it flipped the issue status to Mitigated and shipped a Known Issue Rollback.

How to identify it

Check the build first:

$cv = Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion"
"$($cv.CurrentBuild).$($cv.UBR)"

20348.5622 is the affected Server 2022 build. Then look for three characteristic log signatures:

• Event 20498, TerminalServices-RemoteConnectionManager/Admin — RDS took too long to complete the client connection.
• Event 6005, Microsoft-Windows-Winlogon (System log) — the SessionEnv subscriber is slow handling Disconnect.
• TermService in StopPending rather than Running — the deadlock is already live.

Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-TerminalServices-RemoteConnectionManager/Admin'
    Id      = 20498
} -MaxEvents 5 -ErrorAction SilentlyContinue

If the log is clean and the service is Running, the host either hasn't hit the condition yet or isn't affected.

Why you shouldn't just pull the update

The same package patches CVE-2026-69525, a critical Remote Desktop Services RCE at CVSS 9.8. Plus two zero-days already under active exploitation and listed in CISA's KEV catalog: CVE-2026-81963 (Windows Update stack) and CVE-2026-85880 (ALPC). If the host is internet-facing, a full rollback is a last resort, not a first step.

Separately: wusa /uninstall /kb:5122882 will fail outright. September's updates ship as combined SSU + LCU packages; the SSU can't be removed, so the standalone installer rejects the whole bundle.

The right fix: official KIR

Microsoft released a Known Issue Rollback — a mechanism that reverts the specific offending change while leaving every security fix in place. For Server 2022 the package is KB5122882 260911_18471. The notification only went out to subscribers with applicable Microsoft 365 or Windows licensing, so plenty of admins never heard about it — but the MSIs themselves are publicly available.

1. Download the MSI for your release and install it.
2. The installer drops ADMX/ADML into %SystemRoot%\PolicyDefinitions. In a domain, copy them to the central store at \\domain\SYSVOL\domain\Policies\PolicyDefinitions\. On a standalone host this step isn't needed — the local store is enough.
3. Open gpedit.msc (or GPMC in a domain) → Computer Configuration → Administrative Templates → the section tied to KB5122882.
4. Set the policy to Enabled.
5. Run gpupdate /force.

gpedit.msc ships in Server 2022 Standard, not just Datacenter — you don't need domain infrastructure to deploy a KIR. No reboot is required per the documentation, but watch events 20498 and 6005 for 24–48 hours, especially around bulk logoff windows.

Gotcha: DISM may refuse

The classic path for an already-dead host is a hard reset followed by package removal via DISM:

dism.exe /Online /Get-Packages /Format:Table | findstr /i "Package_for_RollupFix"
dism.exe /Online /Remove-Package /PackageName:Package_for_RollupFix~31bf3856ad364e35~amd64~~20348.5622.1.2 /NoRestart

But DISM may well tell you the package has become a permanent part of the image and cannot be removed. That means component cleanup has already run on the host — either /StartComponentCleanup /ResetBase by hand or the corresponding scheduled task. After ResetBase, the component store no longer keeps previous file versions, and rolling back that specific update becomes impossible, period.

If rollback does succeed, block the update from reinstalling right away — decline it in WSUS, or apply a GPO update deferral. Otherwise it comes back in the next maintenance window.

If the server is already hung

You can't apply a KIR to a frozen host — it's unreachable over RDP and remote management alike. The order is: hard reset, then immediately apply the KIR without waiting for the deadlock to recur (or remove the update via DISM if the KIR isn't available). The window is a few hours after boot.

Own server, colocation, dedicated, or VDS: which to choose

When a business needs server infrastructure, the question arises: keep hardware in-house, place it in a data center, or rent capacity from a provider. The right choice depends on budget, security requirements, and willingness to handle hardware maintenance.

An on-premises (LAN) server is the classic choice for small offices: full control over data, but full responsibility for power, cooling, and repairs when something breaks.

Colocation removes the infrastructure headache — the server is yours, but it sits in a provider's data center with reliable power, connectivity, and security. Renting a dedicated server removes hardware ownership entirely: the provider maintains and replaces components, but configuration is limited to what's available. VDS/VPS is the most flexible and affordable option, with fast resource scaling — but without full control over the physical machine.

Pros and cons, briefly

Where to host 1C: locally, in the cloud, on a rented server, or via web client

1C is the accounting backbone for most Russian companies, and the question of where it physically runs directly affects speed, availability, and total cost of ownership. There are four hosting options, and they aren't mutually exclusive — a business often starts with one and migrates to another over time.

A local install keeps the database on a computer or server in the office, accessible only from the local network. Simple and cheap to start with, but there's no external access without extra VPN setup, and backups and fault tolerance are entirely on you.

A cloud office moves 1C to a dedicated server with redundancy and encryption: employees connect from anywhere, and updates and backups become the provider's job. Renting a server for 1C is a similar approach but without the full service package — you get the compute, while configuration and administration are usually handled by you or ordered separately. 1C's web client gives browser-based access to the database with no thick-client installation — convenient for occasional work and mobile employees, but it demands a stable internet connection and doesn't always support the full configuration functionality.

Pros and cons, briefly

Secure short-message exchange

Don't trust even Threema or Signal, let alone Viber or Telegram? At the same time, secure exchange of messages, documents, and photos still matters to you?

The solution is your own Jabber server with an OMEMO encryption component. It's not a silver bullet against man-in-the-middle attacks or social engineering, but combined with a VPN and IP-based access restrictions, it noticeably improves security, confidence, and peace of mind.

Get in touch — I'll deploy and configure it for your needs.

A mail server for collaborative work

Calendars, convenient mail, shared file work. In the "enterprise" world, Microsoft Exchange is usually the first thing that comes to mind — but it's far from the only option.

Zimbra Collaboration Suite (ZCS) is a mature Exchange alternative with elements of Google Docs and Google Workspace. The product originated at the California-based company Zimbra: Yahoo! acquired it in 2007, the business moved to VMware in 2010, and then to Telligent Systems in 2013. ZCS is available in several editions, including a free Open Source Edition.

What's included

• Zimbra Web Client — an AJAX-based web interface with shared access to mail and calendars, advanced search, and Zimlet modules.
• Zimbra Desktop — a mail client for Linux, Windows, and macOS with POP/IMAP support and synchronization with Zimbra, Yahoo! Mail, and Gmail.
• Zimbra Server — a server for Linux or macOS with a full SOAP API and IMAP/POP3 access.

ZCS is compatible with Outlook and Apple Mail via its own modules, as well as with the open-source Novell Evolution — mail, contacts, and calendar transfer without loss. Sync with mobile devices is also supported.

Over 20 Zimbra deployments so far — get in touch.

Cloud office

All your files, applications, mail, private chats, client-bank, design work, and even your favorite yellow 1C move from the office to a dedicated, encrypted server with redundant hardware and full traffic encryption. The hosting country is your choice: Russia, China, and a number of other jurisdictions.

This is my core service: over 40 deployments across Russia and several in Europe.

Pros and cons, briefly

Pros: flexibility and scalability, access from anywhere, reliable data storage, efficient resource use.
Cons: dependency on an internet connection, and the need to trust the provider on data security — which is why encryption and access control are mandatory.

Protecting the RDP protocol

RDP (Remote Desktop Protocol) is a popular way to remotely access workstations and servers — and one of the most common attack vectors if left unprotected. A minimal set of measures worth enabling:

• A strong, unique password — not reused for other services.
• Two-factor authentication — a password plus a code from a separate device.
• Traffic encryption — TLS/SSL for the channel between client and server.
• VPN — for remote work, RDP connections should be wrapped in a VPN tunnel.
• Access restriction — only for the users and machines that need it, via IP whitelists.
• Regular updates — OS, antivirus, and the RDP server itself.
• Activity monitoring — tracking suspicious login attempts.
• Client privilege restriction — access only to their own files, not others'.
• Disabling unneeded features — printer, drive, and audio redirection, if not required.
• Log review — regular audits of server events.

These measures don't replace one another — they complement each other: the more layers of protection, the lower the chance of a successful attack.