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.

.claude/skills/drive-map/SKILL.md

@@ -99,10 +99,32 @@ bash .claude/skills/drive-map/scripts/drive-map.sh map --host SOME-PC \
   --server '\\CS-SERVER\SalesDept' --letter S
 ```
 
+## CRITICAL — the RMM `verify` is NOT authoritative (read this)
+
+`verify` (and any RMM-dispatched `net use`/`net view`/`Test-Path`/`Get-SmbConnection`)
+runs in an agent-injected process that does **not** share the user's real interactive
+network-logon session. It **false-negatives**: it can report `error 67 (BAD_NETWORK_NAME)`
+/ `RPC 1702` / "not reachable" for shares that are **actually fine**. Proven at Cascades
+2026-06-26 — RMM tests failed against a user's daily-use NAS and showed "no connections"
+for a client that had a live server-side session with open files; an entire "CS-SERVER SMB
+outage" investigation turned out to be this artifact (the server was healthy: `Get-SmbSession`
+showed 7 users / 30 open files). It is **inconsistent**, not always-wrong — it passes once a
+cmdkey is freshly stored in the active session (as in the successful Karen ALDocs migrate).
+
+**Therefore:**
+- A `verify` **failure is NOT proof of a problem.** Never diagnose a "server/share outage"
+  from RMM client-side SMB results. Validate the SERVER with `Get-SmbSession` /
+  `Get-SmbOpenFile` (server truth), or do a REAL interactive test on the endpoint.
+- A `verify` **success is meaningful** (reachable confirmed). Treat the cred+shortcut
+  operations (cmdkey, `.lnk`, Quick Access) as the real deliverable — those persist
+  reliably — and have a human confirm interactively when possible.
+- See errorlog friction `rmm/smb-testing` and memory `project_cascades_network_segments`.
+
 ## Hard rules
 
-- **Always `verify` first and last.** Confirm the target is reachable for that user
-  before declaring success — a green `net use` line is not proof of access.
+- **`verify` first and last, but treat a FAILURE as inconclusive** (see CRITICAL above) —
+  confirm interactively before declaring either success or a server problem. A green
+  `net use` line is not proof of access; a red one is not proof of failure.
 - **One user at a time, with a session.** If no interactive user is logged on, stop
   and say so; do not "succeed" against SYSTEM's profile.
 - **Additive to permissions.** This skill never touches share/NTFS ACLs. If the user