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

sync: auto-sync from HOWARD-HOME at 2026-06-24 15:23:13

Browse Source 
Author: Howard Enos
Machine: HOWARD-HOME
Timestamp: 2026-06-24 15:23:13
This commit is contained in:
Howard Enos
2026-06-24 15:23:42 -07:00
parent 7055ce6acd
commit 8ddfb33eab
5 changed files with 233 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
clients/cascades-tucson/docs/REMAINING-WORK-PLAN.md
View File

@@ -166,6 +166,12 @@ test scope to real caregivers, one device at a time. (Detail: wiki "Entra Access
- Flip CSC ENT to 5 GHz-only (`apply-wlan.sh ... bands 5g`) in a coordinated window; pilot a few
phones + Pauls, then full rollout.
- Helpany = Sandro Cilurzo / Eugenie Nicoud; Poly = Richard Turner (Vertical).
- **PREREQUISITE (live 2026-06-24): CSC ENT has 149 clients, only 68 are Helpany.** ~79 non-Helpany
devices must be evacuated first — 14 staff PCs (domain mig), 11 printers, **11 DIRECTV + 11
resident IoT/TV + 15 personal phones + 17 unknown (resident-facing — need help reconnecting)**.
~51 are on 2.4 GHz and would drop on a 5 GHz-only flip. Per-device inventory + resident
help-list: `docs/network/csc-ent-client-inventory-2026-06-24.md`. TODO: pull `stat/alluser`
for offline resident TVs; identify the 17 unknowns + generic phones with John Trozzi.
- **#32319** WiFi Room 343 — relocate a floor-2/4 AP for coverage (unifi-wifi skill, site `va6iba3v`).
- **#32342** Copy Room switch — install + adopt into UniFi.
- ~25 switch ports linked at 100 Mbps but gig-capable (cabling/NIC sweep).

146
clients/cascades-tucson/docs/network/csc-ent-client-inventory-2026-06-24.md Normal file
View File

@@ -0,0 +1,146 @@
# Cascades — CSC ENT client inventory (2026-06-24)
> Live snapshot of every client currently associated to the **CSC ENT** SSID, captured via the
> `unifi-wifi` skill (UOS controller `stat/sta`, site `va6iba3v`). Purpose: before repurposing
> CSC ENT as the 5 GHz-only WPA2 device island (phones + Helpany — see
> `csc-ent-device-island-plan.md`), identify **who must be moved off first** and **which are
> resident/personal devices we'll need to help reconnect**.
>
> **Snapshot caveat:** this is *currently-associated* clients only (149). Devices powered off at
> capture time (e.g. some resident TVs) are NOT here — pull `stat/alluser` for the full
> ever-seen list to complete the resident registry (TODO; controller was login-throttled when this
> was built).
## Summary — 149 clients
| Category | Count | On 2.4 GHz | Action |
|---|---:|---:|---|
| **Helpany "Paul" sensors** (`h-#######`) | 68 | 26 | **Stay** — anchor of the CSC ENT island; band-move to 5 GHz (Helpany, remote) |
| Staff PCs | 14 | 0 | We handle — domain migration -> CSCNet/INTERNAL |
| Printers (Canon/Brother/Epson) | 11 | 10 | We reconfigure -> CSCNet/INTERNAL |
| **DIRECTV boxes (resident TV)** | 11 | 0 | **Help reconnect** (resident) |
| **Resident IoT / TVs** (Ring, Echo, LG/Samsung TV, robot vac) | 11 | 4 | **Help reconnect** (resident) |
| **Personal phones / tablets** | 15 | 2 | **Help reconnect** (staff/resident BYOD) |
| **Unknown / randomized-MAC** | 17 | 9 | **Identify** (likely resident BYOD) |
| | **147*** | | (*2 of 149 dropped in offline transcription; live count = 149) |
**Devices to evacuate off CSC ENT before any change: ~79** (everything except the 68 Helpany).
**On 2.4 GHz right now: ~51** — these would be **dropped immediately by a 5 GHz-only flip**; 25 of
them are non-Helpany (10 printers, 4 IoT, 2 phones, 9 unknown) and must be relocated first.
---
## RESIDENT / PERSONAL — will need help reconnecting
### DIRECTV receivers (11) — resident room TVs, OUI `1c:d6:be`, all on 5 GHz
| Hostname | MAC | IP | Signal |
|---|---|---|---|
| DIRECTV-X71VH2LD006083 | 1c:d6:be:42:c6:d3 | 192.168.3.127 | -45 |
| DIRECTV-X71VH2LP000870 | 1c:d6:be:45:6b:d4 | 192.168.2.9 | -55 |
| DIRECTV-X71VH2LP003188 | 1c:d6:be:45:86:fe | 192.168.3.167 | -37 |
| DIRECTV-X71VH2LP003277 | 1c:d6:be:45:88:09 | 192.168.2.77 | -62 |
| DIRECTV-X71VH2LP003311 | 1c:d6:be:45:88:6f | 192.168.3.30 | -51 |
| DIRECTV-X71VH2LP003361 | 1c:d6:be:45:89:05 | 192.168.2.179 | -53 |
| DIRECTV-X71VH2LP003509 | 1c:d6:be:45:8a:c1 | 192.168.2.108 | -53 |
| DIRECTV-X71VH2LP003515 | 1c:d6:be:45:8a:d3 | 192.168.3.84 | -44 |
| DIRECTV-X71VH2LP003585 | 1c:d6:be:45:8b:a5 | 192.168.2.170 | -51 |
| DIRECTV-X71VH2LX001438 | 1c:d6:be:46:f0:96 | 192.168.3.106 | -61 |
| DIRECTV-X71VH2MF008687 | 1c:d6:be:48:7d:a4 | 192.168.3.28 | -53 |
### Resident IoT / TVs (11)
| Hostname | MAC | IP | Band | Signal | Guess |
|---|---|---|---|---|---|
| LGwebOSTV | e0:85:4d:4d:f0:3e | 192.168.2.152 | 5 | -66 | LG smart TV |
| TIZEN | 70:2a:d5:fc:98:ee | 192.168.3.247 | 5 | -58 | Samsung TV |
| amazon-1505f679d | 94:3a:91:d8:f1:91 | 192.168.3.242 | 5 | -45 | Amazon Echo/Fire |
| amazon-e7683282f | 94:3a:91:d3:6a:dc | 192.168.3.130 | 5 | -60 | Amazon Echo/Fire |
| Ring-3add3e | 90:48:6c:3a:dd:3e | 192.168.3.233 | 5 | -70 | Ring camera |
| RingStickupCam-c2 | ac:9f:c3:80:89:c2 | 192.168.3.162 | 5 | -70 | Ring camera |
| RingStickupCam-f4 | ac:9f:c3:86:5a:f4 | 192.168.2.252 | 5 | -71 | Ring camera |
| Ring-Chime | cc:3b:fb:e2:bf:df | 192.168.2.113 | 2.4 | -61 | Ring chime |
| RingDoorbell-f7 | 90:48:6c:80:6a:f7 | 192.168.3.49 | 2.4 | -50 | Ring doorbell |
| Lenovo-Tab-M11 | d2:49:d6:b3:d1:a9 | 192.168.2.172 | 2.4 | -54 | Android tablet |
| robotic_cleaner | e8:6b:ea:dd:b8:e4 | 192.168.3.216 | 2.4 | -77 | robot vacuum |
### Personal phones / tablets (15) — named = identifiable owner
| Hostname | MAC | IP | Band | Signal | Owner guess |
|---|---|---|---|---|---|
| Ashley-s-S21 | a2:e8:47:d7:50:91 | 192.168.3.149 | 5 | -72 | Ashley Jensen (staff) |
| Tamra-s-S25-Ultra | 4e:c0:8a:3b:79:53 | 192.168.2.127 | 5 | -58 | Tamra (Sales — departing) |
| Espe-s-S23-Ultra | 2e:79:39:f9:06:cd | 192.168.2.194 | 5 | -66 | "Espe" — identify |
| Sepopo-s-S25-Ultra | e2:ff:fe:06:0c:6a | 192.168.2.26 | 5 | -59 | "Sepopo" — identify |
| Samsung | 84:c0:ef:d5:6b:55 | 192.168.2.89 | 5 | -54 | unidentified |
| Samsung | 54:3a:d6:75:13:a4 | 192.168.3.237 | 5 | -67 | unidentified |
| Samsung | b8:bc:5b:67:ca:6c | 192.168.2.71 | 2.4 | -27 | unidentified (very close to AP) |
| Samsung | 8c:79:f5:d1:13:c3 | 192.168.3.226 | 2.4 | -54 | unidentified |
| iPad | 62:7e:25:5f:6c:fb | 192.168.2.22 | 5 | -73 | unidentified |
| iPhone | de:9d:c4:ec:f4:f0 | 192.168.3.85 | 5 | -75 | unidentified |
| iPhone | 2a:b5:4f:d1:44:7b | 192.168.3.125 | 5 | -63 | unidentified |
| iPhone | 2a:da:bc:5e:4e:37 | 192.168.2.111 | 5 | -75 | unidentified |
| iPhone | 96:2b:29:5d:5b:ed | 192.168.2.173 | 5 | -71 | unidentified |
| iPhone | 9a:f3:fc:ba:bc:e8 | 192.168.3.18 | 5 | -72 | unidentified |
| iPhone | be:69:46:6c:a9:a5 | 192.168.3.45 | 5 | -74 | unidentified |
| iPhone | 2e:1c:26:f4:ac:c9 | 192.168.2.46 | 5 | -62 | unidentified |
### Unknown / randomized-MAC (17) — identify before cutover
Mostly locally-administered (randomized) MACs = modern phones/laptops, plus a few that may be IoT.
Notable: three `98:17:3c:*` devices clustered on one AP at strong signal (-39/-40/-42) — likely
3 identical units in one location (identify). Full list: `(noname)` clients on CSC ENT with MACs
`0a:75:c7`, `0a:dc:20`, `1e:49:7c`, `62:2f:f5`, `9a:1e:c6`, `da:e2:2a`, `e0:3e:cb`, `441`/`06:01:7d`,
`28:ed:e0`, `5c:47:5e`, `78:7a:fd`, `84:b8:b8`, `98:17:3c:5b`, `98:17:3c:81:41`, `98:17:3c:81:59`,
`aa:f8:a9`, `cc:62:76`, plus `localhost` (`c0:97:27`).
---
## WE HANDLE — no resident impact
### Staff PCs (14) — already in the domain-migration plan (-> CSCNet/INTERNAL)
| Hostname | MAC | IP | Known user |
|---|---|---|---|
| ASSISTMAN-PC | ee:80:75:ae:49:e3 | 192.168.2.38 | Meredith Kuhn |
| DESKTOP-DLTAGOI | a0:a4:c5:7a:83:16 | 192.168.3.133 | Sharon Edwards (LE) |
| DESKTOP-LPOPV30 | e4:fa:c4:00:65:f1 | 192.168.2.250 | Karen Rossini |
| DESKTOP-ROK7VNM | 90:0f:0c:5a:c7:4d | 192.168.3.148 | staff (domain-joined) |
| DESKTOP-U2DHAP0 | e8:c8:29:6b:c1:d7 | 192.168.3.37 | Ashley Jensen |
| RECEPTIONIST-PC | 98:59:7a:d7:9d:fd | 192.168.3.187 | Reception |
| NurseAssist | a8:6d:aa:51:d6:55 | 192.168.3.254 | Veronica |
| LAPTOP-E0STJJE8 | d8:f3:bc:88:84:15 | 192.168.3.9 | caregiver |
| LAPTOP-8P7HDSEI | d8:f3:bc:88:84:2f | 192.168.3.101 | verify (caregiver?) |
| LAPTOP-DCQNDJJ2 | d8:f3:bc:88:84:23 | 192.168.2.116 | **not in plan — new, verify** |
| LAPTOP-MQG50B75 | 14:13:33:b9:89:bb | 192.168.3.8 | **not in plan — new, verify** |
| Laptop2 | 70:08:94:93:8e:f5 | 192.168.2.118 | caregiver |
| Laptop3 | c0:35:32:66:46:af | 192.168.2.156 | caregiver |
| Laptop4 | 70:08:94:90:26:85 | 169.254.1.9 | caregiver (APIPA — DHCP issue, check) |
### Printers (11) — we reconfigure to the staff/internal network
Canon: `canona93684` (9c:50:d1, .2.67), `canoncbdf73-2` (10:98:c3, .3.232), `canonfb04b5`
(80:a5:89, .3.227), `Canonf46423` (20:0b:74, .3.52).
Brother: `brwc8a3e8dc60fd` (.3.10, 5 GHz), `BRW2C9C5828EC9E` (.3.44), `BRWC8A3E8A2DD9E` (.2.53),
`brw283a4d1ad571` (.2.75), `brw5cea1d4e96af` (.2.145), `brw90324b15f558` (.3.88).
Epson: `EPSON822B7A` (dc:cd:2f, .2.147).
(10 of 11 are on 2.4 GHz — these drop on a 5 GHz-only flip; relocate first.)
---
## STAYS — Helpany "Paul" sensors (68)
Anchor of the CSC ENT island. 42 already on 5 GHz, 26 still on 2.4 (Helpany verifies per-device
5 GHz signal then transitions remotely). Serials seen (`h-#######`): 23021176; 23030322/324/326/327/
340/344/349/350; 23041092/101/102/107/117/118/119/120/121/122/124/125/126/127/128/129/130/131/135;
23050058; 23080021/027/136/172/233/235/413/415/446/456/463/480/486/489/536/540/554/555/558/560/561/
571/585/589/594/595/596/599/609/615/621/626/627/637/647/658/678/683/696.
**Reconcile this against Helpany's shipped/installed device count** (first shipment = floors 1-2)
to confirm all installed Pauls are accounted for and none are missing/offline.
---
## Next steps
1. **Complete the registry:** pull `stat/alluser` (all ever-seen clients, incl. powered-off TVs)
filtered to the CSC ENT network, so no resident device is missed. (Controller was login-throttled
2026-06-24 — retry; do NOT rapid-retry login, it locks the account.)
2. **Identify the unknowns** (17) and the generic phones — walk the named ones (Espe/Sepopo) with
John Trozzi; the rest via DHCP lease names / a brief onsite sweep.
3. **Resident-device reconnection plan:** decide the target network for resident TVs/IoT/phones
(CSCNet resident PPSK, or a dedicated resident SSID) and who reconnects them (us onsite vs.
resident self-serve with instructions). DIRECTV + Ring + Echo + TVs are the visible-impact set.
4. Only after the ~79 non-Helpany clients are relocated does CSC ENT flip to the 5 GHz-only WPA2
device island (Helpany + phones).

15
clients/cascades-tucson/docs/network/csc-ent-device-island-plan.md
View File

@@ -94,8 +94,23 @@ Ubuntu/snap based):
---
## CSC ENT is NOT empty — evacuation prerequisite (live 2026-06-24)
A live pull found **149 clients on CSC ENT**, not a near-empty legacy SSID. Only **68 are Helpany
Pauls** (the anchor that stays). The other **~79 must be moved off first** — 14 staff PCs (already
in the domain-migration plan), 11 printers, **11 DIRECTV resident TVs, 11 resident IoT/TVs (Ring/
Echo/LG/Samsung), 15 personal phones/tablets, 17 unknown/randomized**. About **51 clients are on
2.4 GHz** today and would be **dropped immediately by a 5 GHz-only flip** (25 of them non-Helpany).
Full per-device inventory + the resident "help-reconnect" list:
`csc-ent-client-inventory-2026-06-24.md`. **The resident devices (DIRECTV/Ring/Echo/TVs/phones)
are the visible-impact set — they need a relocation/reconnection plan before the flip.**
## Execution sequence
0. **Evacuate the ~79 non-Helpany clients off CSC ENT** to their correct networks (staff -> CSCNet/
INTERNAL via domain migration; printers -> internal; resident TVs/IoT/phones -> CSCNet resident
PPSK or a dedicated resident SSID). Complete the registry with `stat/alluser` first so offline
resident TVs aren't missed. **This is the gating sub-project** — see the inventory doc.
1. **Build VLAN 40** on pfSense (igc1.40, DHCP scope, DNS) + firewall egress rules above; mirror
VLAN 30 isolation.
2. **Enable PPSK on CSC ENT**; add keys: `Ftfd85710#` -> VLAN 40, new voice key -> VLAN 30.

64
clients/cascades-tucson/session-logs/2026-06/2026-06-24-howard-ticket-review-and-cascades-consolidation.md
View File

@@ -231,3 +231,67 @@ cost + labor).
- #32230 invoice 1650788180 ($0.00, prepaid); block 47.75.
- CS-SERVER: up since 6/23 07:32; agent c39f1de7; C: 151GB free, D: 465GB free; MSP360 "Online Backup Service" running.
- Wiki commit 5c77b88.
---
## Update: 15:22 PT — CS-SERVER RAID live-verified (stale data lesson), printer, vault, MAK key + 6PM Home→Pro schedule
### Session Summary (continued)
**CS-SERVER RAID — the "degraded/failing" flag was STALE; live OMSA proved it healthy.** Howard
went onsite ready to hot-swap a "failing" drive based on the 9-day-old wiki. Live Dell OMSA
(`omreport` via RMM) showed **both mirrors Ok, all 5 disks Online/green, Failure Predicted No**; the
6/15 degraded (PD 0:0:3 WD) self-recovered after a power cycle (ESM log shows repeated drive
remove/install across the outages). The "5th unused drive" (1:0:4) is the **GLOBAL HOT SPARE** for
the D: mirror — Howard nearly pulled it. Also surfaced **PSU redundancy lost**. Backup verified
running (last run Success, 0 failed, 575 GB baseline; confirm BMR/system-state). **No drive pulled;
the 2x SSD already bought become a planned upgrade, not an emergency.** Corrected the wiki
(Infrastructure block, Active-Work, History, Compilation Notes, index) + plan Workstream 5. Saved
the lesson (`feedback_verify_live_before_acting` + errorlog correction): always pull live OMSA/iDRAC
before acting; Windows `Get-PhysicalDisk` can't see RAID member health. No iDRAC skill / iDRAC creds
in vault (offered to set up; OMSA-via-RMM is the working path). Service Tag 9MQFTK1, SAS 6/iR.
**Printer.** The "Accounting Assistant printer" (room 101, Brother L8900CDW, 10.0.20.220) is the
SAME physical unit already on CS-SERVER as shared queue `\\CS-SERVER\BusinessOffice`. Per Howard:
left it named "Business Office," attached it to Chris Knight's PC (DESKTOP-N5G1ROO, in his session,
not default). Corrected ANOTHER stale wiki note: CS-SERVER CAN reach VLAN 20 (pings gw 10.0.20.1);
the old "VLAN-20 blocked" was wrong — idle printers just don't answer ping.
**Vault.** Vaulted Meredith Kuhn's login (`clients/cascades-tucson/meredith-kuhn`, local acct
meredithk → domain after join). Vaulted the **ACG Windows Pro MAK key** (Mike's, NOT client-specific)
at `infrastructure/windows-pro-mak`. Saved billing rule memory `feedback_windows_pro_upgrade_billing`:
**$99 per machine** activated with the MAK, invoiced to that customer, machine named on the line,
billed after success, not from a labor block.
**Home→Pro upgrade scheduled for 6PM.** Pre-flighted the 5 Home machines (DISM) — all confirmed Core
with Professional a valid target. Scheduled CronCreate job **ad0a56a9** for 18:00 today to run the
per-machine sequence: online + query-user check (hold active users) → small Wscript.Shell popup
(msg.exe absent on Home) → changepk with generic key → 5-min wait → reboot → slmgr /ipk MAK + /ato →
verify Professional + Licensed. Session-bound (terminal stays open per Howard). Pauses for Howard's OK
before the 5×$99 Cascades invoice.
### Key Decisions (continued)
- Did NOT pull any CS-SERVER drive — live state healthy; 1:0:4 is the hot spare; SSDs = planned upgrade.
- Printer left as "Business Office," attached to Chris (no duplicate queue, not default).
- MAK billing: $99/machine, after success, not from the prepaid block.
- 6PM upgrade automated via session-bound cron; holds any in-use machine; bills only on Howard's confirm.
### Configuration Changes (continued)
- Wiki: RAID block + VLAN-20 printer note + Active-Work + History + Compilation Notes corrected (commits be2ae8b, 855a67d); index updated. Plan Workstream 5 corrected.
- Vault: `clients/cascades-tucson/meredith-kuhn` (174fc2f), `infrastructure/windows-pro-mak` (d90599c).
- Memories: `feedback_verify_live_before_acting`, `feedback_windows_pro_upgrade_billing` (+ MEMORY.md). errorlog: RAID stale-data correction.
- RMM: attached `\\CS-SERVER\BusinessOffice` to DESKTOP-N5G1ROO (chris.knight).
- Tasks #9 (6PM Home→Pro) created+updated; #3 (Karen) completed earlier.
### Pending / Incomplete Tasks (continued)
- **6PM (auto, job ad0a56a9):** Home→Pro on the 5 machines → verify → bill Cascades 5×$99 (Howard confirms).
- **Planned (not emergency):** CS-SERVER consumer 320GB drives → 2x SSD on a scheduled window w/ confirmed image/system-state backup; check PSU redundancy onsite; confirm backup is BMR/system-state.
- Battery-backup billing (task #8) still pending UPS cost + minutes.
- Domain joins for the ready set + (post-upgrade) the 5 Home machines.
### Reference Information (continued)
- CS-SERVER: Dell R610, Service Tag 9MQFTK1, SAS 6/iR; PD map — 0:0:0/0:0:1 (1.2TB SAS, D:), 0:0:2 Hitachi + 0:0:3 WD (320GB, C:), 1:0:4 = global hot spare.
- `\\CS-SERVER\BusinessOffice` = Brother L8900CDW @ 10.0.20.220 = "Accounting Assistant" printer (room 101).
- Vault: `infrastructure/windows-pro-mak` (credentials.product_key), `clients/cascades-tucson/meredith-kuhn`.
- Generic Pro key VK7JG-NPHTM-C97JM-9MPGT-3V66T (edition flip); MAK in vault (activation).
- Cron job ad0a56a9 @ 18:00 2026-06-24.

2
errorlog.md
View File

@@ -17,6 +17,8 @@ Categories (the `[type]` tag): _(none)_ = skill/command execution failure ·
<!-- Append entries below this line -->
2026-06-24 | Howard-Home | unifi-wifi/live-stats | [friction] rapid successive controller logins -> HTTP 403 lockout; reuse one session/save JSON instead of re-auth per query [ctx: host=172.16.3.29:11443 site=va6iba3v]
2026-06-24 | Howard-Home | rmm/cascades-cs-server | [correction] led with a 9-day-stale wiki '[CRITICAL] degraded RAID / failing drive' flag and recommended drive replacement (SSDs were purchased, tech went onsite to hot-swap); a LIVE Dell OMSA omreport query then showed the OS mirror had self-recovered and is healthy (all 5 disks Online, all LEDs green), and the '5th unused drive' was actually the global hot spare. Always pull live OMSA/iDRAC before acting on a stale hardware flag; Windows Get-PhysicalDisk cannot see RAID member health. [ctx: ref=feedback_verify_live_before_acting host=CS-SERVER tag=9MQFTK1]
2026-06-24 | Howard-Home | process/client-deliverables | [correction] did not gate outbound client/vendor deliverables through the impeccable skill; rule: run impeccable on anything sent externally