Exchange Online's Get-MessageTrace deprecation pushes PowerShell admins to V2 cmdlets

Microsoft is retiring the legacy Message Trace tooling

Microsoft has started switching off the legacy Message Trace experience in Exchange Online, covering both the old interface in the Exchange Admin Center and the PowerShell cmdlets Get-MessageTrace and Get-MessageTraceDetail. According to a migration guide published on dev.to, the replacements — Get-MessageTraceV2 and Get-MessageTraceDetailV2 — are already generally available.

The timeline, which the article attributes to Microsoft's Message Center notice MC1092458, has two milestones. Deprecation of the legacy EAC interface and the old cmdlets began on September 1, 2025. Deprecation of Reporting Web Service support for Message Trace data, which older integrations rely on, follows from March 18, 2026. Scripts still calling Get-MessageTrace keep running through a transition period, but the dev.to post does not cite a date for the final shutoff, and its central warning is blunt: administrators who wait until the cmdlet fails will discover the breakage during a live mail-delivery incident, when the script is needed most.

The replacement experience entered public preview in December 2024 and reached general availability in the EAC under Mail flow > Message Trace. Citing Petri, the article lists a modernized interface, finer delivery-status filters such as "Quarantined" and "Filtered as spam", customizable columns per account, and timestamps that follow the admin's configured timezone.

How the V2 cmdlets behave differently

The new syntax resembles the old one, but Microsoft's documentation, as summarized on dev.to, describes several behavioral changes:

• No -Page or -PageSize. The V2 cmdlet drops paged retrieval. To continue past a result limit, a script passes -StartingRecipientAddress together with -EndDate, taking the recipient address and received time from the last record of the previous query.
• Ninety days of history, ten days per query. The new experience can search up to 90 days back, but each individual call is capped at a 10-day interval, so larger ranges must be sliced into chunks.
• Leaner, more targeted queries. Microsoft recommends -ResultSize to bound the volume returned, narrowing the start and end dates, filtering with -SenderAddress, and using -MessageTraceId whenever possible. The trace ID is in fact mandatory for messages sent to more than 1,000 recipients.
• UTC output. Unlike the UI, the cmdlet returns timestamps in UTC, so scripts that compare against local times need conversion logic.

For following a single message end to end, the documented pattern replaces the old Get-MessageTraceDetail call with a pipeline: run Get-MessageTraceV2 with a -MessageTraceId, then pipe the result into Get-MessageTraceDetailV2. That surfaces granular per-event statuses — received, delivered, delayed, blocked, in quarantine — with more precision than the legacy tooling offered.

Migrating scheduled automation

Admins with scheduled tasks, Azure Automation runbooks or monitoring jobs that produce delivery reports, email SLA metrics or bounce alerts get a practical checklist from the article:

• Sweep the script repository for references to the old cmdlets, for example with Select-String matching Get-MessageTrace and Get-MessageTraceDetail across .ps1 files.
• Rename calls to the V2 cmdlets, remove -Page and -PageSize, and add loops built on -StartingRecipientAddress and -EndDate where result volumes are high.
• Test against a window of a few hours before querying the full history, keeping the 10-day per-call cap in mind.
• Validate timezone handling, since the V2 output is UTC.

The author also suggests treating the migration as an audit opportunity: check whether each report or alert still earns its keep, and consider whether the new status distinctions — separating "Filtered as spam" from "Quarantined", for instance — would make mail-flow reporting more useful.

Why it matters

Mail-flow diagnostics scripts tend to be written once and touched only when something breaks. A deprecation that surfaces mid-incident strips admins of their primary investigation tool at the exact moment it is needed. The migration effort itself is modest — mostly a rename plus pagination and timezone adjustments — but the semantic differences, such as the missing page parameters, the 10-day query cap and the required trace ID for mass mailings, will defeat a naive find-and-replace. With the legacy cmdlets in deprecation since September 2025 and Reporting Web Service support winding down from March 18, 2026, teams that have not yet inventoried their automation are betting their incident response on an undated grace period.