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

**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`.

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