Windows 11’s September Patch Tuesday cumulative, KB5065426 (OS Build 26100.6584), has been linked to widespread file- and print-sharing failures on some machines, with multiple community threads and Microsoft Q&A posts reporting disabled sharing settings, networks switching from Private to Public, repeated credential rejections (“The username or password is incorrect”), and — in many cases — restoring functionality only after uninstalling the update. (support.microsoft.com)
Microsoft published KB5065426 on September 9, 2025 as a combined Servicing Stack Update (SSU) + Latest Cumulative Update (LCU) for Windows 11, version 24H2 (OS Build 26100.6584). The package bundles security fixes, quality improvements, and updated on-device AI components for Copilot+ hardware, and explicitly documents the SSU coupling — an operational detail that complicates simple rollbacks because the SSU portion is not removable via the wusa /uninstall route. (support.microsoft.com)
The release also enables additional SMB auditing hooks designed to help administrators evaluate compatibility before enforcing stricter SMB signing and Extended Protection for Authentication (EPA) policies. Those hardening and auditing additions are deliberate security steps, but the change has revealed compatibility problems with legacy SMBv1 devices, NetBIOS/NetBT transports, and certain cloned imaging scenarios in the field. (support.microsoft.com)
At the time the community reports emerged, the most reliable immediate remediation for many affected users was uninstalling the LCU — an action that restores previous behavior at the expense of reintroducing patched vulnerabilities. Microsoft Q&A guidance offers safer first steps (re-setting network types to Private, re-enabling sharing, using SMB auditing to map incompatibility, and targeted, temporary policy exceptions for legacy devices). For environments with large fleets and legacy devices, the best path is to pause KB5065426, pilot thoroughly, and remediate imaging/SID and device-compatibility problems before broad deployment. (learn.microsoft.com)
If you manage Windows endpoints at scale, prioritize staged rollouts, SMB auditing, and firmware/PKI readiness as part of an integrated remediation plan; these steps reduce the likelihood you'll face the very outages this update has uncovered while preserving the hardening gains Microsoft is trying to deliver.
Source: Windows Report September Patch Tuesday Update KB5065426 Breaks File and Print Sharing
Background / Overview
Microsoft published KB5065426 on September 9, 2025 as a combined Servicing Stack Update (SSU) + Latest Cumulative Update (LCU) for Windows 11, version 24H2 (OS Build 26100.6584). The package bundles security fixes, quality improvements, and updated on-device AI components for Copilot+ hardware, and explicitly documents the SSU coupling — an operational detail that complicates simple rollbacks because the SSU portion is not removable via the wusa /uninstall route. (support.microsoft.com)The release also enables additional SMB auditing hooks designed to help administrators evaluate compatibility before enforcing stricter SMB signing and Extended Protection for Authentication (EPA) policies. Those hardening and auditing additions are deliberate security steps, but the change has revealed compatibility problems with legacy SMBv1 devices, NetBIOS/NetBT transports, and certain cloned imaging scenarios in the field. (support.microsoft.com)
What users are reporting: symptoms and numbers
- Shared folders and network printers become unreachable after installing KB5065426; some machines see File and Printer Sharing and Network Discovery toggled off, and network profiles changed from Private to Public. (learn.microsoft.com)
- Repeated credential prompts appear when connecting to known shares, often ending in “System error 86” or a plain “The username or password is incorrect,” even when credentials are correct. (windowslatest.com)
- In some environments with large numbers of cloned or imaged machines, admins report that machines with identical or near-identical SIDs (security identifiers) can no longer authenticate with each other after the update. Community diagnostics point to SID-related authentication blocks in many of these cases. (learn.microsoft.com)
- Where the update is installed on both client and server, some SMBv1/NetBIOS-based shares become unreachable; users relying on legacy NAS devices or embedded printers report the worst impact. (windowsforum.com)
Why this likely happened: a technical analysis
1) SSU + LCU composition and hardening behavior
KB5065426 is delivered as a combined SSU+LCU package. SSUs are designed to harden the servicing stack and improve subsequent installs, but once an SSU lands it cannot be removed using the ordinary wusa uninstall approach. The coupling adds complexity to rollbacks and means that any behavioral changes introduced by the servicing stack are effectively persistent until Microsoft ships a corrective servicing update. This increases the operational risk of any behavioral regressions introduced by the combined package. (support.microsoft.com)2) SMB hardening, auditing, and compatibility fallout
The update explicitly enables SMB server-side auditing for signing and EPA, which is intended to let admins discover clients that would fail under stricter enforcement. However, the same auditing and hardening logic can cause previously tolerated behavior to be blocked, especially on legacy SMB stacks and devices that rely on insecure guest access, weak signing, or NetBIOS transports. When auditing discovers a compatibility gap, the system may default to more conservative access rules — effectively blocking or rejecting authentication flows that previously succeeded. This behavior explains why some file/printer sharing stops working even after re-enabling sharing toggles. (support.microsoft.com)3) SMBv1 / NetBIOS interactions
Microsoft has acknowledged connection failures affecting SMBv1 over NetBIOS (NetBT) after the September updates. Systems that still depend on SMBv1 — either because of legacy NAS appliances, older printers, or embedded devices — become a high-risk group. When both endpoints are updated to the hardening-aware stack, the legacy SMBv1 negotiation can fail in new ways that manifest as unreachable shares. (windowsforum.com)4) Duplicate SIDs and imaging issues (community hypothesis)
A consistent pattern in community threads is that cloned machines with identical machine SIDs (a common side-effect of poor imaging processes) suddenly fail to authenticate to one another after KB5065426 is installed. Community troubleshooting indicates that the update surfaces SID-based checks or changes in how SMB/NTLM/Kerberos flows bind principal identifiers, so identical SIDs between hosts can prevent session acceptance until a new unique SID is assigned (via Sysprep) or a new local user is created. This SID theory is strongly supported by multiple administrators’ tests but is not documented as an official Microsoft root cause at the time of writing, so treat it as community-derived but plausible. (learn.microsoft.com)What Microsoft has said (and what it has not)
- The official KB entry confirms the release date (September 9, 2025), OS build (26100.6584), and the combined SSU+LCU packaging. It documents known PSDirect hotpatch edge cases and provides guidance for DISM-based rollback of the LCU only, while reiterating that SSUs are effectively permanent until updated. (support.microsoft.com)
- Microsoft Q&A threads contain moderator responses that outline the observed behavior: the update can reset network profiles to Public, disable Network Discovery and File and Printer Sharing, and block insecure guest logons — all security-conscious defaults. The moderator-guided troubleshooting steps include re-setting the network to Private, re-enabling sharing, and (if necessary) re-allowing insecure guest auth or SMB1 temporarily for legacy devices — but the posts also warn these are security trade-offs and that removing the update restores functionality. (learn.microsoft.com)
- Microsoft has not, in its KB release note, published an explicit, single-line “we introduced a bug that blocks file sharing” statement; instead, the evidence in Microsoft’s forums and Q&A, combined with the KB’s documented hardening additions, frames a scenario where security enforcement uncovered compatibility gaps. That means while Microsoft recognizes related connectivity regressions (and has acknowledged SMBv1 issues), there is no single official “file sharing is broken by KB5065426” bulletin at the KB’s main page beyond forum guidance and known issue notes. (support.microsoft.com)
Practical mitigations and what actually works in the field
The community and Microsoft Q&A moderator guidance converge on a small set of pragmatic steps. Note: each of these has trade-offs; several reduce security posture and should be treated as temporary mitigations while awaiting a proper fix from Microsoft.Safe, preferred operational steps
- Pilot and hold: Delay broad deployment of KB5065426 in environments that rely on file/print sharing (especially SMBv1 devices or large fleets of imaged machines). Test in a controlled ring first.
- Use SMB auditing to map compatibility: Enable the new SMB auditing hooks so you can see which clients fail signing/EPA checks and identify legacy devices before enforcing policies.
- Reboot and validate: After installing, verify Settings → Network & Internet → [network] → set to Private, re-enable Network Discovery and File and Printer Sharing under Advanced Sharing Settings, and restart both the server and client machines. Microsoft Q&A support suggests these steps first. (learn.microsoft.com)
Workarounds (use with caution; security risk increases)
- Allow insecure guest auth (Registry): For Windows Home and unmanaged devices, creating the registry value AllowInsecureGuestAuth = 1 under HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters can permit legacy guest-based shares to function again — but this re-enables an insecure authentication mode and should be avoided wherever possible. (learn.microsoft.com)
- Re-enable SMB 1.0/CIFS (Windows Features): Turn on SMB 1.0/CIFS support in “Turn Windows features on or off” for compatibility with very old devices. This is strongly discouraged long term; SMB1 is insecure and unsupported by modern best practices. (learn.microsoft.com)
- Change machine SIDs on cloned images: If your environment contains cloned machines with identical SIDs (a common imaging mistake), use proper sysprep /generalize or SID-change tools during imaging to ensure unique machine SIDs. Community responders have reported SID changes (via Sysprep or third-party SID tools) restore share access when the problem is SID-related. This addresses the root cause for cloned fleets and is preferable over enabling insecure protocols. Note: changing SIDs is intrusive and must be done with careful backups and testing. (learn.microsoft.com)
- Uninstall the LCU (last resort): Removing the LCU portion has restored functionality in many reported cases, but because the SSU is bundled, rolling back is non-trivial and may not remove all servicing changes. Microsoft documents DISM commands to remove the LCU package name but warns that SSU components remain. Uninstalling may also remove important security fixes; balance risk before choosing this option. (support.microsoft.com)
Step-by-step recovery checklist for sysadmins
- Pause updates for at-risk endpoints and schedule a staged test ring.
- Inventory your estate for: legacy SMBv1 devices, imaged/cloned endpoints (same machine SID), and critical printers/NAS appliances. Use PsGetSid from PSTools to detect duplicate SIDs if needed. (learn.microsoft.com)
- In a lab, install KB5065426 on representative hardware and reproduce the issue. Verify Event Viewer channels: SMBClient/SMBServer Operational logs and Security log for Event ID 4625 for related authentication failures.
- If cloning/SID issues are present, plan a sysprep/regenerate-SID remediation rather than enabling insecure fallbacks. Create and test images with sysprep /generalize to ensure unique SIDs.
- If legacy devices must be supported temporarily, document and apply the minimum required insecure workaround (e.g., AllowInsecureGuestAuth registry, SMB1) and place those devices on an isolated VLAN with tight firewall rules. Revoke these exceptions as soon as possible. (learn.microsoft.com)
- If rolling back the update is necessary, remove only the LCU via DISM and follow Microsoft’s guidance for package names and removal; maintain backups and a plan to reapply security patches once a fix is available. (support.microsoft.com)
Why some “fixes” are risky
- Re-enabling SMB1 or AllowInsecureGuestAuth re-introduces long-known vulnerabilities (relay attacks, lack of signing, weak authentication), so these should only be used as temporary compatibility measures with compensating network controls.
- Uninstalling the cumulative update removes high-severity security fixes included in the rollup. That reduces the attack surface protections delivered by the monthly patch and exposes endpoints to known CVEs. Any rollback should be done with an active compensating-control plan (IDS/EDR tuning, network segmentation). (support.microsoft.com)
- Changing SIDs en masse is operationally heavy and can cause side effects with domain joins, licensing, and local profiles. Test thoroughly before mass application. (learn.microsoft.com)
Monitoring and verification after remediation
- Confirm OS Build: run winver or check Settings → System → About to verify whether the device is on OS Build 26100.6584 or earlier/later. (support.microsoft.com)
- Track Event Logs: SMBClient and SMBServer Operational channels for audit entries, plus Security Event ID 4625 for authentication rejections, and application/service logs for print spooler errors.
- Use network scanning and SMB audit telemetry to identify legacy devices still depending on weak authentication or lacking signing support. Maintain a remediation list and timeline.
What to expect next and the bottom line
Microsoft’s KB shows that this release was intended to address security gaps and several functional regressions from earlier August servicing, and it deliberately moved SMB hardening and auditing forward as part of a multi-year roadmap. Those hardening steps are necessary to reduce entrenched Windows network attack vectors, but they also increase the chance of surprise operational outages where legacy devices or imaging mistakes remain unaddressed. (support.microsoft.com)At the time the community reports emerged, the most reliable immediate remediation for many affected users was uninstalling the LCU — an action that restores previous behavior at the expense of reintroducing patched vulnerabilities. Microsoft Q&A guidance offers safer first steps (re-setting network types to Private, re-enabling sharing, using SMB auditing to map incompatibility, and targeted, temporary policy exceptions for legacy devices). For environments with large fleets and legacy devices, the best path is to pause KB5065426, pilot thoroughly, and remediate imaging/SID and device-compatibility problems before broad deployment. (learn.microsoft.com)
Recommendations for IT managers and power users
- Hold Patch: Delay deployment of KB5065426 to production endpoints that rely heavily on peer-to-peer file and print sharing until you have tested in a pilot ring.
- Inventory and Remediate: Use SMB audit hooks to map clients that will fail signing/EPA checks, and phase out SMBv1 and insecure guest access devices.
- Fix Imaging: If you use imaging/cloning, ensure every deployed image runs sysprep /generalize or a sanctioned provisioning process that generates unique machine SIDs. This prevents duplicate-SID authentication failures exposed by the update. (learn.microsoft.com)
- Prepare Rollback Plans: If rollback becomes necessary, test DISM /Remove-Package removal of the LCU in a lab, and maintain backups and timeline for re-patching when Microsoft issues a corrective update. (support.microsoft.com)
- Isolate Legacy Devices: Place any temporarily re-enabled SMB1 or guest-auth devices on an isolated VLAN, restrict inbound access, and document exceptions for later removal. (learn.microsoft.com)
Conclusion
KB5065426 was a sizable, security-focused September rollup intended to fix pressing vulnerabilities and reduce regressions introduced earlier in the servicing cycle. However, its combined SSU+LCU packaging and the activation of SMB auditing and hardening features have exposed real-world compatibility gaps: disabled sharing settings, lost printer/file access, failed credential authentication, and problematic interactions in fleets with cloned SIDs. The most prudent course for organizations that depend on file and print sharing is to pause broad installation, run targeted pilots, inventory legacy SMB dependencies, and remediate image/SID issues before deploying the update widely. For home users and SMBs who must restore immediate functionality, documented temporary workarounds exist — but they carry real security trade-offs and must be treated as stopgaps until an official corrective from Microsoft is available. (support.microsoft.com)If you manage Windows endpoints at scale, prioritize staged rollouts, SMB auditing, and firmware/PKI readiness as part of an integrated remediation plan; these steps reduce the likelihood you'll face the very outages this update has uncovered while preserving the hardening gains Microsoft is trying to deliver.
Source: Windows Report September Patch Tuesday Update KB5065426 Breaks File and Print Sharing
