Files

Howard Enos e359702837 gps-rmm-audit: CP-QB WMI-repaired+enrolled (112/189); IMC-PRINTSERVER agent installed, blocked by box-wide outbound TLS drop

CP-QB: corrupt WMI class store (Win32_Processor invalid class) killed the universal
installer's arch check; mofcomp cimwin32.mof fixed it; enrolled + reassigned to
Curtis Plumbing. IMC-PRINTSERVER: agent+watchdog installed manually over LAN HTTP
from IMC1 (PowerShell dead on box, SMB hangs, SC extension eats chains/multiline);
box drops ALL outbound TLS (incl google) so agent cannot connect — fix is at IMC
UniFi gateway or local filter; no reinstall needed. Session log + tracker updated.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

2026-07-05 01:00:48 -07:00

5.4 KiB

Raw Blame History

GPS->RMM audit: CP-QB fixed+enrolled (WMI repair); IMC-PRINTSERVER installed but TLS-blocked

Date: 2026-07-05 (late 2026-07-04 MST evening through ~01:00) Session: HOWARD-HOME/claude-main Context: Continuing the GPS->GuruRMM coverage audit (projects/gps-rmm-audit). The only two target machines online over the holiday weekend were CP-QB (Curtis Plumbing) and IMC-PRINTSERVER (Instrumental Music Center) — both Monday-queue items whose installer pushes had failed with unreadable error files.

User

User: Howard Enos (howard)
Machine: Howard-Home
Role: tech

Outcome summary

CP-QB: FIXED + ENROLLED. Root cause: corrupt WMI class store (Win32_Processor = Invalid class, HRESULT 0x80041010; broken since ~2022 — also why its SC GuestInfo was frozen at 2022). The universal installer dies on Get-CimInstance Win32_Processor (line 30). winmgmt /verifyrepository reported CONSISTENT (self-check does not catch a missing class); mofcomp %windir%\system32\wbem\cimwin32.mof restored the class. Re-ran the installer clean, service Running, enrolled into Staging, reassigned to Curtis Plumbing via reassign-staging.py. Enrollment now 112/189. Curtis Plumbing 5/6.
IMC-PRINTSERVER: agent fully installed, service RUNNING, but CANNOT connect — the box silently drops ALL outbound TLS (rmm.azcomputerguru.com/Cloudflare, rmm-api direct IP 72.194.62.10, even https://www.google.com — all hang right after ClientHello; no error, no ServerHello). ScreenConnect still works because its relay protocol is not TLS. LAN traffic works. DNS resolves correctly (no sinkholing). The installed agent will self-connect the moment TLS egress is unblocked — nothing more to do on the box itself.

IMC-PRINTSERVER diagnostic findings (hard-won, reusable)

Machine: Win10 Pro 22H2 (19045), 192.168.0.79/24, gw 192.168.0.254, DNS/DHCP = IMC1 (192.168.0.2). SC session ccbd66a7-f94a-4d87-a18b-5f81a30784d0.

powershell.exe never executes via SC on this box (every installer push is a PS one-liner -> all silently died; also wedges the SC command queue when tried). Plain single-line cmd /c ... commands work.
SC extension command constraints (likely instance-wide, discovered here):
- SendCommandToSession output is NOT retrievable via the API; session model holds ONE queued event slot; a hung command wedges the queue and later sends are lost.
- Commands containing & chains or embedded newlines (multi-line batch) never execute.
- Rapid-fire sequential single commands work while the executor is healthy.
Readback channel built: temporary PowerShell HttpListener on IMC1 (via RMM command, port 8765/8766 + temp firewall rule, auto-removed) — PRINTSERVER reports via curl.exe -G --data-urlencode d@<file> over LAN. Nginx-access-log-as-channel also works for boxes with working egress: GET https://rmm.azcomputerguru.com/install/<code>/windows?gpsdiag=<tag>&d=<msg> (CF allows the install path; /gps-diag paths get CF 403), read via the gururmm server's own root agent (grep gpsdiag /var/log/nginx/access.log).
SMB copy from \IMC1\NETLOGON hung (possibly broken secure channel — box is generally rotten). Workaround that worked: HTTP file server on IMC1:8766 (HttpListener serving the agent exe+toml), PRINTSERVER downloads via curl. Files verified on disk: C:\Program Files\GuruRMM\gururmm-agent-new.exe (5,673,288 bytes) + agent.toml.
Manual no-PowerShell install recipe (worked): short paths avoid quoting — cmd /c C:\PROGRA~1\GuruRMM\gururmm-agent-new.exe install then cmd /c net start GuruRMMAgent. Agent log confirms: service installed, watchdog installed, config loaded, "Connecting to wss://rmm-api.azcomputerguru.com/ws" — then silence (TLS black-hole).
TLS block evidence: curl schannel verbose stops after ALPN offer for BOTH Cloudflare hosts AND google.com; no "Connected to" / no handshake failure line; -o file never created. All-destination TLS drop => per-device gateway rule (IMC UniFi?) or local WFP/AV filter remnant. NOT domain filtering, NOT DNS.

Next actions (IMC-PRINTSERVER)

Check IMC's UniFi gateway (192.168.0.254) for a per-device/VLAN rule throttling 192.168.0.79 / MAC A0-1E-0B-11-60-1D (TLS/DPI, IoT isolation, or ad-block profile).
If gateway clean: hands-on look for broken local network filter (AV remnant/WFP). Bitdefender presence unconfirmed (probe was stopped).
No reinstall needed afterward — agent + watchdog are installed and will connect on their own once TLS egress works. Then reassign out of Staging (reassign-staging.py) and push Datto EDR per the Monday recipe.

Also this session

Verified plan state at start: 111/189, 24 clients short (progress-check dry-run); GPS-RMM-AutoEnroll (Mon 06:00, 30-min) and GPS-RMM-Progress (daily 8:07) tasks armed.
GuruRMM install-reports endpoint checked: empty (installs die before reporting).
Scratch files left in repo root (gitignored-ish dotfiles): .gps-diag-cmds*.txt, .gps-fix-cpqb*.txt, .gps-imc-listener*.json, .gps-imc1-stage.json, .gps-listener-cid.txt, .gps-diag-imc*.txt, .gps-imc-fileserver.json — safe to delete.
Coord messages received (other session, FYI): SPEC-030 edits swept into repair-batch-2 commit 333ceef (being split back out); 2 CONFIRMED review findings on uninstall-engine.ps1 (PID-recycle kill risk at :459; missing never-kill guard at :432) to fix before committing SPEC-030 work.

5.4 KiB Raw Blame History