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

sync: auto-sync from GURU-BEAST-ROG at 2026-07-23 10:55:23

Browse Source 
Author: Mike Swanson
Machine: GURU-BEAST-ROG
Timestamp: 2026-07-23 10:55:23
This commit is contained in:
Winter Williams
2026-07-23 10:56:11 -07:00
committed by ClaudeTools Bot
parent 625d4012fb
commit e51469779a
2 changed files with 44 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

40
clients/prairie-schooner/session-logs/2026-07/2026-07-23-winter-melpc-quickbooks-drive-map.md
View File

@@ -111,3 +111,43 @@ on-site — same letter/target, no conflict. Issue resolved.
- Dev-alerts posts: 1529894134406578256 (diagnostics), 1529896180975276253 (drive map).
- Requesters: Winter (opened thread), Howard (root cause + hand fix, closed thread).
- Skills used: rmm-search, /rmm, drive-map.
## Update: 10:54 AZ — GPO conflict found and fixed (Howard, follow-up in same thread)
Howard asked why the server rebooted — it had NOT. TPS-SVR last boot 2026-07-07 8:30 PM
(15d uptime), zero shutdown/boot/WU events in 7 days. Earlier reboot speculation was wrong:
a .QBW.ND file is rewritten on every client connect and is NOT evidence of a reboot (logged
as errorlog --correction). Note: 15d uptime on the DC = July patches likely not applied yet.
Howard then asked to verify TPS-JAYMI had the Q: map. No active user session, so read the
Network key from all user registry hives cold (reg load NTUSER.DAT per profile): NO
persistent drive maps for jaymi, guru, or localadmin. Howard said the map "was supposed to
already be set up" and approved GPO.
GPO audit on TPS-SVR found the true root cause of the whole incident:
- GPO "QB Drive Map - Q to TPS-SVR" (26450217-4f5e-4857-be36-a165267aafa8, created/modified
2026-07-19) correctly maps Q: -> \\tps-svr\Quickbooks, action=Replace, persistent=1,
linked at domain root order 5, Authenticated Users GpoApply. Someone (likely Howard) had
already set this up.
- BUT Default Domain Policy (31b2f340-016d-11d2-945f-00c04fb984f9, link order 1 = higher
precedence) contained a stale 2017 GPP drive map: Q: -> \\tps-server\quickbooks (the
DECOMMISSIONED offline server), action=Update, persistent=0. Because DDP wins conflicts,
it clobbered the good Q: map at every logon — explaining why the drive kept vanishing on
Mel-PC and never appeared on TPS-JAYMI.
Fix applied on TPS-SVR (cmd 73dbd6bd):
- Backup-GPO of Default Domain Policy -> C:\Backups\GPO-DDP-20260723 (backup id
f14f2a34-8859-486f-8f02-ce62356de63e); stale Drives.xml preserved as
C:\Backups\GPO-DDP-20260723\DDP-stale-Drives.xml.
- Removed USER\Preferences\Drives\Drives.xml from DDP SYSVOL folder.
- Bumped GPO user version 393218 -> 458754 in both AD (versionNumber on the GPC object) and
GPT.INI so clients reprocess.
- Verified only the QB Drive Map GPO's Drives.xml remains in SYSVOL.
Result: next logon, all domain users get Q: -> \\tps-svr\Quickbooks with no conflicting
policy. GPP drive maps apply at logon (not background refresh) — Jaymi gets it at next
sign-in. Dev-alerts: 1529909620741767238. Diagnostic cmds: 35f2d6e0 (boot history),
94edbbda (TPS-JAYMI hive audit), 4a721cd2 (GPO audit), 73dbd6bd (fix).
Remaining follow-ups: TPS-SVR pending July patch reboot (maintenance window); Syncro
ticket still not logged (no response to offer).

4
errorlog.md
View File

@@ -19,6 +19,10 @@ Categories (the `[type]` tag): _(none)_ = skill/command execution failure ·
<!-- Append entries below this line -->
2026-07-23 | GURU-BEAST-ROG | drive-map | drive-map verify failed on TPS-JAYMI [ctx: cmd=6169a053-ab39-4366-a00c-755d4d4bdbf8]
2026-07-23 | GURU-BEAST-ROG | rmm/qb-diagnostics | [correction] speculated TPS-SVR rebooted because .ND file regenerated at 8:48 AM; server uptime was 15 days - a QB .ND file is rewritten on every client connect, it is NOT evidence of a server reboot
2026-07-23 | GURU-5070 | bash/api-pagination | [friction] Hardcoded page guard silently truncated a paginated pull: looped customers with '[ $P -gt 30 ] && break' at 100/page = capped at 3000 of 5082 real records, and the N<100 terminator never fired because every page was full. Produced a confident but 41%-incomplete dedupe. Always compute pages from meta.total_entries and assert the pulled count matches
2026-07-23 | GURU-5070 | syncro/customers-search | GET /customers?query= returned ZERO results for 'enclose', 'Open Enclose', 'Barrins', 'openenclose' despite customer 2549923 having business_name='Open Enclose' / fullname='Colt Barrins'. Search silently excludes disabled customers - do not treat an empty query result as proof a customer does not exist [ctx: endpoint=/customers?query cust=2549923]