Microsoft’s September 2025 Patch Tuesday cumulative update for Windows 11 24H2 landed on September 9, and within hours IT forums lit up with reports of broken file and printer sharing. KB5065426 (OS Build 26100.6584), a combined Servicing Stack Update (SSU) and Latest Cumulative Update (LCU), was supposed to close security gaps and refine on-device AI for Copilot+ PCs. Instead, it triggered a cascade of authentication and connectivity issues that left many networks partially or completely severed. Shared folders vanished from Explorer, printers went offline, and repeated “The username or password is incorrect” prompts stymied users who knew their credentials were right. In dozens of community threads across Microsoft Q&A, Feedback Hub, and sysadmin forums, the common denominator was clear: uninstalling the update restored normal behavior immediately.

The scale of the disruption has been sobering. Some IT managers reported thousands of endpoints affected in a single environment, with production lines grinding to a halt because design files could no longer be pulled from central shares. Home users with simple multi-PC setups found themselves unable to print or stream media between family machines. The fallout exposes a dangerous chasm between Microsoft’s security ambitions and the messy reality of real-world networks, where legacy devices and decade-old imaging practices refuse to die without a fight.

What Symptoms Are Users Reporting?

Across dozens of community threads, the symptom list is remarkably consistent:

  • Shares become unreachable: Network drives mapped with valid credentials suddenly disconnect and refuse to reconnect. Folders that were shared to “Everyone” or “Homegroup” before the update now prompt for credentials that never work.
  • Network Discovery and File and Printer Sharing toggle off: After the update, many machines find these settings disabled in Advanced Sharing Settings. Even manually re-enabling them doesn’t always restore access, because the underlying SMB stack has changed its behavior.
  • Profile type flips from Private to Public: When Windows detects a network change, it sometimes reclassifies a trusted network as Public, which blocks sharing automatically. The update appears to trigger this reclassification, often without user intervention.
  • Credential rejection loop: When trying to access a share, the credentials dialog appears, then fails with “System error 86” or “The username or password is incorrect.” Users have confirmed that the same credentials work from Command Prompt using net use, but Explorer’s GUI path fails.
  • Legacy device deadlock: NAS boxes, old network printers, and embedded SMBv1 appliances stop responding. In mixed environments where only one endpoint receives the update, the legacy device might still work, but if both sides are updated, SMBv1 over NetBIOS (NetBT) often breaks completely.
  • Duplicate SID authentication blocks: Several administrators deploying identical machine images noticed that after KB5065426, machines with the same security identifier (SID) could no longer authenticate to each other. This points to a new sensitivity in how the SMB stack validates peer identities.

These are not isolated glitches. The pattern repeats across every major Windows support channel, and it has affected both workgroup and domain-joined machines. Notably, the issue is not limited to a specific hardware configuration or OEM; users on the latest Dell, HP, and custom builds alike have been caught.

Why Is KB5065426 Breaking Sharing? A Technical Breakdown

KB5065426 is a complicated update because of its dual SSU+LCU nature. The SSU hardens the servicing stack—the component that installs future updates—and once applied, it cannot be removed via wusa /uninstall. Any behavioral changes introduced by the SSU become permanent until Microsoft ships a newer SSU. This means that even if you roll back the LCU portion, some underlying hardening may persist, and the interconnectivity between the two layers complicates troubleshooting.

SMB Auditing and Hardening Collide with Legacy Environments

The September rollup activates new SMB server-side auditing hooks designed to prepare administrators for stricter signing and Extended Protection for Authentication (EPA) enforcement coming in future releases. The idea is to log when clients would fail these checks, giving admins time to remediate non-compliant devices. However, the auditing logic appears to have an unintended side effect: when a client doesn’t meet the modern security bar, the server may default to denying the connection outright rather than just logging it. This is especially harsh on devices that rely on insecure guest authentication, weak or absent SMB signing, or NetBIOS name resolution.

Microsoft confirmed in Q&A threads that the update can reset network profiles to Public, disable Network Discovery and File and Printer Sharing, and block insecure guest logins. These are all sensible security defaults—but applying them silently to existing systems is what caught people off guard.

SMBv1 and NetBIOS: The Fall Guys

Microsoft has long deprecated SMBv1, but its removal isn’t complete. KB5065426 exposed that fact brutally. Systems still employing SMBv1 over NetBIOS (NetBT) for compatibility with old NAS boxes or printers became high-risk candidates for failure. When both client and server receive the update, the SMB negotiation can fail in new ways that didn’t surface before. In some cases, the share becomes accessible again if you enable SMB 1.0/CIFS support in Windows Features (a risky move), or if you switch to pure TCP/IP transport and avoid NetBIOS. The official KB article does not list SMBv1 breakage as a known issue, but Microsoft product team members have acknowledged the reports in forums and suggested temporary SMB1 re-enablement as a last resort—while strongly warning against it.

The Duplicate SID Hypothesis

Perhaps the most insidious discovery came from admins managing large fleets of imaged machines. In environments where a single golden image is deployed without running sysprep /generalize, every clone ends up with the same machine SID. Historically, duplicate machine SIDs in a workgroup or domain have been tolerated by the authentication stack, with only minor side effects (like WSUS conflicts). KB5065426 appears to have introduced a change that makes SID uniqueness critical for SMB session establishment. Community troubleshooters found that machines with identical SIDs suddenly could not authenticate to each other, even though the same credentials worked from a third, unique-SID machine. Changing the SID—either by sysprepping the image or using third-party SID-modification tools—resolved the problem in test after test.

Microsoft has not officially documented this as root cause, and the KB article makes no mention of SID behavior. But the consistency of the community findings leaves little doubt: the update’s hardened SMB stack is now sensitive to machine identity in a way that penalizes sloppy imaging practices. This is a major wake-up call for IT departments that have never bothered with sysprep because “it just worked.”

Microsoft’s Response and What the Forums Reveal

On the official KB5065426 support page, the issues sections focus on known PSDirect hotpatch edge cases and DISM-based rollback procedures. There is no line item stating “file sharing is broken.” However, Microsoft community moderators have posted in multiple threads outlining the observed behaviors (network reset, guest login blocks, etc.) and providing step-by-step guidance to restore functionality. The advice aligns with what peer users have found to work:

  • Reset the network profile to Private.
  • Re-enable Network Discovery and File and Printer Sharing.
  • Temporarily re-allow insecure guest authentication or SMB1 for legacy devices (with clear warnings).
  • If all else fails, uninstall the LCU portion.

Moderators also explicitly stated that uninstalling the update restores everything to normal—a tacit admission that the update is the direct cause. The absence of a formal “known issue” acknowledgment may stem from the fact that the update is functioning as designed, and the breakage is a consequence of necessary security hardening. But for the tens of thousands of users who can no longer print or access files, that is a distinction without a difference.

Safe Mitigations and Risky Workarounds

IT professionals have coalesced around a set of practical responses, ranging from safe operational best practices to last-resort hacks that trade security for connectivity.

Preferred, Low-Risk Steps

  1. Pause and pilot: Halt automatic deployment of KB5065426 on any machine that depends on file/print sharing. Use a test ring of representative hardware to understand the impact before it hits production.
  2. SMB audit first: Enable the new SMB auditing features on a few servers to identify which clients would fail signing or EPA checks. This inventory lets you remediate non-compliant devices before enforcing policies.
  3. Basic post-update validation: After installation, manually check that the network is set to Private, that sharing and discovery are on, and that both client and server are rebooted. This simple sequence has restored access for some users whose shares were disabled but not fundamentally broken.
  4. Sysprep your images: If you use cloning, adopt sysprep /generalize as a mandatory step. This generates a unique machine SID every time. It’s a best practice that predates this update, but the pain of ignoring it now has a measurable cost.

Workarounds That Carry Security Risk

  • AllowInsecureGuestAuth registry tweak: Setting AllowInsecureGuestAuth = 1 under HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters re-enables guest access, which often restores connectivity to legacy devices. Microsoft Q&A moderators caution that this reopens a known attack vector for relay and man-in-the-middle attacks.
  • Re-enable SMB 1.0/CIFS: Going to “Turn Windows features on or off” and ticking the SMB1 box might bring an old NAS back to life. But SMB1 lacks encryption, signing, and is a well-documented vector for ransomware propagation. Only do this if you can physically isolate the legacy device on a firewalled VLAN.
  • Uninstall the LCU: DISM /Online /Remove-Package /PackageName:Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.6584.1.0 (or the appropriate package name for your system) removes the cumulative update and restores pre-September behavior. This also removes dozens of critical security patches, leaving your system vulnerable to exploits that were patched in this very rollup. Only use uninstall as a temporary bridge while you wait for Microsoft to issue a corrective update.

Step-by-Step Recovery Checklist for Sysadmins

  1. Pause updates for all at-risk endpoints and schedule a staged rollout.
  2. Inventory your environment: Map every legacy SMBv1 device, every cloned machine that might have a duplicate SID (use PsGetSid from PSTools to check), and every critical printer/NAS.
  3. Reproduce in a lab: Install KB5065426 on a representative sample and validate the failure. Check Event Viewer under “Applications and Services Logs\Microsoft\Windows\SMBClient” and “SMBServer” Operational channels, and Security log for Event ID 4625 (authentication failure).
  4. Remediate SIDs first: If duplicate SIDs exist, plan a sysprep cycle to regenerate unique IDs. This is more effort than enabling insecure protocols, but it fixes the root cause without degrading security.
  5. Temporarily isolate legacy devices: If you must re-enable SMB1 or guest auth for a legacy device, place it on an isolated VLAN with strict inbound/outbound firewall rules. Document every exception with an expiration date.
  6. Rollback if absolutely necessary: Uninstall only the LCU via DISM, and maintain backups. Have a concrete plan to reapply the patch as soon as Microsoft provides a fix, so you don’t remain exposed to known CVEs indefinitely.

Why the “Quick Fixes” Are Dangerous

Enabling SMB1 or AllowInsecureGuestAuth feels safe when you just need to get a printer working again, but these protocols are fundamentally broken from a security perspective. SMB1 was the primary vector for WannaCry and NotPetya, and guest auth allows anonymous attackers to connect to your shares without any password. Uninstalling the update removes not just the SMB hardening but also all the security patches for zero-day vulnerabilities addressed in September. That might include fixes for vulnerabilities already under active exploit. IT managers who roll back without compensating controls (network segmentation, endpoint detection and response tuning, aggressive monitoring) are gambling with their organization’s security.

Changing machine SIDs is safer in principle, but it’s an intrusive operation. A machine that gets a new SID may require a domain re-join, can lose access to certain encrypted files, and might reset some application licenses. Test thoroughly on a clone before rolling it out across the fleet.

Monitoring and Verification

Once you’ve applied a remediation, verify its effectiveness:

  • Check OS build: winver or Settings → System → About should show 26100.6584 if the update is installed, or a lower build if rolled back.
  • Watch the logs: SMBClient and SMBServer Operational logs will show audit entries for signing/EPA attempts and failures. Security event 4625 will spike if authentication rejections continue.
  • Use network scanning tools to detect any remaining devices that rely on weak authentication or lack signing support. Maintain a list and target them for replacement or isolation.

The Bottom Line: A Necessary Pain with Poor Timing

KB5065426 is not a buggy update in the traditional sense; it’s a deliberate security hardening that landed with the force of a breaking change. Microsoft’s multi-year plan to strengthen the SMB protocol is absolutely necessary—Windows networks have been plagued by weak authentication and legacy protocols for too long. But the rollout missed the mark on operational readiness. By not clearly communicating the potential for broken file sharing, and by bundling the SSU in a way that complicates rollback, Microsoft left administrators scrambling.

The community has once again proven its value, documenting the duplicate SID theory and validating workarounds faster than official channels could respond. For now, the safest course for any organization that relies on file and print sharing is to hold KB5065426, inventory everything, fix imaging practices, and begin the hard work of retiring SMBv1 devices. If you’ve already been hit, the mitigations above can buy you time, but they come with trade-offs you cannot afford to ignore.

Microsoft is expected to release a follow-up update that addresses the most disruptive regressions without sacrificing the hardening gains. Until then, the burden falls on IT teams to navigate this patch with a scalpel, not a sledgehammer.