sync: auto-sync from HOWARD-HOME at 2026-06-26 08:41:22

Author: Howard Enos
Machine: HOWARD-HOME
Timestamp: 2026-06-26 08:41:22

.claude/memory/project_cascades_network_segments.md

@@ -40,13 +40,20 @@ ALL Datto software was removed from CS-SERVER 2026-06-26 (services deleted, dirs
 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).
+**RESOLVED (2026-06-26): there was NO CS-SERVER SMB problem. "Error 67" was a TEST-METHOD ARTIFACT.**
+RMM-dispatched SMB client commands (`net use`/`net view`/`Test-Path`/`Get-SmbConnection`, even with
+`context: user_session`) FAIL with error 67 / RPC 1702 / "none" for KNOWN-GOOD targets too — proven:
+Karen's RMM test to her daily-use NAS (`\\CASCADESDS`) returned the same errors, and Crystal showed a
+live server-side session (5 open files) while RMM `Get-SmbConnection` on her box reported none. The
+agent-injected process lacks the user's real network-logon session. **Validate SMB with server-side
+`Get-SmbSession` (showed 7 live users / 30 open files / new sessions forming) or a REAL INTERACTIVE
+test — never RMM-dispatched client cmds.** Verified 2026-06-26: logging into CS-SERVER shares as
+`CASCADES\karen.rossini` interactively from another PC (John Trozzi/MAINTENANCE-PC) WORKED — account,
+password (vaulted), `SG-IT-RW` access, and the server are all fine. The original drive-map `verify`
+failure that started this whole investigation was the same RMM artifact. See errorlog friction entry
+`rmm/smb-testing`. Karen's only remaining real item: repoint her ALDocs shortcut on DESKTOP-LPOPV30 to
+`\\CS-SERVER\Server\ALDocs` and CONFIRM INTERACTIVELY (don't trust drive-map's RMM verify). NOTE: the
+prior-session move of Karen to CSCNet broke her NAS-by-name resolution — unrelated to the (non)issue.
 
 **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.