Exchange Online administrators are waking up to a transformed message tracing landscape after Microsoft moved the new Message Trace experience to general availability in June 2025. The update introduces modernized cmdlets, a redesigned UI, and a strict tenant-wide throttling limit of 100 queries per 5 minutes—a cap that demands immediate script rewrites for any organization using automated message tracing. Meanwhile, Microsoft has delayed the retirement of the legacy Reporting Webservice REST endpoint to February 28, 2026, but offers no direct REST replacement at GA, leaving SIEM and SOAR integrations in a precarious gap.

The new Get-MessageTraceV2 and Get-MessageTraceDetailV2 cmdlets replace the decade-old Get-MessageTrace and Get-MessageTraceDetail. They require Exchange Online PowerShell V3 module version 3.7.0 or later and discard classic pagination in favor of a round-based retrieval model. Instead of -Page and -PageSize, you now use -ResultSize (default 1000, maximum 5000) and then chain subsequent calls by using the Received timestamp of the last record along with -StartingRecipientAddress. This change promises more efficient bulk extraction but upends years of accumulated scripting logic.

Microsoft’s rollout timeline has been adjusted multiple times in response to community feedback. The GA began in mid-June 2025 and completed worldwide by late July, as confirmed in the Exchange Team Blog on August 25, 2025. Legacy message trace UI and old cmdlets will start deprecating on September 1, 2025, giving administrators only a few weeks to migrate all automation. The Reporting Webservice—widely used for REST-based integrations—was originally slated for a quicker sunset, but after pushback from enterprises, Microsoft extended support to February 28, 2026, with deprecation actions starting in March 2026. A public preview of Message Trace in Microsoft Graph is tentatively planned for November 2025, though no firm commitment or SLA exists.

Throttling That Redefines Throughput

The 100-requests-per-5-minute tenant limit applies to both Get-MessageTraceV2 and Get-MessageTraceDetailV2. This is a hard cap, not a recommendation. Microsoft frames it as a protection against abuse, but large organizations that run frequent, automated traces—for compliance audits, TLS reporting, or SIEM ingestion—will feel immediate pain. A tenant that previously pulled daily message flows with hundreds of parallel queries now faces a tenfold reduction in throughput without architectural changes.

“Throttling is automatically not applied if the request rate is lower than 100 requests in the past 5 minutes,” states the official documentation. Yet the practical effect is that any automation exceeding this rate will receive 429 errors. The remedy is client-side throttling: token buckets, exponential backoff, and queueing. Admins must consolidate queries, use narrower time ranges (maximum 10 days per query), and stagger extraction windows. Even then, a full daily export of 100,000 rows could take hours instead of minutes.

Query Semantics and Result Changes

Beyond throttling, the V2 cmdlets introduce several behavioral shifts. Quarantine status now shows the latest state, not the original, which means a message released from quarantine will appear as delivered, not quarantined. Recipient casing is preserved as recorded in the message tracking logs, causing potential mismatches in case-sensitive downstream parsing. The removal of -Page means you must implement round-based fetching:

# First round
$results = Get-MessageTraceV2 -StartDate (Get-Date).AddDays(-1) -EndDate (Get-Date) -ResultSize 5000

Subsequent round using last record's Received and RecipientAddress

$last = $results[-1] $nextResults = Get-MessageTraceV2 -StartDate $last.Received -EndDate (Get-Date) -ResultSize 5000 -StartingRecipientAddress $last.RecipientAddress

For messages sent to more than 1,000 recipients, you must use the MessageTraceId (Network Message ID) parameter to avoid partial results. The official documentation warns that omitting it leads to incomplete data, a footgun for compliance reporting.

The Reporting Webservice Gap

One of the most significant disruptions is the retirement of the Reporting Webservice REST endpoint (/reporting.svc/MessageTrace). Many organizations built server-to-server integrations—SIEM connectors, SOC dashboards, custom portals—that relied on this endpoint for near-real-time message trace data. As of GA, Microsoft offers no direct REST replacement. The Exchange Team acknowledged the gap and urged customers to either wrap the V2 PowerShell cmdlets in an internal service or wait for Graph API support.

The Graph API preview, while promising, carries no firm date. “Treat the Graph timeline as provisional,” the forum thread advises. Until Microsoft delivers a production-grade REST endpoint, administrators must either build and maintain a secure PowerShell-to-REST facade or accept a CLI-only operational model. The facade approach introduces its own risks: credential management, additional latency, and a new attack surface.

Community Reaction and Microsoft’s Course Correction

Early adopters praised the new EAC interface, which now loads results faster, persists column widths, and aligns time zones to the admin’s account. The subject filter and delivery status options (including “Quarantined” and “Filtered as spam”) make ad-hoc investigations much smoother. However, the throttling and REST gap drew sharp criticism. One administrator on the Office 365 IT Pros forum called the 100/5-minute limit “a sledgehammer to crack a nut” for tenants that just want to ingest daily logs. Another threatened to move to third-party mail gateway analytics if Microsoft didn’t provide a streaming API.

Microsoft listened, at least partially. The August 25, 2025 update explicitly cited community feedback as the reason for pushing the Reporting Webservice retirement to February 2026. The company also committed to a hint mechanism in cmdlet output that will signal partial results and suggest the next query’s parameters, though it wasn’t available at GA time.

Step-by-Step Migration Checklist

With legacy cmdlets deprecating on September 1, 2025, the clock is ticking. Follow this prioritized plan:

  1. Inventory all automation: List every script, scheduled task, and integration that calls Get-MessageTrace, Get-MessageTraceDetail, or the Reporting Webservice.
  2. Install prerequisite module: Ensure Exchange Online PowerShell V3 ≥ 3.7.0 is deployed in all automation environments.
  3. Convert cmdlets and logic: Replace Get-MessageTrace with Get-MessageTraceV2, swap pagination for round-based retrieval, and add MessageTraceId for large recipient sets.
  4. Implement tenant-aware throttling: Build a clientside counter that resets every 5 minutes. When approaching 100, queue requests or sleep. Respond to HTTP 429 with exponential backoff.
  5. Re-architect large extractions: For daily exports exceeding 100k rows, split jobs by time windows, serialize across tenants, or funnel requests through a centralized service that writes to a data lake.
  6. Address the REST gap: If you currently rely on Reporting Webservice, begin wrapping the V2 cmdlets in an internal REST service now—don’t wait for Graph. Enforce the same rate limits internally to avoid cascading throttles.
  7. Validate data parity: Run V1 and V2 in parallel for a week. Compare outputs for quarantine status, recipient casing, and result ordering. Adjust any compliance or forensic reports accordingly.
  8. Monitor Microsoft updates: Track Message Center entry MC1092458 and the Exchange Team blog for Graph preview announcements or timeline changes.

Practical Script Conversion Example

Old script:

$messages = Get-MessageTrace -StartDate (Get-Date).AddHours(-1) -EndDate (Get-Date) -PageSize 500

New script:

$batch = Get-MessageTraceV2 -StartDate (Get-Date).AddHours(-1) -EndDate (Get-Date) -ResultSize 1000
while ($batch.Count -eq 1000) {
    $last = $batch[-1]
    $next = Get-MessageTraceV2 -StartDate $last.Received -EndDate (Get-Date) -ResultSize 1000 -StartingRecipientAddress $last.RecipientAddress
    if ($next.Count -eq 0) { break }
    $batch = $next
}

Add delay if you’re close to the 100-request window. For very large extractions, consider batching by hours and storing results incrementally.

Long‑Term Outlook

Microsoft’s modernization of message trace is overdue, but the execution leaves mid‑size and large tenants scrambling. The new UI and cmdlets are objectively better for interactive use, and the 5,000‑record -ResultSize reduces round trips in many cases. Yet the throttling model, while necessary for service health, penalizes legitimate automation that previously used the legacy endpoints responsibly.

The eventual Graph API integration could resolve the REST gap, but timelines are soft. In the meantime, administrators should treat the PowerShell V2 cmdlets as the only supported programmatic path and build resilient orchestration around it. Centralize message trace retrieval behind a microservice that caches results, enforces rate limits, and authenticates consumers. This not only meets Microsoft’s limits but also gives you a single point of control and audit.

Organizations operating in GCC, GCC‑High, or DoD clouds will face separate timelines (CY25H2), so plan accordingly if you manage multi‑sovereign environments.

Conclusion

The GA of the new Message Trace in Exchange Online is a classic Microsoft modernization: better tools, stricter guardrails, and a forced migration that tests the agility of IT teams. The 100‑request throttle forces you to rethink high‑volume automation, while the Reporting Webservice sunset highlights the need for a scalable REST interface. By starting your migration now, implementing client‑side throttling, and building an internal API wrapper, you can turn a potential outage into a controlled transition. Subscribe to the Message Center and test early Graph previews as they become available—your message tracing pipeline depends on it.