10 KiB
User
- User: Mike Swanson (mike)
- Machine: GURU-5070
- Role: admin
Session Summary
Multi-client continuation session covering Dataforth, Birth Biologic, and Peaceful Spirit, plus
closing out a prior /save. First, the Birth Biologic Calm Ops media upload (background task from the
prior session) was found to have failed: 33 docs uploaded but all 10 large media files died at chunk
0 (connection-closed-on-send + 503) using 60 MB chunks. The uploader was fixed (10 MiB chunks,
Expect:100-continue disabled, -MediaOnly switch to skip the already-uploaded docs); re-upload was
prepared but the user indicated the media was handled, so it was not re-run.
Second, a Dataforth issue from John Lehman: test database file 5BMAIN.DAT updated 6/26 shows in
K:\TS-*\ProdSW\5BDATA but production DOS test stations don't pick it up on restart. Loaded the
DOS-test-machine context and traced the whole pipeline via AD2's RMM agent (read-only). Confirmed
the updated 5BMAIN.DAT (6/26, 83,200 B) is staged correctly on AD2 AND on the D2TESTNAS NAS the
stations pull from — so sync is healthy. Root cause: NWTOC.BAT v5.0 (deployed 2026-03-16), the
on-boot updater, copies only *.BAT (from T:\COMMON\ProdSW) and *.EXE (from T:\Ate\ProdSW);
its own note reads "removed DATA folder copies (avoid cyclic overwrites)," so stations stopped
refreshing master spec DATs (5BMAIN/8BMAIN/DSCMAIN4/SCTMAIN/7BMAIN). CHECKUPD detects updates but
NWTOC never applies them. Per Mike's instruction the work was parked: opened Syncro ticket #32489
(Scheduled), booked a Wednesday 2026-07-01 8:00 AM appointment, and posted a customer-visible note
telling John the fix lands Wednesday with a validation method.
Third, Birth Biologic flagged a "broken" Excel file in the QualitySystemsDepartment SharePoint site.
Resolved the share link via Graph (read-only): the 64,466-byte ".xlsx" is actually ASCII text —
space-separated decimal byte values starting 80 75 3 4 (= the PK zip signature). A broken upload
wrote the byte array as a stringified decimal list instead of raw bytes. Reconstructed the 19,124
real bytes into a valid xlsx (verified OOXML structure + real contact data: "Processor Contact
Information"). The file was created by our Tenant Admin app on 6/26, implying a systemic bug in that
migration batch. Built a recovery tool (bb-recover.py) that enumerates the site's libraries,
detects the decimal-text signature, reconstructs + validates each, and re-uploads in place; launched
a dry-run scan of the QualitySystemsDepartment site (still running at session end).
Fourth and largest: Peaceful Spirit deletion-scope investigation. Mara worried other files
disappeared with Glennda's. A live-filesystem mtime scan flagged 13 client folders changed in the
6/24 10:05-12:05 window across the alphabet — initially read as "widespread," but a per-folder
restore-point diff (cbb) showed those were DELETED=0, added=1 (normal new scans, not deletions),
confirming the mtime heuristic was noise. Pivoted to Mike's approach: restore the pre-deletion state
to staging and diff locally. Verified space (C: 803 GB free; @Clients = 72.5 GB / 142,288 files),
stopped the MSP360 backup, and launched a staging restore of the 6/24 10:05 AM restore point to
C:\PST-Recovery\PreDelete-0624. A second restore of the oldest point (6/29/2025) is queued to
check whether mass deletion happened before. Both restores feed fast local diffs.
Key Decisions
- Parked the Dataforth NWTOC fix to a scheduled Wednesday appointment rather than fixing live —
it touches every test station's boot and needs John to confirm the authoritative master-spec
file list first. Fix will be NWTOC v5.1: copy ONLY engineering-owned master spec files one-way
from
T:\Ate\ProdSW\*DATA, avoiding the cyclic-overwrite the v5.0 change guarded against. - Recovered the corrupt BirthBio xlsx by parsing decimal-byte text back to binary rather than treating it as data-loss — the original file was intact inside the text. Only auto-replace files whose reconstruction yields a known binary magic (PK/%PDF/OLE/PNG/etc.); others flagged for review.
- Abandoned the live-mtime heuristic for PST deletion scope after the cbb diff proved the flagged folders were additions, not deletions. Adopted restore-to-staging + local diff as the trustworthy, complete method (catches victim folders the mtime scan hides because they were touched later).
- Ran the two PST restores sequentially (not concurrently) to avoid a same-bunch usage lock; staged to C: (most free space) rather than D: (VM files) or G: (the live data drive).
- Logged a root-level multi-client session log (spans 3 clients) — no single wiki article implied.
Problems Encountered
- BirthBio media upload failed (10/10 large files, 60 MB chunks) — fixed uploader to 10 MiB chunks + Expect:100-continue off + per-chunk retry; re-run deferred (user handled media).
- SSH-as-SYSTEM on AD2 could not use sysadmin's key (
Permission denied (publickey,password)) — the RMM agent runs as SYSTEM; used the rsync daemon (password auth) for read-only NAS listing instead. - cwRsync (cygwin) on AD2 misread a Windows
C:\pathDESTINATION as a remote host; single-file pulls silently failed. Fix: use/cygdrive/c/...for the local destination. (Logged as friction.) - Read the wrong (inactive) sync script first (
Sync-FromNAS.ps1, SCP); the scheduled task actually runsSync-FromNAS-rsync.ps1. Confirmed via the task action. - PST scope: 60s/folder cbb listing × ~2,500 folders made a full tree diff infeasible interactively; resolved by the restore-and-local-diff approach.
- Bash 120s tool timeout repeatedly cut polling of long RMM commands; mitigated with detached server-side jobs writing to files, polled across calls.
Configuration Changes
- Syncro: created ticket #32489 (Dataforth, Scheduled) + 2 comments + appointment id 5626864474 (Wed 2026-07-01 8:00-9:00 AM MST, Remote).
- PST-SERVER: MSP360 backup "Files Backup 2025" STOPPED (must restart after restores).
- PST-SERVER: created restore plan
ZPreDelete0624(run-once) → restoring toC:\PST-Recovery\PreDelete-0624(in progress); alsoC:\PST-Recovery\scope-diff.ps1(detached diff job) anddeletion-scope-report.txt. - Local repo: removed stray
.pst_sweep/.pst_when(prior session); no other repo edits this session. - Scratch (not committed):
scratchpad/bb-recover.py,upload-calmops.ps1(fixed),.bbfile.xlsx(broken),.bbfile.recovered.xlsx(recovered).
Credentials & Secrets
- BirthBio Tenant Admin app (Graph): vault
msp-tools/computerguru-tenant-admin.sops.yaml, fieldcredentials.client_secret. Tenant19a568e8-9e88-413b-9341-cbc224b39145, client709e6eed-0711-4875-9c44-2d3518c47063. - Dataforth D2TESTNAS rsync daemon: host 192.168.0.9 port 873, module
test(=/data/test), userrsync/IQ203s32119(fromSync-FromNAS-rsync.ps1). NAS root SSH key on AD2:C:\Users\sysadmin\.ssh\id_ed25519(usable only as sysadmin, not SYSTEM). - Dataforth AD sysadmin:
INTRANET\sysadmin/Paper123!@#. No new secrets created.
Infrastructure & Servers
- Dataforth AD2: 192.168.0.6, RMM agent
cfa93bb6-0cdc-4d4e-a29e-1609cda6f047. Sync task runsSync-FromNAS-rsync.ps1every 15 min.testshare =C:\Shares\test. StrayTS-21\ProdSWis a file (not dir) → syncErrors=1/LastResult=1each run (cleanup pending, not the cause). - DOS update chain: AUTOEXEC -> STARTNET (maps T:=\D2TESTNAS\test, X:=datasheets) -> NWTOC v5.0
(COMMON\ProdSW *.BAT to C:\BAT, Ate\ProdSW *.EXE to C:\ATE) -> CTONW. Master spec DATs live in
Ate\ProdSW\*DATAand per-stationTS-*\ProdSW\*DATA; COMMON\ProdSW\5BDATA is empty. - BirthBio QualitySystemsDepartment site id
birthbiologic.sharepoint.com,3173c017-58bd-406a-8858-2c969667336f,ab1e4b4f-0f71-4c15-a4b4-fa900c189ac3, one library "Documents", broken-file parent driveb!F8BzMb1YakCIWCyWlmczb09LHqtxDxVMpLT6kAwYmsM7NUY4oPLSRq7ng3tJq-E9. - PST-SERVER: 192.168.0.2, RMM agent
87293069-33b6-45e8-a68f-6811216cdb96. MSP360 bunch6a121575-84a0-4e98-9c0f-4a656d1a5132, account ACG-PST084b5069-d634-434b-84a2-971b1dcb4b43, prefix PST-SERVER, cbbC:\Program Files\Arizona Computer Guru\Online Backup\cbb.exe. - PST restore points: oldest
20250629170034(6/29/2025 10:00:34 AM, Full); pre-incident20260624170506(6/24 10:05:06 AM); post-deletion20260624190522(6/24 12:05:22 PM). - PST volumes: C: 803.5 GB free / D: (VM Files) 109.9 / G: (data) 193.3. @Clients = 72.5 GB / 142,288 files.
Commands & Outputs
- Graph share resolve:
GET /shares/u!<base64url>/driveItem. Reconstruct:bytes(int(t) for t in text.split()). - cbb restore to alt location:
cbb addRestorePlan -n <name> -aid 084b5069-... -bp PST-SERVER -bunch 6a121575-... -restorePoint <id> -rt "<date>" -d "G:\Shares\Scanned\@Clients" -rl "<destpath>" -ro yes -deleted yesthencbb plan -r "<name>". Stop backup:cbb plan -s "Files Backup 2025". - cbb
listis NON-recursive, ~60s/folder;-rlocation= original|path;-d= source dir. - PST scope-diff sample: every mtime-flagged folder =
DELETED=0 added=1(adds, not deletions).
Pending / Incomplete Tasks
- CRITICAL: PST-SERVER backup "Files Backup 2025" is STOPPED — must restart after restores complete.
- PST restore #1 (
ZPreDelete0624→ C:\PST-Recovery\PreDelete-0624) IN PROGRESS (72 GB from B2). - PST restore #2 (oldest
20250629170034→ C:\PST-Recovery\Oldest-20250629) — launch after #1 finishes. - PST local diffs: (a) PreDelete-0624 vs LIVE = complete deleted-file list + repair source (copy-back no-overwrite); (b) oldest vs pre-incident = "has this happened before."
- BirthBio QualitySystemsDepartment scan (bb-recover.py dry-run) running — review list, then run
--applyto recover+replace in place. - BirthBio Calm Ops media (10 files) re-upload still available if needed (uploader fixed).
- Dataforth ticket #32489 — Wed 2026-07-01 8a: confirm master-spec file list with John, build NWTOC v5.1, test on TS-3R, roll out; cleanup AD2 TS-21 stray + NAS COMMON\ProdSW junk; build John a validation BAT.
Reference Information
- Syncro ticket #32489 id 113201089; appointment 5626864474; Dataforth Corp customer 578095; John Lehman contact 2851723.
- RMM API
http://172.16.3.30:3001. Graphhttps://graph.microsoft.com/v1.0. - Recovery tool:
scratchpad/bb-recover.py. Recovered sample:.bbfile.recovered.xlsx. - Server artifacts:
C:\PST-Recovery\(rps.txt, deletion-scope-report.txt, scope-diff.ps1, PreDelete-0624, Glennda_0605, Gtest).