Share via

SMB protocol negotions fail after 25H2 update

Steven Wallace 0 Reputation points
2026-04-17T20:22:27.2466667+00:00

We had a fleet of machines on 23H2 which we were using group policy to push registry keys forcing a minimum smb version of 3.0.0. After an upgrade to 25H2 smb breaks with an error that windows cannot access that location. Searching in wireshark shows that during smb protocol negotiation, they are not negotiating any smb version at all resulting in the connection failing. We have since deleted those registry keys from our group policy however even after checking that they no longer exist on our machines they still experience this issue after upgrading. Machines added to the domain since, do update correctly. We so far have found no residual settings enforcing any min or max smb version in our machines that could be causing this issue, or identified a fix to allow 25H2 machines to once again communicate over smb after removing the registry keys. Notably, adding these registry keys to a machine running 25h2 that did not have them prior to the upgrade, causes smb to work correctly with it only negotiating the smb protocols listed in the registry keys.

Windows for business | Windows Client for IT Pros | Networking | Network connectivity and file sharing
0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Scott Nguyen 1,390 Reputation points Independent Advisor
    2026-04-17T21:18:23.23+00:00

    Hello.

    You could check that if RequireSecureNegotiate is set to a value of 1 or 0 under that same registry path to see if the negotiation blockage is being triggered by the new strict validation requirements. It is also worth checking the RequireSecuritySignature setting via the Get-SmbClientConfiguration PowerShell cmdlet, as a mismatch between the client's mandatory signing and server can lead to the aborted negotiations you observed in Wireshark.

    If explicitly defining the dialects remains the only working solution, it is best practice to maintain those registry keys as a standardized configuration rather than relying on the 25H2 default state. And I would suggest waiting for a formal cumulative update from Microsoft to address the issue.

    If you find my answer useful, please mark it as the "Accepted Answer" so other members can find the solution easily. Your help in supporting the community is much appreciated!
    Best regards,
    Scott

    Was this answer helpful?

    1 person found this answer helpful.
    0 comments

  2. AI answer

    2026-04-17T20:22:48.5066667+00:00

    The behavior matches known SMB connectivity issues introduced by recent Windows 11 / Server 2025 updates and later corrected by follow‑up updates and known‑issue rollbacks.

    Key points from the context:

    1. SMB protocol issues after 2025 updates
      • Multiple 2025 cumulative updates introduce SMB connectivity problems, especially around SMBv1 and stricter SMB defaults. While the documented symptom explicitly calls out SMBv1, the underlying theme is that SMB behavior changes with these updates and can break existing configurations until a corrective update is applied.
      • The September 9, 2025 update (KB5065426, OS Build 26100.6584) and the out‑of‑band September 22, 2025 update (KB5068221, OS Build 26100.6588) both list “SMBv1 protocol connectivity” as a known issue. The problem is resolved only after installing later updates (KB5065789 or KB5066835), which act as fixes.
    2. Fixes are delivered via later cumulative updates
      • For the SMB connectivity issue, the documentation is explicit that the problem is “addressed in” later cumulative updates:
        • KB5065426 known issue: “This issue is addressed in KB5065789” or “This issue is addressed in KB5066835,” depending on the channel.
        • KB5068221 known issue: “This issue is addressed in KB5065789.”
      • This means that if a system is on a build that includes the breaking change but not the follow‑up fix, SMB negotiation can fail until the corrective update is installed.
    3. Group Policy / rollback packages can temporarily revert breaking changes
      • For other network‑related regressions in 2025 (for example, issues caused by January–March 2025 updates), Microsoft ships a Known Issue Rollback (KIR) Group Policy package. The February 25, 2025 KB5052093 article describes downloading and applying a KIR GPO to revert a breaking change:
        • “This Group Policy will resolve this issue caused by the recent updates released in January, February, and March 2025.”
        • “You’ll need to install and configure the Group Policy for your version of Windows… The Group Policy will temporarily disable the change causing this issue.”
      • This shows the pattern: when a Windows update introduces a networking or protocol regression, the supported remediation is either:
        • Install the servicing update that contains the fix, or
        • Apply the KIR Group Policy for that specific issue, if provided.

    Given the above, the most reliable remediation path for SMB negotiation failures after moving to 25H2 is:

    1. Ensure affected 25H2 machines have the corrective cumulative update installed
      • Check whether the affected 25H2 systems are on a build that includes the SMB fix referenced in the KBs:
        • If they are on a build that includes KB5065426 or KB5068221 but not KB5065789/KB5066835 (or any later cumulative update that supersedes them), SMB connectivity issues can persist.
      • Update those systems to a build that includes the fix:
        • Install KB5065789 (where applicable) or KB5066835, or any newer cumulative update that supersedes them.
      • After installing the corrective update, reboot and re‑test SMB negotiation without re‑applying the custom SMB min/max registry keys.
    2. If Microsoft provides a KIR GPO for the specific SMB regression, apply it
      • For similar 2025 networking issues, Microsoft provides a downloadable Known Issue Rollback Group Policy (as described in KB5052093). Applying the KIR GPO for the specific SMB issue will temporarily disable the breaking change introduced by the earlier update.
      • The process is:
        • Download the KIR package for the relevant issue and Windows version.
        • Import it into Group Policy Management.
        • Link the GPO to the OU containing the affected 25H2 machines.
        • Force a Group Policy update on clients and reboot.
    3. Avoid relying on legacy SMB protocol configurations
      • The SMBv1 protocol is deprecated and no longer installed by default. The KBs emphasize that newer SMBv2/SMBv3 deployments are not affected by the SMBv1‑specific issue.
      • Ensure that any remaining SMBv1 dependencies are removed and that file servers and clients are configured to use SMBv2/SMBv3 only.
    4. Validate that no residual policy is re‑applying old SMB registry settings
      • Even though the original SMB min/max registry keys were removed from Group Policy, confirm that:
        • No other GPOs or local scripts are re‑applying them.
        • New machines that work correctly are indeed receiving a different effective policy set than upgraded machines.
      • Once the systems are on a build that includes the SMB fix, SMB negotiation should succeed without needing to re‑force SMB versions via registry.

    In summary, the failure of SMB protocol negotiation after upgrading to 25H2 aligns with known SMB connectivity regressions introduced by 2025 updates. The supported resolution is to move affected systems to a build that includes the SMB fix (KB5065789/KB5066835 or later) or apply the corresponding Known Issue Rollback Group Policy, rather than continuing to rely on custom SMB version registry enforcement.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

    1 person found this answer helpful.

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.