azcomputerguru/claudetools
1
0
Fork 0
Code Issues 59 Pull Requests Actions Packages Projects Releases Wiki Activity

sync: auto-sync from HOWARD-HOME at 2026-06-30 10:37:25

Browse Source 
Author: Howard Enos
Machine: HOWARD-HOME
Timestamp: 2026-06-30 10:37:25
This commit is contained in:
Howard Enos
2026-06-30 10:37:58 -07:00
parent 6cc0c08ac4
commit 5e92c33b73
4 changed files with 172 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

73
.claude/memory/project_cascades_vlan20_migration_routing.md Normal file
View File

@@ -0,0 +1,73 @@
---
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. 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.<x>: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\<share>` 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\<share>"` (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 <inf> /install`, `Add-PrinterDriver -Name "<exact INF model 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]].