September 2026 Update Breaks RDS on Windows Server: Two Real Fixes (KB5129235 and the Known Issue Rollback)

Windows Server’s September 2026 cumulative update, KB5122871, broke Remote Desktop Services on Windows Server 2019, 2022, and 2025. If your RDS environment started failing shortly after this patch went out, RDP connections dropping after a few minutes, sign-in getting stuck, servers hanging at “Please wait for the Remote Desktop Configuration”, you are not dealing with an unrelated infrastructure problem, you are dealing with a confirmed Microsoft regression with two real fixes. Here is both, and how to pick the right one for your situation.

What the bug actually looks like

Affected environments show RDS becoming unstable in a way that is easy to initially misdiagnose as a network or licensing problem:

• RDP connections that establish successfully but fail after several minutes of use.
• Sign-in getting stuck, sometimes requiring a hard reset of the affected server to restore functionality.
• Servers hanging at the “Please wait for the Remote Desktop Configuration” screen during connection.
• Related management tools becoming unresponsive alongside the RDS failures, including the Microsoft Management Console (MMC), the RDS Licensing Diagnoser, and File Explorer.

If you are seeing this combination, particularly the MMC and File Explorer symptoms alongside RDP failures, check your patch history for KB5122871 before spending time on network or certificate troubleshooting, since this is a known platform-level regression, not something specific to your environment’s configuration.

Fix 1: install the out-of-band update

Microsoft released KB5129235 as an out-of-band (non-security) cumulative update on September 14, 2026, specifically to resolve this. This is the straightforward fix: install it the same way you would any other cumulative update, through Windows Update, WSUS, or your patch management platform, and it fully resolves the RDS instability while keeping the security fixes from KB5122871 in place.

# Check your current build to confirm you're not already on the fix
Get-ComputerInfo | Select-Object WindowsBuildLabEx, OsHardwareAbstractionLayer

# Or check via the registry directly
(Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion").UBR

If your patch management process requires validation before broad deployment and you can’t push KB5129235 immediately, the Known Issue Rollback option below buys you time without reinstalling anything.

Fix 2: Known Issue Rollback (KIR), no uninstall required

Microsoft also published a Known Issue Rollback specifically for this regression, deployed through Group Policy, which reverses the specific behavior change causing the RDS instability without uninstalling KB5122871 or losing its security fixes. This is the right option if you need an immediate fix but aren’t ready to deploy the full out-of-band update yet.

The KIR works by writing a single DWORD value that disables the feature flag responsible for the regression:

# Registry path and value the KIR Group Policy configures:
# Key:   HKLM\SYSTEM\CurrentControlSet\Policies\Microsoft\FeatureManagement\Overrides
# Value: 1501792398
# Data:  0  (disabled, turns off the regression-causing feature flag)

To deploy it properly through Group Policy rather than a manual registry edit on each server:

1. Install the KIR MSI package (available through the Microsoft 365 admin center’s Known Issue Rollback section) on a machine you use to manage Group Policy.
2. Create a new GPO and link it specifically to the Organizational Unit containing your affected RDS servers.
3. Navigate to Computer Configuration → Administrative Templates → KB5122871 260911_18472 Known Issue Rollback within the GPO editor.
4. Set the policy to Disabled, which writes the registry value above and turns off the specific behavior causing the RDS failures.
5. Run gpupdate /force on affected servers, or wait for normal Group Policy refresh, then verify RDS connections stabilize.

A manual registry edit works for emergency single-server remediation, but Group Policy deployment is the right approach for anything beyond a handful of servers, both for consistency and for being able to reverse it cleanly once you’ve deployed the permanent fix.

Which fix should you actually use

If you can validate and deploy KB5129235 through your normal patch process without excessive delay, install it directly, it is the permanent fix and there’s no reason to run a workaround longer than necessary. Use the Known Issue Rollback specifically when you need RDS working again immediately and your patch validation process would otherwise leave affected servers broken for days. Once KB5129235 is deployed, remove the KIR Group Policy rather than leaving both in place indefinitely.

Frequently asked questions

Does this affect Windows Server 2016 or older, or only 2019/2022/2025?
The confirmed affected versions are Windows Server 2019, 2022, and 2025. If you are running an older, out-of-mainstream-support version and seeing similar symptoms, treat it as a separate issue rather than assuming the same fix applies, since the specific KB and feature flag referenced here are tied to updates for the confirmed affected versions.

Will uninstalling KB5122871 entirely also fix this, instead of using either option above?
It would remove the regression, but it also removes the security fixes that update shipped with, which is not a good tradeoff when both a direct fix (KB5129235) and a non-destructive rollback (the KIR) are available specifically to avoid that choice. Uninstalling a security update to work around an unrelated bug should be a last resort, not a first response.

How do I know if the Known Issue Rollback Group Policy actually applied correctly?
Check the registry value directly on an affected server after a Group Policy refresh: confirm the DWORD named 1501792398 exists under HKLM\SYSTEM\CurrentControlSet\Policies\Microsoft\FeatureManagement\Overrides and is set to 0. If it’s not present, verify the GPO is actually linked to the correct OU and that affected servers have processed a Group Policy update since the link was created.