Files
claudetools/wiki/clients/attrebesch.md
Howard Enos a6a3585266 sync: auto-sync from HOWARD-HOME at 2026-06-01 22:49:04
Author: Howard Enos
Machine: HOWARD-HOME
Timestamp: 2026-06-01 22:49:04
2026-06-01 22:49:12 -07:00

10 KiB

type, name, display_name, last_compiled, compiled_by, sources, backlinks
type name display_name last_compiled compiled_by sources backlinks
client attrebesch AT Trebesch 2026-06-01 Howard-Home/claude-main
clients/attrebesch/session-logs/2026-06-01-session.md
projects/gururmm

AT Trebesch

Residential client in Tucson, AZ. Single workstation. Syncro customer 238740. Onboarded into GuruRMM 2026-06-01. Primary active work: PST contact consolidation (Syncro #31953) — final CSV delivered and imported; pending source-PST unmount to clear address-book aggregation duplicates.


Profile

  • Company type: Residential (individual)
  • Contract type: [unverified — check Syncro]
  • Billing rate: [unverified]
  • Key contact: treb737@earthlink.net | 520-529-4999
  • Address: 7280 N. Cathedral Rock, Tucson AZ
  • Syncro customer ID: 238740
  • Open tickets: #31953 (address book / contact recovery — import done, PST unmount pending), #32160 (assess for threats)

Infrastructure

Workstations

  • DESKTOP-QNP3ON5 — Windows, single local user Owner. Agent ID ba173f0c-19e8-488d-834c-1b6f6dfd5699. Outlook = Microsoft 365 Apps x64, 16.0.19929.20172. Free space: C: 593 GB, D: 915 GB.
    • Runs a third-party Explorer shell replacementWin32_Process explorer.exe owner detection returns blank. Use Win32_ComputerSystem.UserName to detect the logged-on user (DESKTOP-QNP3ON5\Owner). See memory note reference_trebesch_qnp3on5.md.

Email & Identity

  • Outlook / PST-based (no M365 tenant confirmed). Client uses earthlink.net email (treb737@earthlink.net). Very large PST archive collection (~155 GB across 24 files).
  • M365 tenant: Not documented. Outlook is M365 Apps x64 but no tenant-side management confirmed.

Network

  • ISP / WAN: [unverified]
  • Firewall: [unverified]

GuruRMM

  • Client name: AT Trebesch
  • Client ID: a6dbe776-c3b0-4345-8c2c-597cff8a9b4d
  • Site name: Main
  • Site ID: 2df75e13-4268-49db-babe-489b66729f87
  • Site code: SWIFT-LION-2892
  • Install page: https://rmm.azcomputerguru.com/install/SWIFT-LION-2892
  • Agent enrollment key: Encrypted at clients/attrebesch/gururmm-site-main.sops.yaml (vault; do not regenerate unless compromised)

Enrolled Agents

Agent OS Agent ID User Notes
DESKTOP-QNP3ON5 Windows ba173f0c-19e8-488d-834c-1b6f6dfd5699 Owner Third-party Explorer shell; use Win32_ComputerSystem.UserName for session detection

Access


Patterns & Known Issues

  • Third-party Explorer shell — logged-on-user detection blank. Win32_Process explorer.exe .GetOwner() returns empty. Workaround: (Get-WmiObject Win32_ComputerSystem).UserName correctly returns DESKTOP-QNP3ON5\Owner. Apply this to any WMI-based session-detection scripts targeting this machine.
  • PST email field corruption. Source address book E-mail Address (Email1Address) field contained junk single-letter values for ~95% of contacts (666/695 rows). Real emails were scattered across E-mail Display Name, additional email fields, and Notes free-text. Any contact-extraction pipeline for this client must reconstruct real (@-bearing) emails from all available fields and key dedup on real-email-or-name — never on Email1Address alone.
  • Contacts stored in Notes free-text. Phone numbers, street addresses, and secondary emails are encoded in the Notes field rather than in structured columns. A parse+enrich pass is required to populate Outlook's standard phone/address/email columns.
  • Heavy PST duplication. 24 PST files total but only 16 are unique (byte-identical copies across Desktop\Outlook\backup\ and D:\E). Deduplicate by name+size before mounting to avoid redundant AddStore work.
  • Large unmounted PSTs take ~9s per AddStore (Outlook reads only the store index). Two 48 GB Outlook2.pst files each took ~9s and turned out to contain real address books (793 and 725 contacts). Do not skip large archives without probing — they may hold contact data.
  • Run COM scripts in user_session context. Outlook COM requires the Owner session; SYSTEM context fails. GuruRMM command context must be user_session for treb-extract.ps1.
  • Outlook CSV import: write NO BOM. Outlook's CSV importer auto-maps by field name; a UTF-8 BOM corrupts the first column header and causes Outlook to silently skip that field (emails and phones come in blank). Always write CSV files with UTF-8 encoding and no BOM for Outlook import.
  • Outlook CSV import: use the exact official 92-column template. Use Outlook's "Sample CSV file for importing contacts.csv" headers verbatim. Non-template or reordered headers cause Outlook to silently drop those fields.
  • Outlook CSV import: leave Birthday/Anniversary blank. Invalid dates (e.g., 0/0/00 from contacts with no date set) are rejected on import. Leave date fields empty rather than passing a zero date.
  • Outlook import ADDS to a folder — never replaces. Importing into a folder that already contains contacts produces duplicates. Always empty the target Contacts folder (via COM or manually) before importing a fresh file.
  • Mounted source PSTs aggregate in the Outlook address book. The Outlook address book displays contacts from ALL mounted PST stores plus Suggested Contacts, so leftover source PSTs appear as duplicates even when the target Contacts folder is clean. After a contact-import migration, unmount all source PSTs and clear Suggested Contacts to eliminate the aggregation effect.

Active Work

Ticket Summary Status
#31953 Address book / contact recovery — 666-contact CSV imported into Outlook; PENDING: unmount 4 source PSTs + clear Suggested Contacts In progress — final step pending
#32160 Assess for threats — pairs with /rmm diagnose once agent reporting confirmed Open

PST Contact Recovery (Syncro #31953)

Goal: Extract all address-book contacts from the client's 24 PSTs and consolidate into one Outlook-importable CSV.

Pipeline:

  1. treb-extract.ps1 — Phase 1: Outlook COM in user_session; mounts each unique PST via AddStore, reads real address-book folders (excludes Suggested Contacts / Recipient Cache), captures raw JSON per PST with FullName/FileAs/Subject fields. MaxMB cap skips large unmounted stores (mounted stores always read); $MaxMB=0 overrides.
  2. treb-merge.ps1 — Phase 2: runs as SYSTEM; unified identity model (EmailsOf + BestName functions; union-find dedup over email, clean First+Last, FullName/FileAs/Subject, email-derived name, raw mangled name signals); reconstructs real emails from all four email fields + email-split-across-name-fields; keys on real-email-or-name, never on junk Email1Address.
  3. treb-enhance.ps1 — Phase 3: non-destructive; parses phones, street addresses (high-confidence "street, City, ST ZIP" pattern), and emails from Notes into structured Outlook columns; Notes left verbatim.
  4. treb-fixaddr.ps1 — Phase 4: street-line cleaning (drops stray leading numbers and embedded newlines); 4 targeted address corrections from Notes.
  5. treb-template.ps1 — Phase 5: rebuilds into Outlook's exact 92-column template, UTF-8 no BOM, blank invalid dates.

Final deliverable: C:\claudetools\.claude\tmp\treb-data\Contacts-outlook.csv (Howard-Home) = C:\Users\Owner\Desktop\default.csv (DESKTOP-QNP3ON5). 666 contacts, 92-col Outlook template, UTF-8 no BOM, 622 emails (all valid), 200 phones, 65 clean addresses, 267 notes, 0 duplicate emails, 0 duplicate names. Import confirmed: Contacts folder emptied (929 -> 0), re-imported clean (664 contacts now in default Contacts folder).

Scripts: .claude/tmp/treb-extract.ps1, treb-merge.ps1, treb-enhance.ps1, treb-fixaddr.ps1, treb-template.ps1, treb-dedup.ps1, plus local path-swapped copies (treb-merge-local.ps1, treb-enhance-local.ps1) for Howard-Home iteration.

Data (local): C:\claudetools\.claude\tmp\treb-data\ — 15 per-PST JSON files + pipeline CSVs (Contacts-clean.csv, Contacts-final.csv, Contacts-outlook.csv). Source ZIP on Owner box: C:\Users\Owner\Desktop\Contacts\treb-contacts-data.zip.

Pending steps:

  • AWAITING Howard go: unmount 4 leftover source PSTs (Outlook1.pst, Outlook.pst, archive1.pst, backup.pst) from Outlook profile + clear Suggested Contacts (639) via RMM — these are causing the address book to show aggregate duplicates from the source stores despite the clean Contacts folder.
  • Log time + resolution note on Syncro #31953.
  • Optional: a few genuine cross-email same-person pairs remain unmerged (Ron Snyder, Judy Stout/U OF A JUDY, Irene/Reenie Keating, Philomina Bime) — ambiguous, acceptable residual.
  • Optional: clean up intermediate CSVs from Desktop\Contacts and _work JSONs.

History Highlights

Date Event
2026-06-01 Howard: GuruRMM onboarding — client + Main site created, SWIFT-LION-2892 enrollment key vaulted. DESKTOP-QNP3ON5 confirmed enrolled and checking in.
2026-06-01 PST inventory scan: 24 files, ~155 GB. COM probe confirmed Outlook COM works in Owner session; 794/374/366 contacts in three live stores; archive1.pst contact-empty.
2026-06-01 ~20:16 MST Extraction executed (Owner session via RMM): safe set first (771 unique), then all-PSTs (826 unique — giants held real address books). Notes-enrichment pass added. Email field corruption found: Email1Address was junk single letters; rewrote merge to reconstruct real emails. Re-ran corrected pipeline: 821 unique, 0 junk emails.
2026-06-01 ~21:08 MST Multi-pass data cleaning on Howard-Home (local iteration): unified identity model (union-find over 5 dedup signals), derived-name + raw-name dedup to collapse last duplicates. Final: 6118 raw -> 674 unique contacts, 0 invalid emails, 0 duplicate groups.
2026-06-01 ~22:46 MST Import troubleshooting: diagnosed BOM-corrupted header causing Outlook to drop email/phone fields; rebuilt into exact 92-col Outlook template, UTF-8 no BOM. Fixed address-field artifacts (treb-fixaddr.ps1). Emptied default Contacts folder (929->0) via COM; pushed clean file (666 contacts, 622 emails) to Owner Desktop as default.csv via RMM (gzip+base64 chunks). Import succeeded: 664 contacts confirmed in default Contacts. Perceived "Tim Gleason duplicates" traced to leftover mounted source PSTs aggregating in address book — fix is PST unmount, not more deduping.