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

## Update: 11:47 AZ — Billing on #32509

- Winter requested 0.5h remote labor on #32509, tech = Howard.
- Added line item 43169157 (Labor - Remote Business, 0.5 @ $150 = $75.00, taxable no).
- API quirk: `user_id` on add_line_item AND update_line_item both ignored — line stuck
  attributed to API key owner (1735/Mike). Stopped per skill hard rule; Winter corrected
  the tech to Howard and generated the invoice in the Syncro GUI herself.
- Invoice #67995 (id 1650972203), $75.00, ticket marked Invoiced (by Winter, GUI).
- Applied standard invoice note (no prepaid block -> block-rate upsell line). Bot alert posted.
