September 2026 Windows updates: the RDS and WSL regressions are fixed — install the September 14 out-of-band update

Updated 2026-10-15 · source: Microsoft Windows release health, re-read 2026-10-15 (previous updates 2026-10-11 and 2026-09-16; originally compiled 2026-09-11)

🔄 Updated 2026-10-15: USB audio is now Resolved on Windows Server 2022 by KB5129237, and still Mitigated elsewhere (details below). October's side effects have their own page: October 2026 known issues. That page covers the Windows Server update that can take Exchange offline, and the NTLMv1 change that breaks MS-CHAPv2 Wi-Fi and VPN sign-in.

🔄 Updated 2026-10-11 — two items on this page are now RESOLVED. (1) The secure channel / domain trust failures this page said Microsoft had not acknowledged: Microsoft opened a known issue on 2026-09-16 and resolved it with the 2026-09-22 updates (KB5124010 on Windows 11 24H2/25H2, KB5124006 on 26H1). The cause was machine identity isolation, the lead this page set out. (2) The false "Defender is turned off" notifications are Resolved in Defender platform 4.18.26080.4. USB audio is unchanged: still only partially fixed. Details below; what changed is listed at the end.

⚠️ This page changed substantially on 2026-09-16. When it was first published on 2026-09-11, the two September regressions below were Confirmed with no fix, and this page told you to hold the September update on RDS hosts and WSL workstations. Microsoft shipped out-of-band fixes on 2026-09-14 and both issues are now Resolved. That advice is withdrawn — the action now is to install the OOB update, not to keep deferring. A third issue (USB audio) has since been opened and is only partially fixed. The corrected detail is below, and what changed is listed at the end.

The September 2026 Windows security updates fix three actively exploited vulnerabilities. They also introduced three regressions — two of which Microsoft resolved with out-of-band updates on 2026-09-14, and one of which is still only partially fixed. This page is the second half of the picture our monthly patch brief gives you: that one says what to patch, this one says what to watch when you do.

---

✅ Resolved 2026-09-14: Remote Desktop Services can stop responding

Microsoft opened this on 2026-09-11 at 11:19 PT, marked it Confirmed the same hour, and marked it Resolved on 2026-09-14 at 10:00 PT.

What happened. After installing the September 2026 security update, Microsoft said some organisations "might experience issues with Remote Desktop Services (RDS)." In affected environments RDS became unstable, with:

• RDP connections failing after several minutes
• sign-in issues
• servers hanging at "Please wait for the Remote Desktop Configuration"
• Microsoft Management Console (MMC), the RDS Licensing Diagnoser and File Explorer also becoming unresponsive
• the Windows Update page itself hanging on a permanent loading indicator

That last symptom still deserves its own line, because it shapes recovery. If the Windows Update page will not load, the first tool an administrator reaches for to check what was installed is the tool that stops working — so on exactly the hosts that need the OOB update, confirming update state may need a different route than the Settings UI.

Who was affected. Microsoft names 14 platforms — 8 client, 6 server.

Fix status: RESOLVED by the out-of-band updates released 2026-09-14, and by any update released after that date. The OOB updates are cumulative. Administrators who deployed a Group Policy mitigation for this issue do not need to take any action before installing it.

✅ = resolving KB read directly on Microsoft's own page for that platform on 2026-09-15/16. ⚠️ = taken from Microsoft's release-health notification for the related Plan9 issue and not re-read on that platform's web page; treat it as a strong pointer and confirm before you deploy. check your platform's page = we did not read it, so we are not stating it — the resolving KB for those rows is on each platform's own release-health page. We would rather send you to the source than print a KB number we have not seen.

---

✅ Resolved 2026-09-14: host folder shares break in Hyper-V Linux VMs (this broke WSL) — and there is a Group Policy catch

Opened 2026-09-11 at 02:22 PT, Resolved 2026-09-14 at 10:00 PT.

After installing the September 2026 security update, applications using HCS-managed virtual machines could fail when sharing host folders with Linux guests over Plan9. The virtual machines started normally — which is what made this one slippery — but folders shared from the Windows host did not appear, or could not be accessed, inside the guest. Affected applications may have reported that no Plan9 drive shares were mounted.

Microsoft explicitly names Windows Subsystem for Linux (WSL) and Claude Cowork as affected applications. Standard Hyper-V virtual machines that do not use the Plan9 feature were unaffected.

Affected: Windows 11 26H1, 25H2, 24H2, 23H2 and Windows 10 22H2 and 21H2. No server platforms.

Fix status: RESOLVED by the 2026-09-14 out-of-band updates (KB5129195 on Windows 11 25H2/24H2, KB5129236 on Windows 10 22H2) and by updates released after that date.

🔴 Do not stop at "install the OOB" on this one. Microsoft updated the resolution section on 9/14 with a step that is easy to miss and that reverses the advice for the sibling RDS issue: "IT administrators who deployed a temporary mitigation through Group Policy must re-enable the Group Policy, install this OOB update, and restart to resolve this issue."

So for this issue, if you deployed the Group Policy mitigation, installing the update alone is not enough — you must re-enable the policy and restart. For the RDS issue, Microsoft says the opposite: no action needed. Two issues, shipped in the same OOB, with opposite instructions about the same kind of mitigation. If you deployed GPO mitigations for both, handle them separately.

Why this one got misdiagnosed. The failure presented as "my tooling can't see my files", not as a patch problem. A developer workstation that installed the September update overnight looked healthy: the VM booted, the terminal opened, and only the shared path was missing. If this reached your service desk last week as a broken dev environment, this is what it was.

---

🟡 Opened after this page was first written — USB audio devices, and it is only PARTIALLY fixed

This one opened on 2026-09-11 at 18:36 PT, after the original version of this page was compiled, so it was never covered here. It is still open.

After installing the September 2026 security update, some USB Audio Class 1.0 devices may fail to start or produce audio. Symptoms:

• Device Manager shows "This device cannot start (Code 10)"
• no audio output
• volume controls unresponsive or stuck at zero
• sound settings unresponsive or unavailable
• devices that work in standard stereo but fail in multichannel modes (8-channel or 3D audio)

Update 2026-10-15: on Windows Server 2022, Microsoft now marks this issue Resolved by KB5129237 (entry last updated 2026-10-13 11:02 PT). On Windows 11 25H2 it is still Mitigated (last updated 2026-09-29). Check your own platform's release-health page; we did not re-read every platform.

Fix status: PARTIALLY resolved — and the distinction matters. Microsoft's status for this issue is Mitigated, not Resolved. The 2026-09-14 OOB update (KB5129195 / KB5129236 and the other platform equivalents) resolves only the last symptom — the multichannel / 8-channel / 3D audio failures. The Code 10, no-audio, dead-volume and dead-sound-settings symptoms are not addressed yet. Microsoft says it is still working on them and directs administrators who need an immediate workaround for the remaining symptoms to Microsoft Support for Business.

The previously circulating advice to switch affected devices to 2-channel mode applied to the symptom the OOB has now fixed.

Affected: the full client range (Windows 11 26H1 through Windows 10 21H2, plus LTSC 2019 and 2016) and the full server range (Windows Server 2025, 2022, 2019, 2016, 2012 R2, 2012). Limited to USB Audio Class 1.0 devices.

---

✅ Resolved 2026-09-30: false "Defender is turned off" notifications (from August)

Update 2026-10-11: Microsoft marked this Resolved on 2026-09-30. The fix is Microsoft Defender Antivirus platform update 4.18.26080.4, released 2026-09-17; the issue began with platform 4.18.26070.9 (2026-08-05). If you still see these notifications, check that the device has taken the 4.18.26080.4 platform update. The original description follows.

Not a September-update issue, and as of 2026-09-15 it was still Confirmed and unresolved.

After recent Microsoft Defender Antivirus updates, devices may show notifications claiming "Microsoft Defender Antivirus is turned off" while Defender is in fact running normally and all settings show it as active. The notifications can appear at start-up and intermittently afterwards, and persist even when notification settings are turned off. Microsoft has no originating KB for this one — it tracks to Defender platform updates rather than a Windows cumulative update — and says a resolution will come in a future Defender Antivirus update.

Affected across the full client and server range. If your monitoring alerts on Defender state from notification text rather than from Defender's own reported status, this will generate false alarms.

---

✅ What the September update fixed — the case against blanket deferral

With the two big regressions now resolved, the argument for holding September is weaker than it was, and it was already weak.

First, the September updates close three actively exploited vulnerabilities — see the monthly brief. Deferral is not a neutral act; it is a decision to stay exposed to bugs that are being used right now.

Second, KB5124008 is itself the fix for three August regressions:

• Microsoft Teams and new Outlook failing to launch on ARM devices (from the August update KB5121003) — resolved by KB5124008
• Mouse customisation reset on non-English Windows (from KB5120998) — resolved by KB5124008
• Desktop background settings lost or reverting to solid black (from KB5120998) — resolved by KB5124008

Holding September to avoid the RDS issue keeps those three in place — and now also keeps you off the OOB that fixes the very thing you were holding for.

---

✅ Resolved 2026-09-22: domain-joined devices losing their secure trust relationship — Microsoft acknowledged it on 2026-09-16

Update 2026-10-11. Microsoft opened the known issue "Domain-joined devices might lose their secure trust relationship with the domain" on 2026-09-16 at 14:15 PT, the day after this page last checked, and it is now Resolved. Per Microsoft:

• Trigger: the September 8 update (KB5124008; KB5124012 on 26H1) or the September 14 out-of-band update.
• Who: some Credential Guard protected machine accounts, which lose their secure channel with on-premises AD.
• Cause: the updates made Windows start honouring existing or policy-provisioned Machine Identity Isolation enforcement settings. That configuration is only supported against domain controllers at Windows Server 2025 domain functional level.
• Fix: the 2026-09-22 updates — KB5124010 on Windows 11 24H2 and 25H2, KB5124006 on 26H1 — and every later update "prevent Machine Identity Isolation (MII) enforcement by disabling it completely while improvements are made to the feature".
• Workarounds: if you install those updates, you do not need one. Microsoft lists Known Issue Rollback, or disabling MII through whatever set it, for devices still on earlier builds, followed by Test-ComputerSecureChannel -Repair.

So the hypothesis below was right: this was machine identity isolation in enforcement mode. The original 2026-09-15 analysis is kept underneath for the record. Its caution about the registry change still matters for anyone on a pre-September-22 build.

As written 2026-09-15: what was not yet on Microsoft's known-issues list

There has been public discussion — including a detailed Microsoft Q&A thread opened 2026-09-09 — reporting that KB5124008 breaks the machine secure channel / domain trust relationship on Windows 11 25H2 (build 26200.9445) against Windows Server 2019 domain controllers.

We re-checked Microsoft's list on 2026-09-15 at 17:24 UTC, and there is still no such entry. No secure-channel, Netlogon, domain-trust or domain-logon issue appears on the Windows 11 25H2 known-issues page — not as Confirmed, not as Investigating. Four days on from the original check, with two other September issues opened, resolved and documented in the meantime, claims that "Microsoft has acknowledged this and a fix is in progress" remain unsupported by Microsoft's own record.

But absence from a known-issues list is not the same as "not real", and here there is a second explanation worth taking seriously: this may be documented behaviour rather than an unacknowledged bug.

The reported symptoms map closely onto Microsoft's own documentation for Credential Guard protected machine accounts / machine identity isolation, controlled by HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MachineIdentityIsolation and by the Group Policy setting Computer Configuration → Administrative Templates → System → Device Guard → Turn On Virtualization Based Security → Machine Identity Isolation Configuration. Its states are:

Three things in Microsoft's documentation line up with what is being reported:

1. Cached credentials masking the failure. Microsoft: "If local cached logon is enabled when this setting is disabled, local logon will still work while the cache is fresh, but domain authentication will break." That is precisely the reported pattern — users keep working, machine authentication is already gone.
2. Repair cmdlets not being enough. Reports say Reset-ComputerMachinePassword and Test-ComputerSecureChannel -Repair do not fix it and a full domain leave/rejoin is required. Microsoft documents exactly that consequence for moving off enforcement mode: "the device must be unjoined and rejoined to the domain, as it's unable to authenticate otherwise."
3. A documented failure mode with the same outcome. Microsoft: "if Credential Guard fails to start after a device reboot, it results in the inability to complete domain authentication, potentially requiring intervention from a local administrator account to recover."

⚠️ What we have NOT verified, and will not assert: we have no evidence that KB5124008 enables, re-enables or changes the default of machine identity isolation. That is the obvious hypothesis given the timing, and it is only a hypothesis. Microsoft's documentation carries a standing note that the feature was temporarily disabled from the April security update (KB5055523) over a Kerberos machine-password-rotation problem and "remains disabled until a permanent fix is available." Whether that changed in September, and whether Server 2019 domain controllers are supported on this path at all, are open questions we cannot answer from published sources. Treat the mapping above as a strong lead for your own diagnosis, not as a root cause.

🔴 About the registry "workaround" circulating publicly

A mitigation being shared publicly sets MachineIdentityIsolation from 2 to 0 and then repairs the secure channel. Understand what that is before you run it: it turns off a security hardening control — it takes your machine account password back out of Credential Guard's protected execution environment and returns it to the registry, which is the exact exposure the feature exists to close (machine account secrets "can be easily extracted from the registry"). It is not a hotfix; it is a decision to stop using a protection.

It also has a documented cost that a one-line registry tip tends to omit: per Microsoft, moving from enforcement mode to Disabled leaves the device unable to authenticate until it is unjoined and rejoined to the domain, and only the local administrator account can perform that unjoin and rejoin. If you have no working local administrator credential on an affected machine, find that out before you change the value, not after.

We are not recommending that change. If machine identity isolation is in play in your environment, the lower-risk direction is audit mode (1), which Microsoft documents as falling back to the LSA copy when Credential Guard authentication fails — but that is still a hardening reduction, it still needs testing, and if the policy is currently in enforcement mode the unjoin/rejoin consequence may still apply. Check your own Group Policy state first: this setting may simply not be configured in your estate, in which case none of this is your problem.

What to actually do

If you held the September update on RDS, terminal servers or VDI: that hold has done its job and should now end. Install the 2026-09-14 out-of-band update for those platforms — it carries the September security content and the RDS fix, because the OOB updates are cumulative. You do not need to remove the September cumulative first, and if you deployed a Group Policy mitigation for the RDS issue, Microsoft says no action is needed before installing.

If you removed the September cumulative to recover an RDS host: the OOB is the way back on. Removing the update left those hosts without three exploited-vulnerability fixes; that is the exposure the OOB closes.

If you run developer workstations on WSL (or Claude Cowork): install the OOB — and if you deployed the Group Policy mitigation for the Plan9 issue, re-enable that policy, install the update, and restart. Installing the update alone will not resolve it. This is the opposite of the RDS instruction; do not carry one across to the other.

If you have USB audio problems: the OOB fixes the multichannel/8-channel/3D symptom only. If your symptom is Code 10, silence, or dead volume controls, there is still no fix — that is a support case, not a patch.

Everywhere else: patch on your normal cycle, and take the OOB with it.

If you are seeing domain logon failures: triage before you conclude anything.

1. Run Test-ComputerSecureChannel. If it returns True and your symptoms involve RDP or terminal servers, you were most likely looking at the RDS issue above — now fixed by the OOB — not a secure-channel problem. Microsoft's RDS entry explicitly listed "sign-in issues" among its symptoms, and conflating the two sent people down the wrong path for several days.
2. If it returns False, corroborate with nltest /sc_query:<domain> and check the domain controller Security log for Event 4625 against the computer account (HOST$).
3. Then check whether machine identity isolation is configured in your estate — Group Policy under Device Guard, or the MachineIdentityIsolation value — before treating this as an unexplained patch bug. If it is set to enforcement mode, read the section above carefully, including the unjoin/rejoin consequence, before changing anything.
4. Install the September 22 update or later (KB5124010 on 24H2/25H2, KB5124006 on 26H1). (Updated 2026-10-11 — this step previously said there was no Microsoft entry.) Microsoft acknowledged and resolved this issue: those updates disable machine identity isolation enforcement entirely. On a machine that is already broken, follow the update with Test-ComputerSecureChannel -Repair.

However you decide: decide per workload, not per estate. The pattern in every one of these issues is that they hit specific roles — RDS hosts, Plan9/WSL users, USB audio devices — and leave the rest of the fleet alone.

---

What changed on this page since 2026-09-11

2026-10-15:

2026-10-11:

2026-09-16:

---

Updated 2026-10-15 from Microsoft's Windows release health documentation (re-read 2026-10-15; previously 2026-10-11 and 2026-09-15 at 17:24 UTC). Known-issue status, affected platforms and fix availability change without notice — verify against Microsoft's current page before acting on anything here. Prepared for practitioners. Not affiliated with, or endorsed by, Microsoft.

Sources

Microsoft documentation below was read on 2026-09-15/16 unless otherwise noted. The secure-channel and Defender resolutions were read on 2026-10-11.

• Windows Server 2022 known issues and notifications (Microsoft). Source for USB audio Resolved by KB5129237 on Server 2022 (read 2026-10-15).
• Windows 11, version 25H2 known issues and notifications — Microsoft. Primary source for the September issue statuses, the resolving KB5129195, the Group Policy re-enable instruction on the Plan9 issue, the USB audio partial-resolution wording, and for the verified continued absence of any secure-channel entry. Page last updated 2026-09-15 17:24 UTC.
• Windows 11, version 26H1 known issues and notifications — Microsoft. Source for the 26H1 secure-trust entry: originating KB5124012, resolved KB5124006 (read 2026-10-11).
• Windows 11, version 24H2 known issues and notifications — Microsoft. Corroborates the same three issues and KB5129195 on 24H2.
• Windows 10, version 22H2 known issues and notifications — Microsoft. Source for the Windows 10 originating update KB5122878 and the resolving KB5129236.
• KB5129237 — Windows Server 2022 out-of-band update, 2026-09-14 — Microsoft. Source for the Server 2022 resolving KB and confirmation that it addresses both the RDS instability and the USB audio multichannel symptom.
• Credential Guard protected machine accounts in Windows Server 2025 — Microsoft. Source for the machine identity isolation states (Disabled / audit / enforcement), the Group Policy path, the cached-logon and unjoin-rejoin consequences quoted above, and the standing note that the feature was temporarily disabled from the April security update (KB5055523) pending a fix for a Kerberos machine-password-rotation issue.
• KB5124008 (26200.9445) breaks machine secure channel / domain trust — Microsoft Q&A — ⚠️ user-submitted community content, not a Microsoft advisory. Cited only as evidence that the reports exist and for the diagnostic commands practitioners are using. No Microsoft representative had responded on the thread at the time of writing. We have not independently reproduced any of it.

Compiled by patchtriage.com. We verify against vendor primary sources and say so when we cannot.