--- name: project_cascades_vlan20_migration_routing description: Cascades CSC ENT->VLAN20 migration — pfSense WAN_Group policy-route breaks LAN<->VLAN20; fix + printer-migration mechanics metadata: type: project --- Cascades is migrating staff machines + printers off the flat old LAN (192.168.0.0/22, "CSC ENT") onto the isolated **Staff VLAN 20 (10.0.20.0/24, gw 10.0.20.1)** ("CSCNET"). Printers are being re-IP'd to 10.0.20.x (static) and re-shared on the CS-SERVER print server. **PROGRESS (live-reconciled 2026-07-01):** MACHINES are essentially done — 22 online hosts on VLAN 20; only CS-SERVER (stays by design) + ~6 stragglers (ASSISTMAN-PC, CascadesProxess, Laptop2, NurseAssist, 2 roaming laptops) remain on 192.168.x. PRINTERS lag — only 4 of 15 CS-SERVER shares repointed to 10.0.20.x (FrontDesk .221, BusinessOffice .220, LifeEnrichment .94, MCReception .78); 11 shares still on old-LAN IPs (MCMedTech still stale 192.168.2.53 though target 10.0.20.74 is live+reachable). GPO still NOT fleet-live (silent new-driver-install gap open: reboot vs pre-stage drivers). MEMCARE-STATION rename staged but not yet applied. Full live inventory (all shares/ports/machines): clients/cascades-tucson/docs/printer-gpo-map.md. Key operational facts learned 2026-06-30 (Howard, front-desk ET-5800 + Life Enrichment Canon MF741CDW): **pfSense gotcha (the big one):** CS-SERVER (on the old LAN) could not reach ANY VLAN 20 printer (.221/.220/.94/.78:9100) even though it pinged the VLAN20 gateway 10.0.20.1. Root cause was NOT a block — the LAN "Default allow LAN to any" rule has **Gateway = WAN_Group** (dual-WAN policy routing), so LAN->internal-VLAN traffic gets shoved out the WAN and dies. **Fix = a pass rule at the TOP of the LAN interface** (Firewall/Rules/LAN), Source = CS-SERVER 192.168.2.248, Dest = 10.0.20.0/24, protocol any, **Gateway = default** (do NOT set WAN). This bypasses the policy route so internal traffic routes normally. Scoped to the server's source IP => residents (own /28 VLANs) + guests (VLAN 50) can't match it (rule is on the LAN interface, sourced from the server only). This also un-broke the already-migrated Business Office/Life Enrichment/MC Reception shares. VLAN20->server (SMB) was already fine. **pfSense SSH from the VPN is BLOCKED** (tcp/22 dropped; GUI 443 open). The `unifi-wifi` skill's `pfsense-ssh.sh` therefore returns empty (it sends ssh stderr to /dev/null). Did the rule via the GUI instead. To use the skill remotely later, add an OpenVPN-side allow for 22. **Printer migration mechanics:** - CS-SERVER side: repoint the share's port to TCP_10.0.20.:9100 (Set-Printer -PortName), drop the old 192.168.2.x port; keep the same ShareName so client mappings survive. - Client side: mapping `\\CS-SERVER\` as a standard domain user triggers a PrintNightmare elevation prompt (HRESULT 0x800702e4) EVEN when the driver is already local — see [[feedback_rmm_printer_elevation]] / errorlog. Promptless options: GPO printer deployment (they already do this for caregivers — the scalable answer), or push as SYSTEM via `rundll32 printui.dll,PrintUIEntry /ga /n"\\CS-SERVER\"` (per-machine, appears at the user's NEXT logon), or set Point-and-Print "Approved server = CS-SERVER" so user- context maps are promptless+immediate. - Old room-named shares (e.g. `1F-132-RecRoom-Canon`) were renamed on the server during migration, leaving ORPHANED per-user client mappings; a spooler restart auto-drops them. - Build UNC paths in RMM PowerShell with `[char]92`, not literal `\\` (jq/agent pipeline mangles literal backslashes — [[feedback_windows_quote_stripping]]). **Point-and-Print is the REAL promptless fix (proven 2026-06-30 on the LE machines).** The 0x800702e4 prompt AND the `/ga` per-machine path silently failing at logon (PrintService event 513, error 0xBCB) are BOTH the same default `RestrictDriverInstallationToAdministrators` (ON when unset) blocking the standard user from pulling the driver. We're domain admin, but the *end user* isn't — so apply admin rights via the Point-and-Print policy: `HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Printers` `RestrictDriverInstallationToAdministrators=0` + subkey `PointAndPrint` `Restricted=1,TrustedServers=1,ServerList=CS-SERVER,InForest=0,` `NoWarningNoElevationOnInstall=1,UpdatePromptSettings=2` (scopes silent install to CS-SERVER only). After that, `WScript.Network.AddWindowsPrinterConnection` in the user session is promptless+immediate. **Correct durable fix = put this in a computer GPO fleet-wide** (the caregiver machines already have it; that's why their printer GPO works), then deploy printers via GPO. Existing GPOs: `CSC - Life Enrichment Printers`, `CSC - Printer Deployment`, `CSC - Caregiver Workstation`, `CSC - Reception Workstation Policy` (the LE one likely still pushes the OLD share name — repoint it to the new share). **Driver/PDL trap — Canon MF741/743 = UFR II ONLY (not PCL).** The rebuilt `LifeEnrichment` share was created with **Canon Generic Plus PCL6**; the MF741 can't parse PCL → spools OK, nothing prints, panel shows **Error #822** (unsupported/corrupt data). Fix = use the **UFR II** driver (`Canon Generic Plus UFR II V250`, INF cnlb0ma64.inf). CS-SERVER only had PCL6/PS3/XPS staged; pulled UFR II from a client's DriverStore (`C:\Windows\System32\DriverStore\ FileRepository\cnlb0ma64.inf_amd64_*`) using the vaulted `cs-server` `sysadmin` domain-admin cred. **Transfer direction matters:** CS-SERVER (192.168.2.x) CANNOT reach a client's C$ (client host-firewall scopes File/Print sharing to LocalSubnet, and CS-SERVER is off-subnet) -> have the CLIENT push to `\\CS-SERVER\C$` instead (client->server SMB works). Then `pnputil /add-driver /install`, `Add-PrinterDriver -Name ""`, `Set-Printer -DriverName`. Get the exact driver name from the INF's quoted strings, not a guess. When the server driver changes, refresh each client connection (Remove+AddWindowsPrinterConnection) so it drops the stale cached PCL6 driver. Related: wiki clients/cascades-tucson (network/VLANs), [[project-cascades-migration-plan]].