KB5065428 (OS Build 17763.7792) installed breaks SMB 3.1.1 connection on windows server 2019 intermittently.

ChatGPT said:

Hi yangyang — short answer: yes — others have seen SMB breakage after the recent cumulative/security servicing that added SMB auditing/hardening, and the community has reported intermittent SMB connection/authentication failures on Server 2019 and other Windows builds. The updates introduced server‑side SMB auditing and stricter authentication/signing behavior which has exposed compatibility gaps (especially in environments with legacy SMBv1/NetBIOS devices or cloned machines with duplicate SIDs).
What the field reports show (high level)

• The patching cycle added SMB server auditing and tighter signing/EPA checks; when a compatibility gap is found the stack can reject connections that previously succeeded.
• Most confirmed, documented problems centered on SMBv1 over NetBIOS (NetBT), but the hardening/auditing changes can surface other intermittent SMB 3.x behaviors in some environments (authentication failures, repeated credential prompts, or intermittent disconnects).
• Environments with identically‑imaged/cloned machines (duplicate machine SIDs) frequently show authentication failures after the update; regenerating unique SIDs or rolling back the LCU sometimes restores functionality (note SSU changes can remain and complicate rollbacks).

Practical troubleshooting checklist (what to check now)

1. Confirm exact build and KB on both client and server
   • winver (or Get-HotFix) and the installed KB number(s). Many threads reference the September/October 2025 servicing packages that bundle an SSU+LCU — this matters for rollback options.
2. Check Event Viewer for SMB/LSA/Kerberos/NTLM errors at the time of failure
   • Look in System, Security, and Applications & Services Logs → Microsoft → Windows → SMBServer/SMBClient, LSA, Kerberos. Events are the primary diagnostics used in the field.
3. Test basic connectivity and SMB negotiation
   • From a client: Test-NetConnection -ComputerName <server> -Port 445 and attempt a net use \\<server>\<share> while capturing timestamps in the logs.
4. Verify SMB configuration on the server
   • Get-SmbServerConfiguration and Get-SmbClientConfiguration (PowerShell) to confirm signing, encryption, and allowed protocols.
5. Check for duplicate machine SIDs (if you use imaging/VDI)
   • Tools: PsGetSid or Get-ADComputer -Properties objectSid in AD environments; duplicated SIDs have been correlated with failures after these hardenings.
6. Confirm whether SMBv1/NetBT is in use
   • If any legacy device relies on SMBv1/NetBIOS, that is a high‑risk compatibility vector. Microsoft documented NetBT/SMBv1 connectivity regressions and recommended mitigations.

Short-term mitigations (use cautiously)

• Force SMB over TCP (allow TCP/445 between affected endpoints): this is a Microsoft‑documented workaround to avoid NetBIOS/NetBT negotiation problems — apply only in controlled/segmented networks.
  Example firewall rule (run as admin):
  New-NetFirewallRule -DisplayName "Allow SMB Inbound 445" -Direction Inbound -Protocol TCP -LocalPort 445 -Action Allow
• If you must talk to a legacy SMBv1 device, isolate it (VLAN/ACL) or update firmware — enabling SMB1 or AllowInsecureGuestAuth is insecure and only a last resort.
• If the LCU rollback is required, remember SSU changes may remain (combined SSU+LCU packages); Microsoft documents DISM approaches for LCU removal but SSU often persists. Plan rollback tests before doing this in production.

Recommended next steps I can help with

1. If you can share exact build/KB numbers from the server and a short timeline of the failures (timestamps), I’ll point to the most likely causes and next commands to run. (No files were attached to your post — please attach logs or screenshots if you want me to review them.)
2. Gather these items and paste them here:
   • Output of winver or Get-HotFix
   • Get-SmbServerConfiguration and Get-SmbClientConfiguration output
   • A sample SMB client failure event (EventID, time, and message) from Event Viewer
   • Whether the server and clients are identically imaged / any known duplicate SIDs
3. If you want immediate containment, I can give the exact PowerShell commands to enable the TCP/445 workaround on your firewall and how to temporarily collect verbose SMB logs.

If you want, paste the KB number(s) and the winver output here and I’ll give a tailored checklist and the precise commands to capture the relevant event/log snippets.

Click to expand...

• winver (GUI) or from an elevated PowerShell: Get-HotFix | Where-Object { $_.HotFixID -match "KB506" } — paste the KB and OS build. (Knowing whether an SSU+LCU was installed matters for rollback options.

• Check these logs for the timestamps when the SMB 3.1.1 session failed:
  • Microsoft-Windows-SMBServer/Audit and Microsoft-Windows-SMBClient/Audit (Applications and Services Logs) — look for audit events (examples: 3021, 3022 on server; 31998, 31999 on client).
  • System, Security and LsaSrv (watch for EventID 6167), Kerberos (EventID 21/45), and Security 4625 (network logon failures).
• Helpful PowerShell to pull recent SMB audit events (run as admin):
  • Get-WinEvent -LogName "Microsoft-Windows-SMBServer/Audit" -MaxEvents 50 | Format-List TimeCreated, Id, LevelDisplayName, Message
  • Get-WinEvent -LogName "Microsoft-Windows-SMBClient/Audit" -MaxEvents 50 | Format-List TimeCreated, Id, Message

• Get-SmbServerConfiguration | Format-List *
• Get-SmbClientConfiguration | Format-List *
• Look specifically for settings related to signing/encryption/allowinsecureguestauth and the audit flags. The new KBs add Group Policy / PowerShell audit toggles you can enable to see compatibility issues.

• From a client: Test-NetConnection -ComputerName <serverFQDNorIP> -Port 445
• Attempt a mount and capture error: net use \\<server>\<share> /user:<domain>\user — note exact error code/text and time.

• If you use cloned images/VDI or have many freshly provisioned hosts, run PsGetSid or query AD objectSids for duplicates. Example: psgetsid \\computername or Get-ADComputer -Filter * -Properties objectSid | Select-Object Name,objectSid — duplicate machine SIDs have been correlated with authentication breaks after the hardening.

• Microsoft’s documented short‑term workaround for NetBIOS/SMBv1 fallback problems is to force SMB over TCP by allowing TCP/445 between endpoints — this often restores connectivity where NetBT negotiation fails. Apply only in tightly controlled/segmented networks and monitor. New-NetFirewallRule -DisplayName "Allow SMB Inbound 445" -Direction Inbound -Protocol TCP -LocalPort 445 -Action Allow.
• Do NOT re-enable SMBv1 or AllowInsecureGuestAuth broadly; if absolutely necessary for a legacy device, isolate that device (VLAN/ACL) and plan replacement/firmware update.
• If the environment has duplicate SIDs, the long‑term fix is to generalize/regenerate SIDs (Sysprep or tested SID‑regeneration tooling) — that has restored functionality in many reports, but it is intrusive and must be planned/tested.

• The update introduces server‑side SMB auditing and tighter signing/EPA and identity validation. When a compatibility gap is detected (legacy client, missing signing/encryption, duplicate machine identity), the server can reject or audit the session instead of accepting an insecure fallback — which can look like intermittent SMB 3.1.1 connection failures. The change was added intentionally as a security hardening, but it exposes devices/environments that relied on previous leniency.

• If you paste:
  1) the server’s winver / KB list,
  2) outputs from Get-SmbServerConfiguration and Get-SmbClientConfiguration, and
  3) a copy (or the text) of the SMB Audit / LSA / Kerberos events captured at failure time (EventID + Message + Time) — I’ll analyze them and point to the exact cause and remediation. (You can paste trimmed logs — don’t include passwords.

• winver (screenshot or text)
• Get-HotFix | Where-Object { $_.HotFixID -match "KB506" }
• Get-SmbServerConfiguration | Format-List *
• Get-SmbClientConfiguration | Format-List *
• Get-WinEvent -LogName "Microsoft-Windows-SMBServer/Audit" -MaxEvents 50 | Format-Table TimeCreated,Id,@{n='Message';e={$_.Message -replace "(\r\n|\n)","\t"}}
• Get-WinEvent -LogName Security -MaxEvents 50 | Where-Object { $_.Id -in 4625,4624 } | Format-Table TimeCreated,Id,Message -AutoSize

• (A) walk you through running those commands and interpreting the logs step‑by‑step, or
• (B) show the exact firewall rule + audit enabling commands to try the TCP/445 workaround and enable SMB audit (so you can see which clients would be blocked under stricter enforcement)?

ChatGPT said:

Thanks — that clarifies. Short answer: while the biggest, documented breakages after the recent servicing were with SMBv1/NetBT, the SMB auditing/hardening those updates added has also exposed compatibility/authentication gaps that can cause intermittent SMB 3.1.1 failures in some environments (authentication prompts, disconnects or rejected sessions). Community diagnostics show this pattern and point to tightened server‑side signing/EPA checks and identity validation as the trigger.
What to check right now (quick checklist + exact commands)
1) Confirm patch/build on server and client

• winver (GUI) or from an elevated PowerShell: Get-HotFix | Where-Object { $_.HotFixID -match "KB506" } — paste the KB and OS build. (Knowing whether an SSU+LCU was installed matters for rollback options.)

2) Reproduce and capture the exact failure time + Event Viewer messages

• Check these logs for the timestamps when the SMB 3.1.1 session failed:
  • Microsoft-Windows-SMBServer/Audit and Microsoft-Windows-SMBClient/Audit (Applications and Services Logs) — look for audit events (examples: 3021, 3022 on server; 31998, 31999 on client).
  • System, Security and LsaSrv (watch for EventID 6167), Kerberos (EventID 21/45), and Security 4625 (network logon failures).
• Helpful PowerShell to pull recent SMB audit events (run as admin):
  • Get-WinEvent -LogName "Microsoft-Windows-SMBServer/Audit" -MaxEvents 50 | Format-List TimeCreated, Id, LevelDisplayName, Message
  • Get-WinEvent -LogName "Microsoft-Windows-SMBClient/Audit" -MaxEvents 50 | Format-List TimeCreated, Id, Message

3) Verify SMB server/client config and negotiation

• Get-SmbServerConfiguration | Format-List *
• Get-SmbClientConfiguration | Format-List *
• Look specifically for settings related to signing/encryption/allowinsecureguestauth and the audit flags. The new KBs add Group Policy / PowerShell audit toggles you can enable to see compatibility issues.

4) Basic connectivity & reproduction tests

• From a client: Test-NetConnection -ComputerName <serverFQDNorIP> -Port 445
• Attempt a mount and capture error: net use \\<server>\<share> /user:<domain>\user — note exact error code/text and time.

5) Check for imaging / duplicate SID issues (common cause)

• If you use cloned images/VDI or have many freshly provisioned hosts, run PsGetSid or query AD objectSids for duplicates. Example: psgetsid \\computername or Get-ADComputer -Filter * -Properties objectSid | Select-Object Name,objectSid — duplicate machine SIDs have been correlated with authentication breaks after the hardening.

Immediate mitigations (use with caution)

• Microsoft’s documented short‑term workaround for NetBIOS/SMBv1 fallback problems is to force SMB over TCP by allowing TCP/445 between endpoints — this often restores connectivity where NetBT negotiation fails. Apply only in tightly controlled/segmented networks and monitor. New-NetFirewallRule -DisplayName "Allow SMB Inbound 445" -Direction Inbound -Protocol TCP -LocalPort 445 -Action Allow.
• Do NOT re-enable SMBv1 or AllowInsecureGuestAuth broadly; if absolutely necessary for a legacy device, isolate that device (VLAN/ACL) and plan replacement/firmware update.
• If the environment has duplicate SIDs, the long‑term fix is to generalize/regenerate SIDs (Sysprep or tested SID‑regeneration tooling) — that has restored functionality in many reports, but it is intrusive and must be planned/tested.

Why this happens (short)

• The update introduces server‑side SMB auditing and tighter signing/EPA and identity validation. When a compatibility gap is detected (legacy client, missing signing/encryption, duplicate machine identity), the server can reject or audit the session instead of accepting an insecure fallback — which can look like intermittent SMB 3.1.1 connection failures. The change was added intentionally as a security hardening, but it exposes devices/environments that relied on previous leniency. fileciteturn1file3turn1file19

What I can do next for you

• If you paste:
  1) the server’s winver / KB list,
  2) outputs from Get-SmbServerConfiguration and Get-SmbClientConfiguration, and
  3) a copy (or the text) of the SMB Audit / LSA / Kerberos events captured at failure time (EventID + Message + Time) — I’ll analyze them and point to the exact cause and remediation. (You can paste trimmed logs — don’t include passwords.) fileciteturn1file19turn1file12

If you want an immediate command bundle to run now (collect build, SMB config, and last 50 relevant events), run these in an elevated PowerShell on the server and paste the output:

• winver (screenshot or text)
• Get-HotFix | Where-Object { $_.HotFixID -match "KB506" }
• Get-SmbServerConfiguration | Format-List *
• Get-SmbClientConfiguration | Format-List *
• Get-WinEvent -LogName "Microsoft-Windows-SMBServer/Audit" -MaxEvents 50 | Format-Table TimeCreated,Id,@{n='Message';e={$_.Message -replace "(\r\n|\n)","\t"}}
• Get-WinEvent -LogName Security -MaxEvents 50 | Where-Object { $_.Id -in 4625,4624 } | Format-Table TimeCreated,Id,Message -AutoSize

Caveat: if you need to roll back an LCU, remember SSU changes may remain (combined SSU+LCU packages complicate rollbacks) — plan and test rollback in a maintenance window.
Would you like me to:

• (A) walk you through running those commands and interpreting the logs step‑by‑step, or
• (B) show the exact firewall rule + audit enabling commands to try the TCP/445 workaround and enable SMB audit (so you can see which clients would be blocked under stricter enforcement)?

Tell me which option and paste the outputs you already have (winver / Get-SmbServerConfiguration / any event messages) and I’ll take it from there.

Click to expand...

• If you mean “the AD user account’s SID is the same on Server A and Server B”: that’s expected — a domain user has one SID and it will be identical no matter which machine that user authenticates from. That alone is not the problem.
• The real compatibility/authentication issue reported after these updates is usually caused by duplicate machine SIDs (the cloned image left both machines with the same machine/local SID) or other identity collisions — that can cause the tightened authentication checks to reject SMB sessions. Community troubleshooting has repeatedly pointed at duplicate machine SIDs as a frequent root cause after the SMB hardening/auditing updates.

• To show the currently logged-in user SID (domain user): open cmd or PowerShell as that user and run:
  • whoami /user
  • or in PowerShell: [System.Security.Principal.WindowsIdentity]::GetCurrent.User.Value
• To show the machine/local SID, run PsGetSid from Sysinternals (download if needed) on each server:
  • psgetsid \\ServerA
  • psgetsid \\ServerB
    If both show the same machine SID, you have a cloned-machine SID collision. Community reports link this to SMB auth failures after the hardening updates.

• Check for LsaSrv and SMB audit clues around the failure time:
  • Get-WinEvent -FilterHashtable @{LogName='System'; ID=6167} -MaxEvents 20 | Format-List TimeCreated, Id, Message
  • Get-WinEvent -LogName 'Microsoft-Windows-SMBServer/Audit' -MaxEvents 50 | Format-List TimeCreated, Id, Message
  • Get-WinEvent -LogName Security -MaxEvents 200 | Where-Object { $_.Id -in 4625,4624 } | Format-Table TimeCreated,Id,Message -AutoSize
    Look for messages about “partial mismatch in the machine ID”, Kerberos Event IDs 21/45, or NTLM/SMB audit events. Those are the high‑signal breadcrumbs the field uses.

• Server: Get-SmbServerConfiguration | Format-List *
• Client: Get-SmbClientConfiguration | Format-List *
• From client: Test-NetConnection -ComputerName <serverIPorFQDN> -Port 445 then attempt net use \\<server>\<share> /user:<domain>\username and note the exact error text and time.

• Force SMB over TCP (workaround for NetBT/SMB negotiation problems): on the server (or firewall) allow inbound TCP 445 from the client subnets:
  • New-NetFirewallRule -DisplayName "Allow SMB Inbound 445" -Direction Inbound -Protocol TCP -LocalPort 445 -Action Allow
    This is a Microsoft-documented short-term mitigation for NetBIOS/SMBv1 fallback failures — apply only within segmented/trusted networks.
• Test using a local account (temporary) for the share to isolate whether domain auth is the blocker. Creating a local share user and granting NTFS/share rights can show whether authentication via a non-domain account succeeds.

• Regenerate unique machine SIDs by reimaging / running Sysprep /generalize on the cloned image and rejoining the domain (or otherwise rebuild the machine). Community reports and field experience show regenerating machine SIDs (via Sysprep) or re-provisioning fixes the authentication breaks exposed by the hardening update — but this is intrusive and must be planned/tested.

• Confirm which SID you meant (AD user SID vs machine/local SID).
• Paste the outputs (or copy/paste snippets) of:
  1) whoami /user (or psgetsid \\ServerA and psgetsid \\ServerB)
  2) Get-SmbServerConfiguration | Format-List * (from Server A)
  3) the most relevant EventViewer entries you find (LsaSrv 6167, SMBServer/Audit events, Security 4625 entries around the failure time)