sync: auto-sync from HOWARD-HOME at 2026-06-25 23:09:59

Author: Howard Enos
Machine: HOWARD-HOME
Timestamp: 2026-06-25 23:09:59

.claude/memory/MEMORY.md

@@ -135,6 +135,7 @@
 - [GURU-BEAST-ROG Setup Status](machine_windows_guru_setup_status.md) — Windows workstation fully configured except SSH key deployment to servers.
 
 ## Project
+- [Cascades network + CS-SERVER SMB instability](project_cascades_network_segments.md) — NAS->CS-SERVER migration. NOT a CSC-ENT-vs-CSCNet issue (corrected): fresh SMB to `\\cs-server\*` fails err 67 from BOTH Wi-Fis; only persistent admin-mapped drives work, intermittently → CS-SERVER-side SMB instability (multichannel advertises .248/.254/IPv6 ULAs; Get-SmbServerConfiguration errors). Blockers: CSCNet=WPA3 (old adapters can't join); workstations store domain-admin cred. Repoint tool [[drive-map]].
 - [CyndyOffice physical HP lockups](cyndyoffice-physical-hp-lockups.md) — RMM "Howard-VM" site agent CyndyOffice is a PHYSICAL HP Pavilion TP01 (not a VM); ~20 hard freezes/6wk = Kernel-Power 41 bugcheck-0, no dump/WHEA = hardware (RAM/PSU/BIOS), SSD healthy. UUID re-enrolls.
 - [Automate memory consolidation/lint (phased)](project_memory_consolidation_automation.md) — Eventually auto-run /memory-dream; lint+additive fixes can automate early, merges/deletes stay human-approved. Engine: .claude/skills/memory-dream/ + .claude/scripts/sync-memory.sh.
 - [Trebesch PST consolidation (staged)](project_trebesch_pst_consolidation.md) — Address-book CSV from 24 PSTs on DESKTOP-QNP3ON5; scripts staged at .claude/tmp/treb-*.ps1, WAITING for Howard's 6pm-MST 2026-06-01 go signal (attended run). See [[reference_trebesch_qnp3on5]].

.claude/memory/project_cascades_network_segments.md

@@ -0,0 +1,50 @@
+---
+name: project_cascades_network_segments
+description: Cascades of Tucson network segments + the CSC-ENT Wi-Fi SMB block that stalls NAS->CS-SERVER user migration
+metadata:
+  type: project
+---
+
+Cascades of Tucson NAS->CS-SERVER share migration — network reality discovered 2026-06-25.
+
+**CS-SERVER** (DC, RMM agent, Synology Drive sync target): IPs `192.168.2.248` (Ethernet) and
+`192.168.2.254` (Hyper-V vSwitch), both **/22 = `192.168.0.0/22`** (covers `.0`–`.3.255`).
+Domain `CASCADES` / `cascades.local`. SMB healthy — serves 13+ live sessions; shares under
+`D:\Shares\<name>` (Server, Management, Activities, Sales, etc.). Firewall SMB-In = Allow/Any.
+
+**Working SMB clients** live on `10.0.20.x` (routed, gw `10.0.20.1`) and `192.168.3.x` (on-link
+in the /22). Wi-Fi SSID for corporate = **`CSCNet`**.
+
+**Two Wi-Fi SSIDs (same AP family):** **`CSC ENT`** = `192.168.2.0/24`, gw `192.168.0.1`, **WPA2-PSK**
+(old NAS-side); **`CSCNet`** = `10.0.20.0/24`, gw `10.0.20.1`, **WPA3-SAE** (newer corporate). DNS =
+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.
+
+**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.
+
+**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.
+(2) **Security smell:** workstations are WORKGROUP (local logins) and reach CS-SERVER by storing a
+DOMAIN credential — Meredith's PC stores `cmdkey cs-server→administrator` (her Y:/X:/E: are mapped as
+domain admin). Shares `Server`/`Management` = share ACL **Authenticated Users:Full** (NTFS gates real
+access). Fix: stop storing admin creds on user PCs; scope shares to groups.
+
+Karen Rossini case (DESKTOP-LPOPV30, WORKGROUP, dual Wi-Fi): `CASCADES\karen.rossini` reset+vaulted
+(`clients/cascades-tucson/karen-rossini.sops.yaml`), added to `SG-IT-RW`, CS-SERVER cmdkey staged.
+She doesn't really use the Server folder (per Howard) so deprioritized. ALDocs is in
+`\\CS-SERVER\Server\ALDocs`. Repoint tooling = [[drive-map]] skill (but blocked by the CS-SERVER SMB
+instability above — fix that first).