Hey Checkyourlogs fans,

Recent cumulative updates (including KB5065426) can surface (and in some cases enforce) stricter behaviour around machine identity during authentication. In environments where two or more Windows systems share the same machine SID (often due to improperly generalized/cloned images), you may see sudden breakage in:

  • SMB file sharing (\server\share) and print sharing
  • Peer-to-peer authentication between affected hosts
  • Access that previously “worked” despite the duplicate SID condition

The technically correct remediation remains: rebuild/reimage so every node has a unique machine SID (using supported imaging/provisioning methods). If reimaging is not immediately feasible, Microsoft’s Known Issue Rollback (KIR) provides a viable temporary mitigation by rolling back the specific behaviour change introduced by the problematic update—without fully uninstalling the cumulative update.

Here is the link to the Microsoft Article with more details on this issue: Kerberos and NTLM authentication failures due to duplicate SIDs – Microsoft Support

This post includes a step-by-step procedural guide (enterprise-friendly) to deploy the KIR.

The screenshot below is from a 3-node Server 2025 S2D Cluster that was imaged but didn’t properly generalize.

We can see the duplicate SIDs.

Why do duplicate machine SIDs become an outage trigger?

A Windows machine SID is a core identifier used in security token construction and authentication flows. When multiple computers share the same machine SID, you can get collisions in scenarios that depend on machine identity and trust relationships. Historically, many orgs unknowingly “got away with it” until an update tightened logic or changed how identities are validated. Once that change lands, the duplicate SID condition moves from “latent risk” to “visible outage.”

What the KIR does (and does not do)

KIR does:

  • Roll back a specific problematic behaviour change associated with the update.
  • Restore interoperability (for example, SMB auth) between systems that were failing after the update.
  • Allow you to stabilize operations while planning proper remediation.

KIR does not:

  • Fix the root cause (duplicate SIDs).
  • Make duplicate SIDs “safe” long term.
  • Replace the need to rebuild/reimage where feasible.

Treat KIR as a bridge, not the destination.

Step-by-step procedural guide (Microsoft KIR MSI)

0) Prerequisites and guardrails

  1. Confirm symptoms match
    Typical indicators include SMB or file-sharing failures between specific hosts after the update is applied, often accompanied by authentication errors. (If only one direction fails, test both directions.)
  2. Confirm the duplicate SID condition exists
    You indicated you have already confirmed duplicates. If you need to re-validate quickly, do so using your established method (avoid “SID changer” community tools as a first response).
  3. Identify your scope
    • Which OS builds are affected (Server 2025, Windows 11 builds, etc)
    • Which machines require the rollback behaviour (often the systems participating in the failing authentication path)
  4. Change control
    The KIR is low risk relative to uninstalling an LCU, but still treat it as a controlled change: a maintenance window, a backout plan, and validation steps.

1) Obtain the correct KIR MSI package

  1. Go to the Microsoft Q&A thread (the one discussing KB5065426 and the workaround) – KB5065426 update stops file and print sharing from working – Microsoft Q&A
  2. Locate the official Microsoft-provided KIR MSI for the specific OS/build family you’re targeting (the thread contains the “known issue rollback MSI” reference).  Technically, you should get this from Microsoft support, but here is the direct download link.

https://download.microsoft.com/download/c6c70455-59ce-4d47-b13c-56b99d0435f1/Windows%2011%2024H2%2c%20Windows%2011%2025H2%20and%20Windows%20Server%202025%20KB5065426%20250923_06201%20Known%20Issue%20Rollback.msi

  1. Download the MSI to a controlled internal location (for example, a software distribution share).

Operational note: In many cases, Microsoft publishes separate KIR MSIs for each OS family/build. Do not assume one MSI applies to all versions.

2) Pilot installation on a single affected machine

On one impacted node (or one impacted client), run:

  • Interactive (manual) install:
    Double-click the MSI and complete the wizard.
  • Silent install (recommended for managed rollout):
    • Use msiexec with quiet mode and a log file, for example:
      • Install: msiexec /i <KIR-MSI>.msi /qn /norestart /l*v C:\Windows\Temp\KIR-KB5065426.log

After installation completes:

  1. Reboot the machine (do not skip reboot during pilot—policy activation and rollback behaviour often won’t apply correctly without it).
  2. Proceed to policy enablement (next section).

3) Enable the Known Issue Rollback policy (Local Policy test)

After the MSI is installed, it typically installs or activates the administrative template needed to expose the KIR policy.

  1. Open Local Group Policy Editor: gpedit.msc
  2. Navigate (path names may vary slightly by OS build, but commonly appear under KIR):
    • Computer Configuration → Administrative Templates → Known Issue Rollback
  3. Find the policy entry associated with KB5065426 (the name often includes a KB identifier and/or a build-specific string).
  4. Set the policy state according to Microsoft’s guidance in the thread (typically, set it to Enabled to activate the rollback behaviour, but follow the exact wording for that specific policy entry).
  5. Reboot

4) Validate functionality (Pilot validation checklist)

From a system that previously failed, test:

  1. SMB connectivity
    • Browse to \\<target>\c$ (admin share, if permitted) or a known file share.
    • Map a drive to the share.
  2. Credential prompt behavior
    • Confirm you are not getting repeated prompts or “username/password incorrect” loops.
  3. Print sharing (if relevant)
    • Connect to a shared printer and perform a test print.
  4. Event logs (target machine)
    • Check relevant security/authentication events around the time of connection attempts.
  5. Regression check
    • Confirm no unexpected side effects on other auth-dependent services on the pilot node.

If the pilot restores access reliably, proceed to enterprise deployment.

5) Backout plan

If you need to reverse the rollback behaviour:

  1. Set the KIR policy back to Not Configured (or the opposite state)
  2. gpupdate /force
  3. Reboot
  4. Optionally uninstall the MSI if Microsoft guidance indicates that is appropriate:
    • msiexec /x <product-code> /qn /norestart /l*v C:\Windows\Temp\KIR-KB5065426-uninstall.log

Long-term remediation plan (the real fix)

Once stability is restored, schedule the corrective work:

  1. Stop image-based propagation of duplicate SIDs
    • Ensure cloning is done with supported generalization/provisioning.
  2. Rebuild/reimage systems with duplicate SIDs
    • Especially critical for clustered infrastructure and any hosts providing core services.
  3. Add a detection control
    • Validate uniqueness during build pipelines or post-provisioning compliance checks.

This avoids repeated “surprise outages” when future updates further tighten authentication and identity validation.

 

Thanks,

Dave Kawula – MVP