azcomputerguru/claudetools
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
227e1a4fceaed6c43834053f2a3e2230ec6f0743
claudetools/wiki/clients/attrebesch.md
Howard Enos f7c18f0f23 sync: auto-sync from HOWARD-HOME at 2026-06-02 00:30:09 
Author: Howard Enos
Machine: HOWARD-HOME
Timestamp: 2026-06-02 00:30:09
2026-06-02 00:30:16 -07:00

12 KiB
Raw Blame History

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-02 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) — clean 666-contact CSV delivered and imported (~660 contacts in main Contacts folder, one merged Tim Gleason, emails populating); 4 source PSTs re-mounted after accidental unmount; Suggested Contacts (639) cleared (not reversible); pending clarification from Howard on next step before any further action.

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 succeeded, awaiting Howard clarification on final step), #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 replacement — Win32_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.
  • Do not unmount a client's mounted PSTs to resolve address-book aggregation without explicit confirmation. The Outlook address book aggregates contacts from ALL mounted PSTs plus Suggested Contacts, so the same person can appear multiple times even when the target Contacts folder is clean — but the mounted PSTs are the client's own data and setup. Resolve by confirming the exact target folder to clear before acting; do not unmount PSTs unless the client or tech explicitly authorizes it. (An accidental unmount of 4 source PSTs on 2026-06-02 was immediately reverted via AddStore; files were never deleted. The PSTs are at C:\Users\Owner\Desktop\Outlook{Outlook1.pst, Outlook.pst, archive1.pst, backup.pst}.)

Active Work

Ticket Summary Status
#31953 Address book / contact recovery — 666-contact CSV imported (~660 contacts in main Contacts, emails populated); Suggested Contacts cleared (639, not reversible); 4 source PSTs re-mounted after accidental unmount; PENDING: Howard clarification on what to clear next In progress — awaiting Howard
#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 (~660 contacts now in default Contacts folder, one Tim Gleason, emails populating).

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 clarification: confirm what "clear the contacts" means before taking further action. Leading guess = empty the main Contacts folder (~660) to re-import fresh. PSTs must remain mounted per Howard's instruction.
  • Note: Suggested Contacts (auto-harvest cache, 639 entries) was cleared on 2026-06-02 and is not reversible (cache only, not real data).
  • 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.
2026-06-02 ~00:27 MST Howard imported default.csv: ~660 clean contacts, one Tim Gleason, emails populating. Reported duplicate Gleasons; COM probe confirmed they are in OTHER mounted PSTs (Outlook1, Outlook) and Suggested Contacts — not in the main folder. Over-interpreted "clear the contacts" instruction: unmounted 4 source PSTs AND cleared Suggested Contacts (639) via RMM. Howard corrected immediately — PSTs must remain mounted. All 4 PSTs re-mounted via AddStore (files never deleted; profile restored to 5-store state). Suggested Contacts clearing is not reversible (auto-complete cache only). Awaiting Howard's clarification on actual next step before any further action.

Backlinks

Reference in New Issue View Git Blame Copy Permalink