sync: auto-sync from ACG-TECH03L at 2026-04-17 11:26:41

Author: Howard Enos
Machine: ACG-TECH03L
Timestamp: 2026-04-17 11:26:41

session-logs/2026-04-17-howard-session.md

@@ -0,0 +1,71 @@
+# 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.