azcomputerguru/claudetools
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

sync: auto-sync from HOWARD-HOME at 2026-06-26 07:19:00

Browse Source 
Author: Howard Enos
Machine: HOWARD-HOME
Timestamp: 2026-06-26 07:19:00
This commit is contained in:
Howard Enos
2026-06-26 07:19:29 -07:00
parent 15f2d03d7b
commit 270e294938
3 changed files with 185 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files

40
.claude/memory/project_cascades_network_segments.md
View File

@@ -20,21 +20,33 @@ in the /22). Wi-Fi SSID for corporate = **`CSCNet`**.
pfSense `192.168.0.1`. CSCNet PSK + CSC ENT PSK vaulted (`clients/cascades-tucson/wifi-cscnet.sops.yaml`,
`wifi-csc-ent.sops.yaml`).
**CORRECTION (don't trust the first theory): the SMB problem is NOT CSC-ENT-vs-CSCNet.** Verified
2026-06-26: fresh SMB connections to `\\cs-server\<share>` fail with **System error 67
(BAD_NETWORK_NAME), even `IPC$`**, from CSC ENT AND CSCNet alike (Meredith on CSC ENT, Crystal +
Karen on CSCNet all hit it). Only **pre-existing persistent mapped drives** work, and even those are
**intermittent** (Meredith's `Y: \\cs-server\Server` read True then False minutes later). Lower layers
are fine everywhere (ping, nbtstat=CS-SERVER, TCP 445/139). So it's a **CS-SERVER-side SMB
instability**, not the client network.
**CORRECTION x2 (2026-06-26): the SMB problem is NOT CSC-ENT-vs-CSCNet AND NOT the AV.** After a
FULL removal of the Datto stack from CS-SERVER (DattoAV SDK + Datto RMM + Datto EDR — see below) and
a reboot, **error 67 persisted unchanged** — so the AV minifilters (`rtp1`/`rtp2`/`BdSentry`) were a
RED HERRING for SMB. More importantly, the SMB **server is HEALTHY for domain/Kerberos clients**:
`Get-SmbSession` shows 7+ live SMB 3.1.1 sessions with open files (lauren, Sharon, Crystal @10.0.20.205,
Megan, Ashley, chris) established AFTER the reboot. The failure is confined to **workgroup/NTLM +
loopback**: Karen (DESKTOP-LPOPV30, workgroup) gets error 67 to EVERY share (IPC$, C$, a brand-new
test share) even in her real user session with CORRECT creds, and `Get-SmbConnection`=none (the SMB
session never negotiates; NO SMBServer/SMBClient event is logged -> failure is **pre-SMB-negotiate,
BAD_NET_NAME**, not auth). NTLM restriction is NOT set (`RestrictReceivingNTLMTraffic`,
`LmCompatibilityLevel`, NTLM Operational log all clear). `Get-SmbServerConfiguration` now works
(NullSessionShares REG type was repaired prior session).
**Root-cause leads (CS-SERVER):** `Get-SmbServerConfiguration` throws *"Data of this type is not
supported"* (degraded SMB config subsystem); SMB **multichannel advertises multiple interfaces** —
`192.168.2.248` (Ethernet), `192.168.2.254` (Hyper-V vSwitch), and IPv6 ULAs (`fde4::…`,`fd8f::…`).
Clients negotiating channels to unreachable interfaces is the prime suspect for flaky/failed new
sessions. SMB signing required (it's a DC). Likely fixes (NEED approval, prod DC, 13 live sessions):
disable SMB multichannel / unbind File&Printer sharing from `.254`+IPv6 so it serves only on `.248`;
and/or restart LanmanServer (or reboot) to rebuild the degraded config.
**The AV was DattoAV, not GravityZone Bitdefender.** It was the Datto EDR "Endpoint Protection SDK"
under `C:\Program Files\infocyte\agent\dattoav`, managed by Datto RMM (CentraStage/CagService) + Datto
EDR Agent (HUNTAgent/Infocyte HUNT). That is why removing from the GravityZone console did nothing.
ALL Datto software was removed from CS-SERVER 2026-06-26 (services deleted, dirs/registry/drivers gone).
Tenant azcomp4587; Cascades org `2d5ea96e-3228-461b-9c60-13ae464b61d8`; CS-SERVER was already de-enrolled
from EDR. Use the `/datto-edr` skill + `msp-tools/datto-edr.sops.yaml`.
**Open SMB-67 leads (server fine for domain clients):** SMB multichannel advertises `.248` (Ethernet),
`.254` (Hyper-V vSwitch, often unreachable from routed clients), and IPv6 ULAs (`fde4::`,`fd8f::`) —
a routed WORKGROUP client (Karen @10.0.20.100, 4 of 5 adapters on APIPA 169.254) negotiating channels
to unreachable interfaces is a candidate. Next: fresh connect from Meredith (workgroup, ON-LINK
192.168.2.x) to isolate Karen-machine vs workgroup-general; clean Karen's APIPA adapters; consider
unbinding File&Printer from `.254`/IPv6 (prod DC, domain clients currently fine — needs care); or
domain-join Karen (Kerberos works for everyone who is joined).
**Two more migration blockers found:** (1) **CSCNet is WPA3-SAE** — older adapters (e.g. Intel AC 3165
on Meredith's ASSISTMAN-PC) **cannot join it**, so "move everyone to CSCNet" is blocked by hardware.