---
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).