sync: auto-sync from GURU-BEAST-ROG at 2026-07-07 11:01:13

Author: Mike Swanson
Machine: GURU-BEAST-ROG
Timestamp: 2026-07-07 11:01:13
This commit is contained in:
Winter Williams
2026-07-07 11:02:20 -07:00
committed by ClaudeTools Bot
parent 27595d6475
commit a0a86742bc

View File

@@ -0,0 +1,101 @@
# The Prairie Schooner — Tina web outage (dead DHCP DNS) — 2026-07-07
## User
- **Executed by:** ClaudeTools Discord Bot (GURU-BEAST-ROG)
- **Requested by:** Winter Williams (@winterguru, via Discord) - tech
- **Role:** automation (acting on the requester's behalf)
## Session Summary
Winter reported via Discord (#tech-department) that Tina at The Prairie Schooner could not
reach websites from her computer while the office internet and other systems were up.
Located the machine in GuruRMM via rmm-search: TPS-Tina (agent id
c8d76770-dc9e-45b7-94c7-fdcab3e105a2, online), one of 4 Prairie Schooner agents (Mel-PC,
TPS-SERVER, TPS-SVR, TPS-Tina). Ran a series of remote diagnostics via ps-encoded.sh
dispatch (SYSTEM and user_session contexts).
Diagnosis: the machine gets DNS from DHCP (router 192.168.1.1) with three servers:
192.168.1.125 (TPS server / TPS.local DC) plus 199.85.26.20 and 199.85.27.20 — both dead
(retired Norton ConnectSafe service). Confirmed both dead servers time out on queries while
192.168.1.125 resolves fine. When Windows rotated to a dead resolver, all web traffic
appeared down (ping/gateway/raw TCP fine — classic intermittent "can't reach any website").
Initial SYSTEM-context HTTP tests timed out entirely; later tests returned 200, consistent
with intermittent failure.
Fix applied: pinned TPS-Tina's NIC DNS statically to 192.168.1.125 only, flushed DNS cache.
Verified: google.com resolves, tps.local resolves (192.168.1.120), HTTPS to google returns
200 in both SYSTEM and Tina's user session.
Created Syncro ticket #32509 (Resolved, 4 Urgent, assigned Winter/1737) with initial issue
and full resolution comments. Bot alerts posted to #dev-alerts (RMM fix) and #bot-alerts
(ticket).
## Key Decisions
- Pinned static DNS on the NIC as immediate relief rather than waiting for a router DHCP
fix — reversible, and the machine is domain-joined so DC-only DNS is correct posture.
- Did NOT add a public fallback DNS (domain-joined machine; avoids split-resolution issues).
- Ticket created per Winter's explicit request; priority set to 4 Urgent per her instruction.
- No billing added yet — Winter had not specified minutes at save time.
## Problems Encountered
- First SYSTEM-context HTTP test timed out on all URLs while DNS/ping/TCP worked; subsequent
tests passed — consistent with the intermittent dead-resolver rotation (and possibly AV
scan load from same-day Datto EDR deploy).
## Configuration Changes
- TPS-Tina (Prairie Schooner): NIC "Ethernet 2" IPv4 DNS changed from DHCP-issued
(192.168.1.125, 199.85.26.20, 199.85.27.20) to static 192.168.1.125. DNS cache flushed.
- No repo config changes.
## Credentials & Secrets
- None created or discovered. Vault paths accessed: infrastructure/gururmm-server.sops.yaml
(RMM API auth, via rmm-auth.sh). Vault searched for Prairie Schooner router creds — only
clients/prairie-schooner/gururmm-site-main.sops.yaml exists (no router credentials).
## Infrastructure & Servers
- Site network: 192.168.1.0/24, gateway/DHCP = router 192.168.1.1 (brand/creds unknown).
- TPS server: 192.168.1.125 (DNS for TPS.local domain). tps.local resolves to 192.168.1.120.
- TPS-Tina: 192.168.1.139, DHCP, domain-joined to TPS.local, Intel I219-LM NIC.
- GuruRMM agents (Prairie Schooner): Mel-PC, TPS-SERVER, TPS-SVR, TPS-Tina — all online.
- Dead DNS servers still in DHCP scope: 199.85.26.20, 199.85.27.20 (Norton ConnectSafe,
service retired ~2018).
## Commands & Outputs
- rmm-search.sh -c "prairie schooner" → 4 agents.
- Diagnostics dispatched via .claude/scripts/ps-encoded.sh (temp scripts, deleted after):
ipconfig/ping/DNS/HTTP/proxy/hosts; TCP connect + AV inventory + fltmc; HTTP retry +
adapters/routes; user-session HTTP + per-DNS-server Resolve-DnsName; DHCP vs static reg
check; Win32_NetworkAdapterConfiguration + domain membership; final DNS pin + verify.
- Key outputs: 199.85.26.20/27.20 Resolve-DnsName timeout; DhcpNameServer reg value
"192.168.1.125 199.85.26.20 199.85.27.20"; post-fix "DNS now: 192.168.1.125", web 200.
- AV inventory on TPS-Tina: Windows Defender + Sentinel Agent + Bitdefender EST + Datto AV
(Datto EDR deployed 2026-07-07 per GPS audit project). McAfee Safe Connect VPN installed,
services mccspsvc + SafeConnectService running. Hosts file has McAfee/autodiscover
redirect entries. TAP-Windows adapter present (disconnected).
## Pending / Incomplete Tasks
- [ ] Fix at source: remove 199.85.26.20/27.20 from router (192.168.1.1) DHCP DNS options —
affects ALL DHCP machines at Prairie Schooner (Mel-PC etc.). Needs router credentials
(not in vault) or onsite access.
- [ ] Uninstall McAfee Safe Connect junk VPN from TPS-Tina (awaiting Winter's go-ahead).
- [ ] Review AV stack with Howard: 4 engines on TPS-Tina (Defender/SentinelOne/Bitdefender/
Datto EDR) — is SentinelOne a leftover?
- [ ] Billing on ticket #32509 if Winter provides minutes.
## Reference Information
- Syncro ticket: #32509, id 113581381 — https://computerguru.syncromsp.com/tickets/113581381
- Syncro customer: The Prairie Schooner, id 3664974. Ticket comments 422573917 (Initial
Issue), 422573928 (Resolution).
- GuruRMM agent TPS-Tina: c8d76770-dc9e-45b7-94c7-fdcab3e105a2.
- Discord thread: 1524109428582908086 (#tech-department).
- Related project: projects/gps-rmm-audit (Prairie Schooner cid 3664974, EDR deploy Monday
2026-07-07; TPS billed $10/mo backup with no backup found — separate open item there).