# 2026-04-17 Session Log — Howard ## User - **User:** Howard Enos (howard) - **Machine:** ACG-TECH03L - **Role:** tech --- ## [FOR MIKE] Vault hygiene — Cascades pfSense password While troubleshooting John Trozzi's WiFi issue at Cascades, I pulled the pfSense creds from the vault and the password was wrong. - **Stale entry (leave as-is for now):** `clients/dataforth/cascades-router.sops.yaml` contained `admin / a6A6c6fe` — this does not work on the actual Cascades pfSense. - **Correct password:** `Th1nk3r^99` - **New entry created:** `clients/cascades-tucson/pfsense-firewall.sops.yaml` — verified encrypts/decrypts correctly with the right password. - **Also misfiled:** the stale entry is under `clients/dataforth/` but the device belongs to Cascades, not Dataforth. Likely a copy-paste leftover from the Dataforth work. **Action item for you:** decide whether to update the dataforth entry with the correct password, rename/move it, or delete it. Left untouched at your request pending your call. --- ## Cascades — ongoing work (in progress) ### 1. Folder Redirection silent-skip (Sharon Edwards) **Status:** Root cause likely identified; parked to chase John's WiFi issue. Investigation confirmed: - FR CSE runs cleanly, fires events 1000 → 1006 (`Documents has to be redirected`, flags `0x1231`) → 1007 (`no folders previously redirected`) → 1001 with **nothing in between** and **no `fdeploy.log` entry** even after fixing permissions on `C:\Windows\Debug\UserMode\` (ACL had Users read-only, fixed to Modify). - Ruled out: OneDrive KFM (not installed), Offline Files service (running), ownership on `D:\Homes\sharon.edwards` + `\Documents` (both owned by `CASCADES\Sharon.Edwards`), stale history (contradicted by 1007 firing). **Leading hypothesis:** the `0x200` bit in the flag word `0x1231` indicates **"Redirect folders on primary computers only"** is enabled somewhere in the GPO tree. When FR evaluates that policy and the user's `msDS-PrimaryComputer` attribute is empty or doesn't include the current machine, FR silently skips — no error, no debug log entry. Fits the fingerprint exactly. **Howard's note on design intent:** Cascades wants classic "log in anywhere, files follow you" FR. "Primary computer only" is the **opposite** of that design and should NOT be set. So the fix is to find the GPO enabling that policy and disable it, not to populate Sharon's `msDS-PrimaryComputer`. **Next step when we resume:** 1. Run ADSI check to confirm `msDS-PrimaryComputer` is empty on Sharon and capture DESKTOP-DLTAGOI's DN (Howard has the command ready). 2. `Get-GPResultantSetOfPolicy -User CASCADES\sharon.edwards -Computer DESKTOP-DLTAGOI` then grep for `PrimaryComputer` to find which GPO sets it. 3. Disable that single setting in the offending GPO (Not Configured). 4. Sign Sharon out/in, watch for event 1013. Full playbook: `C:\Users\howar\.claude\plans\immutable-imagining-spring.md` --- ### 2. John Trozzi WiFi (MAINTENANCE-PC) **Status:** Working at EOD but root cause not nailed down — fragile. Symptoms: - Machine connects to CSCNet (VLAN 20 INTERNAL, 10.0.20.0/24), hostname `MAINTENANCE-PC`, MAC `0c:ef:15:76:84:09` - Gets IP (`10.0.20.96`) but initially bounces APs at strong signal (-55 to -60 dBm) and DNS times out - Works fine on legacy CSC ENT (192.168.0.0/22) - Built-in Realtek 8822CE NIC disabled (`Not Present`) — known flaky. Replaced with TP-Link USB MU-MIMO adapter one week ago - Today the driver was updated on the TP-Link; immediately after, adapter went to APIPA (`169.254.232.130`) - pfSense had an active lease for his MAC at 10.0.20.96 the whole time - After some combination of actions (driver settle / release/renew / Windows healing), internet started working again — **exact trigger unknown** **Why this is fragile:** The TP-Link USB adapter has a 2019-era driver (per version string). USB WiFi adapters on UniFi with modern SSID features (802.11r/k/v, PMF, band steering) are a chronic pain point — the bouncing-at-strong-signal fingerprint points squarely at client-side roaming/driver behavior. Worked fine on CSC ENT because that SSID is simpler/legacy. **Recommended hardening before it recurs:** 1. On John's PC: Device Manager → TP-Link adapter → Power Management tab → uncheck "Allow the computer to turn off this device to save power." 2. Windows WiFi settings → CSCNet → Properties → set "Random hardware addresses" to **Off** (pin his MAC). 3. Pull the latest TP-Link driver from tp-link.com for his exact model (HardwareID still not captured — do this next time onsite). 4. In UniFi Controller, check CSCNet SSID advanced settings: Fast Roaming (802.11r), Minimum RSSI, Band Steering, PMF. Something recent changed that triggered this today after a week of stable operation. 5. Long-term: replace the TP-Link USB with a known-good enterprise USB adapter, OR get the built-in Realtek functional with a current driver (preferred — PCIe beats USB for WiFi every time). --- ## Conversation thread — Claude coordination - Ollama integration discussion (earlier): Howard's laptop (Dell Inspiron 14 5441, Snapdragon X Plus, 16 GB RAM, ARM64, no CUDA) is NOT a good fit for Mike's documented Ollama setup (`qwen3:14b`, `codestral:22b`). Recommended remote Ollama on Mike's workstation + Tailscale, or small-models-local only. Parked.