Microsoft’s September Remote Desktop Repair Needs the Right Windows Build
September disrupted some RDS sessions. Plan for failure of that management path during update work.
Update, 13 October 2026: Microsoft currently marks the September Remote Desktop Services issue resolved. Out-of-band updates released on 14 September, and updates released later, carry the repair for affected Windows versions. A separate Citrix and FSLogix black-screen condition can still appear after a Remote Desktop connection succeeds.
The security decision remains operational. Keep the September protections while checking that the change restored the service users need.
Which update repairs RDS?
Windows Server 2025 release health names KB5129235 as its repair example. Windows 11 24H2 release health names KB5129195. These examples are version-specific, so use the entry for each device rather than one KB across the estate.
The out-of-band repair is cumulative and includes earlier security protections.
The earlier virtual-machine deallocation guidance is historical rather than the current remedy.
BlackTree’s separate Citrix and FSLogix report covers a black desktop after sign-in. Microsoft’s Windows 11 24H2 page still labels that distinct condition mitigated.
Check the affected Windows version
For context, Windows Server 2025 lists KB5122871, OS Build 26100.33438, as its originating update. The Windows 11 26H1 record lists KB5124012, OS Build 28000.2954, as its originating update and KB5129194 as its repair.
Why rollback remains exceptional
The September release contains security fixes, including vulnerabilities Microsoft reported as exploited. BlackTree’s Patch Tuesday analysis explains those separate attack paths. A broad uninstall can reopen them.
Make any exceptional rollback a documented service and security decision. Record which protections it removes, the compensating controls and the recovery route. Set a return date and a service-level exit check before taking that risk.
A practical RDS repair checklist
- Identify dependencies. Include session hosts, brokers, licensing servers, jump hosts and machines whose only practical management route is RDP.
- Map the installed build. Capture each device’s OS version, build and update in the change record.
- Pilot the repair. On representative hosts, test a connection, sign-in, session stability and the licensing or management tool those hosts use. Record results before broad rollout.
- Confirm another management route. Test authorised hypervisor, cloud-console, lights-out-management or local access before maintenance.
- Account for service dependencies. For virtual machines, record active sessions, broker or cluster failover, storage dependencies and restart impact. Schedule the repair so users and dependent services have a tested return path.
- Preserve evidence. If a system fails, collect relevant events, service state, update history and timing before a disruptive restart where possible.
- Avoid estate-wide uninstall. Escalate exceptional impact through the change and risk process, including the security exposure a rollback would restore.
- Close the change. Record the installed build and repeat the pilot. Route a remaining black desktop to the separate Citrix and FSLogix investigation.
What the public record cannot prove
Microsoft’s public RDS entry gives no detailed root cause or complete trigger matrix, and it does not describe a compromise. Service checks determine whether dependent systems recovered.
Before the next RDS maintenance window, document the plan and confirm an independent administrative route. A black desktop after sign-in calls for a separate investigation.
