The two engines
Interactive (real-time-ish, ~10 days, fast): Get-MessageTrace / the EAC UI — the daily tool. Historical (up to 90 days, batched, downloadable): Start-HistoricalSearch — the investigation tool. The V2 cmdlets (Get-MessageTraceV2) modernised paging and fields — pin to them, because the classic cmdlets' row caps silently truncate big searches (the 'trace showed nothing' that was 'page 2 you never saw').
The per-recipient discipline
A trace SUMMARY hides forks (life-of-a-message concept): one message, N recipients, N outcomes — 'Delivered' can conceal a failed fork. Mastery is expanding to Get-MessageTraceDetail per recipient on any multi-recipient dispute and reading EVENTS in order (RECEIVE → EXPAND → rules → verdict → DELIVER/FAIL/DEFER). The far-side SMTP response in the FAIL detail is the most under-read line in Exchange.
Building signal from traces
Aggregated traces answer questions individual ones can't: delivery-latency percentiles (received→delivered → p50/p95 — the Pulse EXO metric), failure-reason distributions (the NDR ledger, generated), deferral trends (queue health without a queue viewer). Traces are not just forensics — they're the raw telemetry of a system that shows you no other dials.
What to watch (proofs)
- Right engine per job: interactive for today, historical for last month — using historical for a live issue wastes the batch lag.
- Per-recipient reflex: detail-not-summary on multi-recipient cases — one fork missed is one 'but it says delivered' escalation.
- V2 in automation with paging handled — the truncation bug designed out.
- The aggregate build: a scheduled trace-to-percentiles job feeding the latency chart — traces graduating to monitoring.