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