azcomputerguru/claudetools
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
f157795fb7fdb66b7f1ba1c9c5a6897420019027
claudetools/session-logs/2026-04-17-howard-session.md
Howard Enos 32888ea9d4 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
2026-04-17 11:26:46 -07:00

5.2 KiB
Raw Blame History

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.
Reference in New Issue View Git Blame Copy Permalink