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, MessageGet-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. fileciteturn1file3turn1file19
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.) fileciteturn1file19turn1file12
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.
