OmniMend
Confirm the symptom matches Microsoft's incident
Microsoft describes a specific problem after the September 2026 security updates. Remote Desktop Services can become unstable. Connections may fail after several minutes, sign-in can fail, or a server can stop at the Remote Desktop Configuration message. Microsoft also notes that related tools, including Microsoft Management Console, RDS Licensing Diagnoser, File Explorer, and the Windows Update page, may stop responding in affected environments.
Use this article only when the timing, Windows version, originating update, and Remote Desktop symptom line up. A recent update is useful evidence, but timing alone does not make every connection, credential, licensing, network, firewall, or policy problem part of this incident.
- Connection or sign-in failed after the named September update. Continue with the version and build check.
- The host is stuck at Remote Desktop Configuration. Keep the administrator involved. Record the exact screen and endpoint role.
- Only one account or network fails. Preserve that boundary. The cause may be outside the Microsoft incident.
- The system is Windows Server or an RDS session host. Do not apply a consumer self-service sequence. Use the organization administrator and Microsoft guidance.
If the error wording or failure stage differs, save it. Do not force an unrelated Remote Desktop problem into the KB5124008 path because the dates are close.
Record the Windows version, build, and installed update
Before changing the system, open Settings > System > About and record the Windows edition, version, and OS build. You can also run winver. In Settings > Windows Update > Update history, record the recent KB numbers and installation dates.
Write down the device role, whether it is managed, the Remote Desktop client, the target, the exact message, and the failure stage. Separate a client that cannot start a connection from a host that accepts the connection and then hangs during sign-in or Remote Desktop Configuration.
Do not put passwords, recovery keys, private hostnames, public IP addresses, access tokens, or customer data in a public report. On a managed system, use the organization's approved incident record.
Match the Windows version to Microsoft's update
| Windows 11 version and starting update | Microsoft's corrective update | Corrected build |
|---|---|---|
| 24H2 after KB5124008 | KB5129195 or later | 26100.9457 or later |
| 25H2 after KB5124008 | KB5129195 or later | 26200.9457 or later |
| 26H1 after KB5124012 | KB5129194 or later | 28000.2956 or later |
| 23H2 after KB5122880 | KB5129242 through optional updates, or later | 22631.7584 or later |
Microsoft's release-health pages connect each starting update to the Remote Desktop Services problem. The September 14 out-of-band updates provide the fix. A later cumulative update can replace the exact package, so the final OS build matters more than finding an old package by name.
Do not choose an update from a forum post or from a nearby build number. Match the recorded Windows version first. If the computer uses an organization update ring, follow the administrator's deployment schedule and approval process.
Install the current update and retest once
Save open work and keep a portable computer on reliable power. Open Settings > Windows Update, check for updates, and install the current cumulative update offered for that Windows version. Version 23H2 may require the optional-updates route documented by Microsoft.
Use Windows Update by default. Do not download a package from a mirror. Ordinary readers should not pick a Microsoft Update Catalog package manually. A manual package requires an administrator to confirm the version, architecture, prerequisites, deployment policy, and rollback plan.
Restart when Windows requests it. After sign-in, check the OS build again. A downloaded package or pending restart is not a confirmed correction. When the build meets or exceeds the number in the table, repeat the same Remote Desktop connection or sign-in test once. Record the result and time.
If the connection works, stop changing the system. Keep the starting and corrected builds with the successful retest. That result supports this update path on the tested device, but it does not prove the cause of every Remote Desktop failure.
If the same Remote Desktop failure remains
First verify the Windows version and build again. Confirm that the corrected update installed successfully and that the required restart finished. Managed update tools can report a package as assigned before the computer reaches the corrected build.
If the build is current and the same symptom remains, preserve the before and after record. Include the Windows edition, version, OS build, originating and corrective KBs, device role, client, target type, exact message, failure stage, and one controlled retest result.
Send that record to the organization administrator or Microsoft. Do not answer an unchanged result by uninstalling security updates, killing services, changing policy, weakening the firewall, resetting Windows, or repeating connection attempts.
If Windows Update itself will not complete, use the Windows 11 update guide. If a driver update caused a different startup or hardware problem, use the driver-update recovery guide. Those branches do not replace the version and build check.
Keep Plan9 and general connection failures separate
KB5124008 also caused a separate Plan9 host-folder problem in some HCS-managed Linux virtual machines. That incident uses different symptoms and verification steps. If the message says that no Plan9 drive shares were mounted, use the Plan9 host-share guide.
A rejected password, expired account, unreachable host, licensing error, VPN problem, certificate warning, blocked port, or one-user failure can look like a Remote Desktop outage. Preserve the exact stage instead of applying the September fix to every connection problem.
Older reports may still recommend deallocating a virtual machine, rolling back the security update, or applying a temporary mitigation. Microsoft now lists corrective updates for the documented Windows 11 versions. The current safe sequence is version, starting update, corrective update, confirmed build, and one retest.
Where OmniMend fits
On a supported unmanaged Windows 11 x64 computer, OmniMend 2.0.9 can organize read-only Windows, update, event, configuration, and retest evidence around this symptom. Diagnosis is read-only. A supported repair inside OmniMend requires approval and a result check.
OmniMend does not install KB5129195, KB5129194, or KB5129242, repair Remote Desktop Services, manage a server, change organization policy, restore access, or support Windows Arm. Microsoft and the responsible administrator control the update and managed-environment response.
If you want a separate evidence record on a supported unmanaged Windows x64 PC, review OmniMend's diagnostic scope or download OmniMend. Read the privacy information before sharing a report.
Editorial sources
Checked September 16, 2026 against Microsoft's Windows 11 version 24H2 release-health page, Windows 11 version 26H1 release-health page, KB5129195 for versions 24H2 and 25H2, KB5129194 for version 26H1, and KB5129242 for version 23H2. Microsoft supplies the affected scope, starting updates, corrected builds, update route, and September 14 resolution. OmniMend added the version map, evidence order, safety limits, and product boundary. This article does not claim that every Remote Desktop failure is caused by the September update.