• Thread Author
Microsoft has moved the revamped Message Trace experience in Exchange Online out of preview and into general availability, bringing a faster UI, new PowerShell cmdlets, extended query windows, and new operational constraints that will change how administrators automate and extract trace data from Exchange Online. The rollout began in mid‑June and was scheduled to complete in July; Microsoft also published a firm deprecation schedule for the legacy UX and cmdlets that requires action from tenants who still run scripts or integrations against the old Message Trace or the Reporting Webservice. (techcommunity.microsoft.com) (learn.microsoft.com)

Two blue-lit monitors show dashboards as glowing cables feed into a neon circular device.Background / Overview​

Microsoft’s Exchange team has replaced the older Message Trace experience with a new Message Trace in the Exchange admin center (EAC) and introduced two next‑generation cmdlets — Get‑MessageTraceV2 and Get‑MessageTraceDetailV2 — intended to deliver better performance, richer filtering, and more reliable long‑range queries. The change is aimed at giving admins more accurate, near‑real‑time traces across a longer window of history, while reducing load on Exchange Online’s telemetry systems. The announcement and technical details were published on the Microsoft Tech Community and in Microsoft Learn documentation for Exchange Online monitoring. (techcommunity.microsoft.com) (learn.microsoft.com)
Key headlines admins need to know at a glance:
  • New Message Trace is now GA and enabled by default in EAC for worldwide (WW) tenants; rollout began mid‑June and completed in July. (techcommunity.microsoft.com)
  • New PowerShell cmdlets (Get‑MessageTraceV2, Get‑MessageTraceDetailV2) require Exchange Online PowerShell V3 module version 3.7.0 or later. (learn.microsoft.com)
  • Throttling: tenant‑level rate limit of 100 query requests per 5‑minute running window applies to the new cmdlets. (learn.microsoft.com)
  • Deprecation: legacy Message Trace UX and the original cmdlets (Get‑MessageTrace, Get‑MessageTraceDetail) begin deprecating September 1, 2025 for WW tenants; Reporting Webservice timelines have been discussed and questioned in the community and Microsoft forums — see “Timeline and verification” below. (techcommunity.microsoft.com) (learn.microsoft.com)

What’s new: features and behavior​

Extended query range and filters​

  • Query window: The new Message Trace supports queries over up to 90 days of historical data for near‑real‑time traces. Initially tenants may see less historical depth (for example an initial 30‑day window), which will grow over time. Each individual query can cover up to 10 days of data per request in the EAC UI and related guidance. (learn.microsoft.com)
  • Subject filtering: New Subject options allow starts with, ends with, and contains searches — including support for special characters — making it easier to find messages by subject text. (learn.microsoft.com)
  • Delivery status filter enhancements: Delivery statuses like Quarantined, Filtered as spam, and Getting status are available as filter criteria. This should reduce manual triage time for quarantined/spam incidents. (learn.microsoft.com)

UI and UX improvements​

  • Customizable columns and persistent column widths let each admin tailor the results view and keep that layout across sessions.
  • Time zone consistency: timestamps will align to the logged‑on admin’s Exchange account time zone to avoid confusion on cross‑region investigations.
  • UI lazy loading ensures users see initial results quickly while more rows load on demand.

Cmdlet improvements (Get‑MessageTraceV2 / Get‑MessageTraceDetailV2)​

  • Module requirement: Exchange Online PowerShell V3, v3.7.0+, is required to use the new cmdlets. Admins must upgrade automation hosts accordingly. (learn.microsoft.com)
  • Result size and pagination: The new cmdlets remove page number/page size pagination; instead they use a -ResultSize parameter with a default of 1000 and a hard maximum of 5000 results per call. Combined with the StartingRecipientAddress and EndDate techniques, scripts can iterate through large datasets reliably. (learn.microsoft.com)
  • Ordering: Results are ordered by Received descending, then RecipientAddress ascending (case‑insensitive), so scripts must use the documented pattern to avoid duplicates or gaps when iterating. (techcommunity.microsoft.com)
  • MessageTraceId for large recipients: For messages sent to more than 1,000 recipients, include MessageTraceId (also known as NetworkMsgId) in queries to ensure complete results. (learn.microsoft.com)

Throttling and tenant limits — what changed and why it matters​

Microsoft introduced a tenant‑level, rate‑based throttling policy for the new Message Trace queries to protect shared resources and preserve system availability. Key facts:
  • Limit: maximum of 100 query requests per tenant per 5‑minute running window. Throttling is not applied if the query rate stays below that threshold. (learn.microsoft.com)
  • Applies to: Get‑MessageTraceV2 and Get‑MessageTraceDetailV2 (and EAC traces that translate into equivalent queries). (learn.microsoft.com)
Why this is important:
  • Many organizations run automated processes that poll message trace data frequently (for compliance, deliverability detection, TLS‑reporting, or SIEM ingestion). A 100‑per‑5‑minute cap means that naive automation that splits a day into many small queries or runs many concurrent queries will quickly hit the tenant quota and receive throttling responses.
  • Large retrievals that previously relied on the Reporting Webservice’s bulk responses may need redesign because the new cmdlets intentionally limit single‑call sizes and overall call frequency.
Operational guidance to avoid throttling:
  • Consolidate queries so that each tenant uses fewer, larger calls (but respect the 5‑day/ResultSize limits).
  • Stagger query schedules across the tenant’s automation accounts.
  • Implement client‑side rate limiting and exponential backoff for transient throttling responses.
  • Use MessageTraceId and StartingRecipientAddress to paginate deterministically and only request the slices needed for processing. (learn.microsoft.com)

Deprecation timeline and verification​

Microsoft’s published timeline (verified)​

  • Microsoft announced general availability and stated that the legacy Message Trace UI and legacy cmdlets (Get‑MessageTrace, Get‑MessageTraceDetail) will begin deprecating on September 1, 2025 for WW customers. This deprecation intent appears in the official Tech Community announcement and is reflected in Microsoft Learn material. Admins should treat September 1, 2025 as the operational cutoff for legacy reliance unless Microsoft publishes further changes. (techcommunity.microsoft.com) (learn.microsoft.com)

Reporting Webservice and public uncertainty​

  • The original GA announcement indicated Reporting Webservice support to pull Message Trace data will also begin deprecating starting on September 1, 2025. Community forums and Microsoft Q&A contain follow‑up discussions where Microsoft staff and moderators recognize that there is no direct REST replacement announced and have recommended migrating integrations to Get‑MessageTraceV2 or to Microsoft Graph where appropriate. (techcommunity.microsoft.com) (learn.microsoft.com)
  • The user‑provided material included an “Update 8/25/2025” that claims Microsoft delayed legacy Reporting Webservice support until February 28, 2026. That specific change could not be located in the public Microsoft Tech Community post or Microsoft Learn pages at the time of verification. Until Microsoft publishes a clear, timestamped update on its official channels, this particular February 28, 2026 extension should be treated as unverified. Admins must confirm the current authoritative timeline in the tenant Message Center or by checking the Exchange Team blog and Microsoft 365 Message Center notices. (techcommunity.microsoft.com) (learn.microsoft.com)
Caveat: Microsoft sometimes updates posts and timelines; always validate the deprecation notice against the authoritative Tech Community post and Microsoft 365 Message Center targeted to each tenant. If an 8/25/2025 update appears in a tenant feed, treat it as authoritative for that tenant — but cross‑check before postponing migration work. (techcommunity.microsoft.com)

Practical migration checklist — what to do and when​

  • Inventory: catalog every script, automation, SIEM feed, or third‑party connector that uses:
  • Get‑MessageTrace / Get‑MessageTraceDetail
  • Reporting Webservice endpoints (/ecp/reportingwebservice/reporting.svc/MessageTrace)
  • Any EAC automation that relies on the old UI behavior
  • Upgrade PowerShell hosts:
  • Ensure automation hosts running Exchange Online PowerShell use Exchange Online PowerShell V3 v3.7.0+. Confirm module installation and that the connection method uses modern authentication (OAuth). (learn.microsoft.com)
  • Replace legacy cmdlets:
  • Rewrite scripts to call Get‑MessageTraceV2 / Get‑MessageTraceDetailV2.
  • Use -ResultSize (default 1000, max 5000), and implement the EndDate + StartingRecipientAddress pattern to iterate through larger result sets without duplication. (learn.microsoft.com)
  • Throttle‑aware automation:
  • Implement client‑side throttling that respects 100 requests per tenant per 5 minutes.
  • For multi‑account automation, coordinate calls across service principals and admin accounts to avoid a single tenant exceeding the rate cap. (learn.microsoft.com)
  • Reporting Webservice consumers:
  • Replace or wrap Reporting Webservice calls by running Get‑MessageTraceV2 from a secure service account and publishing the results internally (for example, to a staging blob storage or SIEM ingest).
  • Consider a connector pattern where the new PowerShell runs at lower frequency, writes batches to storage, and downstream systems ingest without re‑querying Exchange.
  • Test and validate:
  • Run side‑by‑side comparisons (old cmdlets vs. V2) to ensure parity for the queries and that MessageTraceId handling returns the expected full result sets.
  • Validate edge cases: messages with >1000 recipients, quarantined message transitions, messages that change status after initial delivery.
  • Notify stakeholders:
  • Inform helpdesk, security, compliance, and dev teams of the expected change window and the new query patterns and limits.

Recommended scripting patterns and examples​

  • Use MessageTraceId when dealing with messages sent to >1,000 recipients to guarantee completeness.
  • For deterministic batching, use this two‑step pattern:
  • Call Get‑MessageTraceV2 with desired filters and -ResultSize = 5000.
  • Read the last row from the results, then call the next Get‑MessageTraceV2 with -EndDate equal to that last row’s Received timestamp and -StartingRecipientAddress equal to the last row’s RecipientAddress. Repeat until fewer than ResultSize items return.
  • Implement exponential backoff for 429/Throttle responses and log when throttling occurs; include a telemetry metric so teams can track rate usage vs. the 100/5min quota.
Note: Microsoft Learn provides a sample script and recommended best practices for iterating result sets using StartingRecipientAddress and EndDate and documents ResultSize defaults and max values. (learn.microsoft.com)

Risks, limitations, and operational considerations​

  • Throttling impact on large tenants: For tenants that previously relied on frequent, fine‑grained queries (for example, pulling a full day’s message trace frequently for TLS checks or compliance), the new 100 requests/5‑min cap may require redesign. Without careful aggregation, full‑day retrieval could span many minutes or hours, depending on query shape and ResultSize. (learn.microsoft.com)
  • No direct REST replacement announced: Microsoft’s message (and subsequent Q&A confirmations) indicates that no direct REST API replacement for the Reporting Webservice has been published yet; Microsoft recommends invoking the new cmdlets from automation or awaiting Graph API support where appropriate. This leaves API‑centric integrations in a transitional state. Expect to run PowerShell‑based extraction until a documented REST/Graph replacement is available. (learn.microsoft.com)
  • Possible UI/behavior differences: V2 intentionally shows the latest quarantine/delivery status rather than the original status in some cases. This change can affect historical forensic workflows that expect an immutable past snapshot; design your reporting accordingly. (techcommunity.microsoft.com)
  • Sovereign cloud timelines differ: GCC, GCC‑High, DoD and other sovereign environments follow different timelines. The public WW dates do not apply to those clouds; wait for the separate CY25H2 announcements that will target those tenants. (techcommunity.microsoft.com)
  • Community feedback and bugs: Early adopters reported UX quirks (for example, recipient filters needing a wildcard and ordering edge cases). Monitor Microsoft’s Tech Community thread and Product Support channels for fixes and updated guidance as the MEV evolves. (techcommunity.microsoft.com)

The Reporting Webservice question — a closer look​

A frequent question from administrators is whether the legacy Reporting Webservice endpoint (for example /ecp/reportingwebservice/reporting.svc/MessageTrace) will be removed and when. Public Microsoft announcements and Microsoft Q&A responses from Exchange moderators have indicated that the Reporting Webservice is included in the deprecation discussion and that no official REST replacement has been published yet; the immediate guidance has been to adopt the V2 cmdlets or consider Graph API solutions for specific use cases where Graph provides the required data. That community confirmation is important because many SIEM and custom integrations rely on the older web service. (learn.microsoft.com)
If the community or tenant feed shows a specific extended deadline (for example the user content’s claim of a delay to February 28, 2026) — treat that as provisional until the Tech Community or Message Center contains the explicit published update. Always validate the timeline with the Microsoft 365 admin Message Center for the tenant and the Exchange Team blog; do not assume the extension without written confirmation targeted to your tenant. (techcommunity.microsoft.com)

Recommended long‑term posture​

  • Migrate automations to Get‑MessageTraceV2 and introduce resilient harvest patterns that respect the tenant throttling limit.
  • Build a PowerShell extraction service that centralizes Message Trace calls (one authenticated service principal that pushes results to a central store), and then let downstream consumers read from that store. This minimizes tenant query churn and keeps the number of external requests down.
  • Monitor Microsoft Graph and the Exchange Team communications for the planned Graph API public preview that Microsoft mentioned as a future target for Message Trace support; when Graph support is available it will be a better fit for API‑first integrations. Until then, the PowerShell path is the recommended migration route. (techcommunity.microsoft.com)

Final analysis — strengths, risks, and verdict​

The new Message Trace is a long‑overdue upgrade that gives Exchange Online administrators:
  • Stronger query power (subject filtering, extended ranges),
  • Cleaner UX (persistent layout and timezone consistency),
  • Upgraded cmdlets that are more deterministic for automation.
These improvements will speed investigations and reduce the flakiness many admins experienced with older trace pagination and partial results. The introduction of a tenant‑level throttling rule is a defensible engineering decision: it protects Microsoft’s shared telemetry platform and helps maintain consistent performance for all tenants. However, the operational cost of throttling is real: automation and integrations that assume no rate limits will break or slow down without redesign. The lack of an immediate, documented REST replacement for Reporting Webservice also places a short‑term burden on API‑dependent workflows, forcing organizations to adopt PowerShell‑based solutions or engineer custom bridging layers.
Bottom line: adopt the new Message Trace now, rewrite scripts to V2 patterns, implement robust client‑side rate limiting, and centralize Message Trace extraction to avoid hitting tenant quotas. Confirm the Reporting Webservice timeline against Microsoft’s official tenant Message Center; do not rely on second‑hand or unverified timeline claims. (learn.microsoft.com) (learn.microsoft.com)

Closing summary and immediate next steps (quick checklist)​

  • Upgrade automation hosts to Exchange Online PowerShell V3 v3.7.0+. (learn.microsoft.com)
  • Replace Get‑MessageTrace/Get‑MessageTraceDetail with Get‑MessageTraceV2/Get‑MessageTraceDetailV2. (learn.microsoft.com)
  • Implement batching with -ResultSize and the EndDate + StartingRecipientAddress pattern. (learn.microsoft.com)
  • Add tenant‑aware rate limiting to automation: respect 100 requests per 5 minutes. (learn.microsoft.com)
  • Validate whether your tenant’s Message Center contains any timeline updates (especially around Reporting Webservice) before scheduling final cutovers. (techcommunity.microsoft.com)
The new Message Trace materially improves investigative capability and performance in Exchange Online, but it requires careful automation changes and operational discipline to avoid hitting new throttling constraints. Prioritize an inventory and migration plan now — and validate any claimed timeline extensions against Microsoft’s official tenant notices before assuming additional breathing room. (techcommunity.microsoft.com) (learn.microsoft.com)

Source: Microsoft Exchange Team Blog Announcing General Availability (GA) of the New Message Trace in Exchange Online | Microsoft Community Hub
 

The new Message Trace experience for Exchange Online has reached general availability and Microsoft is beginning a global rollout, but the change comes with important operational limits, a firm deprecation timeline for legacy tooling, and migration steps that every Exchange administrator should treat as high priority. The Exchange team rolled the feature out to tenants beginning in mid‑June 2025 and expects the worldwide deployment to complete by late July 2025. Administrators gain a modernized tracing UI in the Exchange admin center, new PowerShell cmdlets (Get‑MessageTraceV2 and Get‑MessageTraceDetailV2), and updated query behavior — but they also face a tenant‑level throttling cap (100 queries per 5‑minute window) and a clear deadline for replacing older cmdlets and Reporting Webservice integrations. (techcommunity.microsoft.com, learn.microsoft.com)

Two blue computer screens display analytics dashboards, with a floating orange GA cube and a 100% badge.Background​

Microsoft made the Public Preview of the redesigned Message Trace available in late 2024 and used feedback from previews to shape the GA release. The new trace is intended to deliver better performance, clearer UI controls, and expanded query parity with message tracking logs. The feature is accessible from Exchange admin center > Mail flow > Message Trace and is enabled by default after deployment. (techcommunity.microsoft.com, learn.microsoft.com)
Administrators who rely on message tracing for troubleshooting, compliance checks, and automated reporting need to understand three things immediately: the new cmdlets and parameters, the tenant‑level throttling behavior, and the deprecation dates for legacy interfaces and APIs. The Microsoft 365 Message Center and the Exchange team blog provide the official timeline and preparation guidance that follow. (mc.merill.net, techcommunity.microsoft.com)

What’s new in the GA Message Trace​

Modern UI and extended query scope​

The new Message Trace UI offers improved filtering, persistent column customizations, timezone alignment to your Exchange account, and a refreshed results experience designed for large datasets. Administrators can query up to 90 days of historical message trace data for near real‑time queries, with a single query limited to a 10‑day window when using PowerShell. These UI and behavior changes are a major step toward parity with message tracking logs and make investigations that span weeks simpler. (techcommunity.microsoft.com, learn.microsoft.com)

New cmdlets and result semantics​

PowerShell users should switch to:
  • Get‑MessageTraceV2
  • Get‑MessageTraceDetailV2
The V2 cmdlets change how pagination and result sets are expressed: there is no page number/page size model; instead a -ResultSize parameter (default 1000, max 5000) controls the number of rows returned per call, and a StartingRecipientAddress pattern helps resume multi‑round queries for messages with many recipients. The V2 cmdlets require Exchange Online PowerShell V3 module version 3.7.0 or later. (learn.microsoft.com)

New filters and query controls​

Key new query capabilities include:
  • Subject filter (supports starts with / ends with / contains)
  • Delivery status filtering with states such as Quarantined, Filtered as spam, and Getting status
  • The ability to use MessageTraceId (NetworkMsgId) for messages sent to >1000 recipients to ensure full results
These controls reduce noisy queries and improve targeted diagnostics when used together with narrow StartDate/EndDate windows and sender/recipient filters. (techcommunity.microsoft.com, learn.microsoft.com)

Throttling: the 100‑requests per 5‑minute rule​

To ensure fair resource use and protect Exchange Online availability, Microsoft enforces a tenant‑level rate cap of 100 query requests per 5‑minute sliding window for both Get‑MessageTraceV2 and Get‑MessageTraceDetailV2. If an automation approach or an operator produces more than 100 requests in any 5‑minute period for a tenant, subsequent requests will be throttled until the running window drops below the threshold. Throttling is not applied when the rate remains under 100 requests per 5 minutes. (learn.microsoft.com)
This cap is applied per tenant (not per user) and is intended to protect shared backend capacity. It affects both interactive and scripted/automated usage. The Learn documentation explicitly calls this out and recommends that automation be adjusted to remain below the limit for predictable behavior. (learn.microsoft.com)

Why the cap matters in practice​

Large organizations or automation frameworks that routinely run repeated trace queries — for example, daily ingestion jobs, compliance exports, or tooling that iterates by user — can exceed 100 requests in five minutes and will need to rework batching logic. Community reports and admins’ reactions indicate that this will require operational changes in many estates, especially those that previously pulled bulk message trace data quickly. (techcommunity.microsoft.com)

Rollout and deprecation timeline — what’s fixed and what’s still soft​

  • General Availability (Worldwide): mid‑June to late‑July 2025 (rollout window to tenants). (techcommunity.microsoft.com, mc.merill.net)
  • Legacy Message Trace UI and legacy cmdlets (Get‑MessageTrace, Get‑MessageTraceDetail) will begin deprecating for worldwide tenants starting September 1, 2025. Administrators should be prepared to migrate before that date. (techcommunity.microsoft.com, mc.merill.net)
  • Microsoft’s Message Center lists August 31, 2025 as the recommended “act by” date for migrating automation and scripts to the new V2 cmdlets — treat that as the practical deadline to avoid interruptions. (mc.merill.net)
Important note on Reporting Webservice: Microsoft’s GA announcement and Message Center indicate that Reporting Webservice support for Message Trace data will begin deprecating on September 1, 2025 for worldwide tenants. There has been community Q&A and requests for clarification about how this affects the /ecp/reportingwebservice/reporting.svc/MessageTrace endpoint; Microsoft has directed users toward the new cmdlets and noted the Graph API as a potential future route, but a direct one‑for‑one REST replacement was not announced in the GA message. If your org consumes message trace via the Reporting Webservice, treat this dependency as requiring migration planning immediately. (techcommunity.microsoft.com, learn.microsoft.com)
Caveat about later timeline edits: some notifications and community posts referenced the Reporting Webservice timeline and potential delays or additional clarifications. Those items were discussed in forums and Q&A threads, but an authoritative Microsoft update extending the Reporting Webservice deprecation to a specific date (for example, February 28, 2026) could not be located in the official GA announcement or Message Center entries at the time of writing; any such date should be treated as unverified until published by Microsoft. Administrators should watch the Exchange team blog and Message Center for formal timeline changes. (techcommunity.microsoft.com, learn.microsoft.com)

What you need to do — a prioritized migration checklist​

  • Inventory your current uses of Message Trace (UI, PowerShell cmdlets, Reporting Webservice, custom APIs). Capture script names, scheduled tasks, and external integrations that call legacy cmdlets or the Reporting Webservice.
  • Start using the new Message Trace UI in EAC for everyday investigations so operators are familiar with the new look and filters before legacy UI retirement. (learn.microsoft.com)
  • Migrate PowerShell automation to the V2 cmdlets by no later than August 31, 2025. Update scripts to use -ResultSize and StartingRecipientAddress patterns, and ensure Exchange Online PowerShell V3 module 3.7.0+ is available in your runbooks. (learn.microsoft.com)
  • Rework any Reporting Webservice integrations to either call the new cmdlets (for on‑prem automation that can host Exchange Online PowerShell) or to use alternate ingestion strategies. If you require an API endpoint, build a controlled adapter that runs the PowerShell queries on schedule and exposes a secure internal API — but treat this as an interim approach until Microsoft documents a supported REST API replacement. (learn.microsoft.com)
  • Throttle your automation: implement client‑side rate limiting and backoff so your tenant never issues more than 100 Message Trace queries in any 5‑minute sliding window. Use batching and coarser time windows where possible. (learn.microsoft.com)

Migration patterns and scripting hints​

  • Use narrow StartDate/EndDate windows and the SenderAddress or RecipientAddress filters to reduce the volume returned per query. This decreases the number of queries required and improves responsiveness. (techcommunity.microsoft.com)
  • For messages sent to >1000 recipients, always use MessageTraceId in your queries to ensure full and consistent results. Pair MessageTraceId with StartingRecipientAddress to retrieve the complete recipient set across rounds. (techcommunity.microsoft.com)
  • When porting scripts, replace pagination logic (Page/PageSize) with a pattern that uses -ResultSize and then iterates using the Received timestamp and StartingRecipientAddress of the final row from the previous call. Microsoft provides sample patterns in the FAQ. (learn.microsoft.com)
Example conceptual flow (pseudocode):
  • Run Get‑MessageTraceV2 with filters and -ResultSize 5000.
  • If returned rows == ResultSize, note last record Received time and last RecipientAddress.
  • Repeat with EndDate set to the last Received and StartingRecipientAddress set to the last RecipientAddress.
    This approach mimics pagination without using page numbers and preserves compatibility with the throttling model. (learn.microsoft.com)

Reporting Webservice and API strategy — current state and caveats​

Microsoft’s GA announcement states that Reporting Webservice support for Message Trace data will begin deprecating, and Microsoft’s guidance currently points customers to the new V2 cmdlets as the supported access mechanism. Microsoft has discussed eventual Graph API onboarding for Message Trace but did not provide a firm public‑GA schedule or a comprehensive Graph surface at the time of the GA note. The absence of a direct REST replacement means organizations with programmatic integrations must design transitional adapters or rehome automation into hosts that can execute Exchange Online PowerShell V3 securely. (techcommunity.microsoft.com, learn.microsoft.com)
Warning: community threads show confusion about whether the Reporting Webservice endpoint will be turned off immediately on September 1, 2025, or phased out over time. Microsoft has used phrasing like “begin deprecating,” which implies a staged approach, but there is no absolute guarantee of extended availability beyond the stated date — plan for migration by the end of August 2025 and treat any later extension as a grace period, not a guarantee. (mc.merill.net, learn.microsoft.com)

Graph API: promises and uncertainty​

Microsoft has indicated intent to bring Message Trace functionality to Microsoft Graph in the future, and the announcement referenced onboarding efforts; however, public documentation and a finalized Graph surface for full message trace scenarios were not available in the GA release. Some Exchange team commentary mentioned a tentative public preview timeline for Graph onboarding (discussed informally in community responses), but a confirmed schedule and API schema should be considered pending until Microsoft publishes a formal preview announcement. Any planning that assumes Graph will replace Reporting Webservice or cmdlets immediately should be held until Microsoft publishes the Graph preview and API contract. (techcommunity.microsoft.com, learn.microsoft.com)

Performance and operational impacts — what to expect​

  • Large exports that previously used frequent sequential queries will see slower end‑to‑end throughput unless reworked to operate within the 100‑per‑5‑minute cap. Expect redesign for streaming or batched ingestion. (learn.microsoft.com)
  • Interactive admin investigations within EAC should be faster and more intuitive, but users accustomed to the old UI must adapt to the new controls and result loading semantics (scroll to load more). (techcommunity.microsoft.com)
  • Security and compliance audits that depended on nightly bulk pulls of message trace data should validate retention and completeness under the new query limits and the V2 cmdlets’ 10‑day per query constraint. Design pipelines to run multiple controlled queries with staggered windows. (learn.microsoft.com)

Security, compliance, and governance considerations​

Switching to V2 cmdlets and the new UI has security benefits: the new tooling is designed for modern authentication, and Microsoft expects admins to run queries under current, auditable tooling stacks. However, replacing the Reporting Webservice with a custom adapter or a PowerShell‑based integration introduces potential security pitfalls if not implemented with least‑privilege, secure credential handling, and proper logging. Ensure runbooks that execute V2 cmdlets:
  • Use managed identities or service principals where supported,
  • Avoid long‑lived credentials stored in plain text,
  • Emit audit events and integrate with SIEM for accountability. (learn.microsoft.com)

Critical analysis — strengths and potential risks​

Strengths​

  • Modernized UX and richer filters make investigations faster and reduce operator friction. The Subject filter, delivery status states, and persistent column settings are meaningful productivity gains. (techcommunity.microsoft.com)
  • Cmdlet parity and improved semantics (MessageTraceId usage, StartingRecipientAddress) address many of the historical limitations when tracing mass recipients. (learn.microsoft.com)
  • Clear migration runway (GA rollout mid‑June → legacy deprecation begins September 1, 2025) gives organizations a measurable window to plan and act. (mc.merill.net)

Risks and tradeoffs​

  • Tenant‑level throttling (100 per 5 minutes) is conservative and will force many orgs to rearchitect bulk data exports or tooling that depends on high query concurrency. For organizations that pull hundreds of trace queries in short bursts, this will be a painful change unless reworked. (learn.microsoft.com)
  • Reporting Webservice deprecation without an immediate REST replacement leaves API consumers in a difficult position; building and maintaining internal adapters is a risky, hands‑on cost that some teams will need to undertake quickly. (learn.microsoft.com)
  • Uncertainties around Graph API timing mean that long‑term API planning should be cautious. Don’t assume Graph will be a drop‑in replacement until Microsoft publishes a preview and API contract. (learn.microsoft.com)
Community posts and forum threads reflect these concerns: administrators praise the UI improvements but caution that the throttling and lack of a published API replacement create operational friction for large tenants and automation-heavy environments.

Recommended tactical plan (30/60/90 days)​

  • 0–30 days: Inventory all usages of Get‑MessageTrace, Get‑MessageTraceDetail, and Reporting Webservice endpoints. Begin porting critical, high‑priority scripts to Get‑MessageTraceV2 and test under the Exchange Online PowerShell V3 module. (learn.microsoft.com)
  • 30–60 days: Rework pipelines to respect the 100/5‑minute tenant cap. Implement client‑side throttling, increase result sizes (up to 5000 where safe), and use MessageTraceId/StartingRecipientAddress patterns to collect full datasets in controlled rounds. (learn.microsoft.com)
  • 60–90 days: Replace Reporting Webservice dependencies with PowerShell adapters or other supported workflows. Validate data fidelity, logging, and error handling across the transition. Prepare contingency and rollback plans in case Microsoft modifies timelines. (mc.merill.net)

Conclusion​

The GA release of the new Message Trace in Exchange Online is a substantive upgrade for administrators: it brings improved UI, modernized cmdlets, and a clearer path toward better alignment with message tracking logs. At the same time, the tenant‑level throttling cap and the deprecation of the legacy Reporting Webservice force immediate operational planning for organizations that rely on bulk exports or programmatic trace access. Administrators should prioritize inventory and migration, adopt the V2 cmdlets and usage patterns, and implement client‑side throttling and batching in their automation. Watch Microsoft’s official channels for any formal changes to Reporting Webservice timelines or for the announced Graph API preview; until those changes are published, treat unconfirmed dates as provisional and plan to complete migrations before the September 1, 2025 deprecation window. (techcommunity.microsoft.com, learn.microsoft.com, mc.merill.net)


Source: Microsoft Exchange Team Blog Announcing General Availability (GA) of the New Message Trace in Exchange Online | Microsoft Community Hub
 

Microsoft has pushed the refreshed Message Trace for Exchange Online out of preview and into general availability for worldwide (WW) tenants, triggering a hard look at automation, reporting integrations, and long-running scripts that rely on the legacy message-tracing stack; admins must plan now to migrate to the new cmdlets, adapt to new throttling behavior, and rethink how they ingest trace data programmatically. (techcommunity.microsoft.com) (mc.merill.net)

An office desk with a computer monitor and a shield icon, conveying cybersecurity.Background​

Microsoft announced the General Availability (GA) of the new Message Trace experience in the Exchange admin center (EAC) on June 3, 2025 and published a series of clarifications and timeline changes as the rollout progressed. The GA rollout began in mid‑June and was expected to complete by late July 2025 for WW tenants. The Exchange team updated the GA post on August 25, 2025 to adjust the timeline for legacy Reporting Webservice support and to add a tentative Graph API preview plan. (techcommunity.microsoft.com)
Why this matters: Message trace is a primary operational tool for Exchange administrators — it’s used to investigate delivery, quarantine, spam filtering, and TLS/transport issues. Any change to the UI, cmdlets, or APIs that feed automation and SIEM/monitoring tooling can break workflows and compliance reporting if not handled ahead of deadlines. Microsoft has provided explicit migration dates to give organizations time to adapt. (mc.merill.net)

What’s new in the Message Trace V2 experience​

Core capabilities and UX improvements​

  • The new Message Trace is now the default in EAC > Mail flow > Message Trace after the GA rollout. The web UI was rebuilt with improved performance, persistent column widths, time‑zone alignment to the admin’s Exchange account, and more granular filtering (for example, subject matching and delivery status options such as Quarantined or Filtered as spam). (learn.microsoft.com)
  • Historical range: tenants will gain access to up to 90 days of historical message data for near‑real‑time queries over time, but each PowerShell query can only request up to 10 days per call (you must page across time ranges to cover a longer span). The EAC supports scrolling to load additional results automatically. (learn.microsoft.com)

Cmdlet changes (V2)​

  • New PowerShell cmdlets:
  • Get-MessageTraceV2
  • Get-MessageTraceDetailV2
These require Exchange Online PowerShell V3 module version 3.7.0 or later. The V2 cmdlets replace the older Get-MessageTrace and Get-MessageTraceDetail cmdlets and include new semantics such as -ResultSize (default 1000, maximum 5000) and removal of classic pagination parameters. (learn.microsoft.com)
  • Pagination is replaced by a round‑based retrieval model: use -ResultSize, the Received timestamp of the last record, and -StartingRecipientAddress to get subsequent rounds of results without duplication. For high‑recipient messages (>1,000 recipients) use MessageTraceId to avoid partial results. (learn.microsoft.com)

Query and result behavior differences​

  • Recipient case and ordering semantics changed (V2 preserves case from Message Tracking Logs).
  • Quarantine displays latest status (V2), not original status (V1) — this affects how you interpret traces for messages that were later released.
  • ResultSize makes bulk extraction more efficient, but you must handle time ties and the starting recipient logic to avoid missed/duplicate rows. (techcommunity.microsoft.com)

Hard technical limits: throttling and per‑query rules​

Microsoft put a tenant‑level throttling rule in place for V2 cmdlets: a maximum of 100 query requests per tenant per 5‑minute running window. Throttling is rate‑based and not applied if your request rate stays below the threshold. This limit applies to both Get-MessageTraceV2 and Get-MessageTraceDetailV2. (learn.microsoft.com)
Other important per‑query rules:
  • You can only query 10 days of data per query (even though the tenant may have up to 90 days retained for near‑real‑time queries).
  • -ResultSize default is 1000, maximum 5000.
  • Use MessageTraceId for messages with >1,000 recipients.
  • The new cmdlets are available only with Exchange Online PowerShell V3 (>=3.7.0). (learn.microsoft.com)

Deprecation timeline — exact dates you must track​

Microsoft published clear milestone dates for the WW environment:
  • GA rollout: mid‑June to late July 2025 (completed during that window). (mc.merill.net)
  • Legacy Message Trace UX and legacy cmdlets (Get-MessageTrace, Get-MessageTraceDetail) will begin deprecating on September 1, 2025. Migrate automation and scripts by August 31, 2025. (mc.merill.net)
  • Reporting Webservice: Microsoft delayed the removal of legacy Message Trace support on the Reporting Webservice in response to feedback — legacy Reporting Webservice support was delayed to February 28, 2026, with deprecation actions starting March 2026; in practice Microsoft instructs teams to migrate off Reporting Webservice before February 2026. The Exchange Team made this timeline update on August 25, 2025. This applies to WW tenants only; GCC/GCC‑High/DoD/sov clouds will have separate schedules. (techcommunity.microsoft.com)
Caveat: the Reporting Webservice deprecation and the Graph API onboarding are evolving; Microsoft lists a tentative public preview for Message Trace support in Microsoft Graph in November (tentative), and has said more details will be shared closer to release. Treat the Graph timeline as provisional. (techcommunity.microsoft.com, learn.microsoft.com)

Why the change is disruptive (and why Microsoft made it)​

  • The legacy Reporting Webservice (the REST endpoint many integrations used) is being retired with no one‑to‑one, ready‑to‑plug REST replacement announced; Microsoft is steering programmatic customers toward the new PowerShell V2 cmdlets and eventually Graph API support. That creates a gap for customers who need a server‑to‑server REST API. Microsoft has acknowledged the gap and indicated Graph API support is forthcoming (public preview tentative). (learn.microsoft.com, techcommunity.microsoft.com)
  • The new rate‑based throttling (100 queries/5 minutes) can severely slow bulk extraction for large tenants that relied on high‑throughput pulls from the old endpoints. Community reports and early feedback show administrators pulling daily activity snapshots (hundreds of thousands of rows) could see job times increase dramatically if scripts are not reworked. Expect to refactor extraction strategies to respect the rate limits. (techcommunity.microsoft.com, office365itpros.com)
  • V2 changes to result semantics (ordering, quarantine status, recipient casing) mean that automated parsing and interpretation logic may produce different outcomes unless updated. This is particularly relevant for compliance scripts, TLS reporting, and forensic tooling. (techcommunity.microsoft.com)

Practical migration guidance — a step‑by‑step checklist​

The deprecation dates are real and tight. Use this step list to prepare and migrate with minimal disruption.
  • Inventory & prioritize (ASAP)
  • Catalog all scripts, scheduled jobs, and integrations that call Get-MessageTrace, Get-MessageTraceDetail, or the Reporting Webservice /reporting.svc/MessageTrace.
  • Identify usage patterns: daily extracts, per‑user traces, high‑frequency support queries, SIEM ingestion, and troubleshooting automation.
  • Verify environment and prerequisites
  • Confirm Exchange Online PowerShell V3 is installed and version 3.7.0 or later is available where your automation runs.
  • Validate credentials and RBAC permissions: users must have the same permissions to run V2 cmdlets as before, but check role assignments for any differences. (learn.microsoft.com)
  • Replace legacy cmdlet calls with V2 equivalents
  • Convert Get-MessageTrace -> Get-MessageTraceV2
  • Convert Get-MessageTraceDetail -> Get-MessageTraceDetailV2
  • Replace pagination logic with the round‑based retrieval pattern:
  • Use -ResultSize to control chunk size (start with default 1000).
  • On each round, take the Received timestamp of the last record and RecipientAddress as -EndDate and -StartingRecipientAddress for the next call. (learn.microsoft.com)
  • Respect throttling
  • Ensure tenant automation uses no more than 100 query requests per 5 minutes across the tenant (this is a tenant‑wide limit). Throttle clientside: implement token buckets, sleeps, or exponential backoff when you get 429s.
  • Consolidate queries where possible (use filters to narrow searches) rather than running many small queries in parallel. (learn.microsoft.com)
  • Rework large extractions
  • For very large data pulls (e.g., daily exports with >100k rows), move to a time‑windowed extraction strategy and stagger runs across tenants/regions to avoid hitting the 100/5min limit.
  • Consider queuing jobs on a centralized service that serializes message‑trace queries and writes output to an internal data lake for downstream consumers.
  • Replace Reporting Webservice dependencies
  • For integrations still using Reporting Webservice, plan to move off it by February 28, 2026 (per Microsoft’s Aug 25, 2025 update). If you need an API rather than PowerShell, evaluate interim options:
  • Wrap V2 cmdlets in a secure service (internal REST facade) that enforces throttling and authentication rules.
  • Monitor Microsoft Graph announcements — Graph support for Message Trace is planned (public preview tentative in November) but not guaranteed on a specific date; do not rely exclusively on it until Microsoft confirms GA. (techcommunity.microsoft.com, learn.microsoft.com)
  • Test and validate
  • Run parallel output from legacy and V2 cmdlets for a representative set of queries and compare results.
  • Validate for special cases: messages with >1,000 recipients, multirecipient batching, quarantine -> released messages, and timezone handling.
  • Deploy with observability
  • Add metrics and logging around query counts, 429/503 responses, time per query, and row counts.
  • Create alerting on threshold breaches so the team can act before tenant‑wide throttling is hit.
  • Communicate internally
  • Notify support teams, on‑call engineers, and any third‑party vendors that depend on message trace data of the migration schedule and throttling behavior.

Example extraction pattern (conceptual)​

  • Use Get-MessageTraceV2 with a narrow time window (<=10 days) and -ResultSize (e.g., 5000).
  • If result count equals -ResultSize, assume there may be more; use the Received/RecipientAddress of the last item for the next round. Repeat until you cross the full span.
  • Rate‑limit your orchestration to keep per‑tenant requests under 100 per 5 minutes (including all automation runs in the tenant).
Note: Microsoft is working on a hint mechanism in cmdlet output to indicate partial results and next‑query guidance, but older cmdlets will not return this; test for current behavior in your tenant. (learn.microsoft.com)

Reporting Webservice and API landscape — what to do if you need a REST endpoint​

  • Microsoft’s official direction: use the new PowerShell cmdlets (V2) or wait for Graph API support targeted for preview (tentative). No fully equivalent REST endpoint replacement was published as of the Aug 25, 2025 update. If your integration requires REST, you have three practical choices:
  • Build an internal REST wrapper that calls the V2 cmdlets under controlled credentials and enforces the new throttling rules.
  • Keep a reduced/optimized extraction schedule that runs fewer, larger queries and writes to an internal store your applications can consume.
  • Evaluate vendor or partner tooling that provides intermediary log ingestion if your SLAs demand near‑real‑time REST access (costly and requires careful security controls). (learn.microsoft.com, techcommunity.microsoft.com)
Important: Microsoft’s Q&A and forum moderators have explicitly warned that no direct REST replacement has been announced and that teams should proactively design contingency plans. Expect Graph API eventual support, but do not assume it will meet any strict SLA until Microsoft confirms GA. (learn.microsoft.com)

Strengths, weaknesses, and risk analysis​

Strengths​

  • Improved UI and performance for ad‑hoc investigations, with modern filtering and a better UX for admins performing interactive troubleshooting. (learn.microsoft.com)
  • Larger single‑query result sizes (up to 5000) reduce round trips for many scenarios and simplify retrieval logic for moderate workloads. (learn.microsoft.com)
  • Cleaner data semantics (message‑tracking alignment) — V2 aligns more closely with the Message Tracking Logs, reducing ambiguity between sources. (techcommunity.microsoft.com)

Weaknesses and risks​

  • Throttling is conservative and tenant‑wide. The 100 requests / 5 minutes cap is low for large enterprises that rely on frequent, automated queries. Without re‑engineering, a tenant that previously ran many parallel diagnostics jobs could experience long delays or throttling errors. (learn.microsoft.com, office365itpros.com)
  • No direct REST replacement at GA. Many existing integrations used the Reporting Webservice REST interface. While Reporting Webservice support was delayed to February 28, 2026, the lack of an immediate REST alternative forces organizations to create internal wrappers or rework architecture. This is a material integration risk for SIEM/SOC systems that expect streaming or REST ingestion. (techcommunity.microsoft.com, learn.microsoft.com)
  • Behavioral differences may alter historical reporting. Differences in status reporting (e.g., quarantine latest status) and recipient normalization require validation of any compliance or forensic reports built from V1 outputs. (techcommunity.microsoft.com)
  • Sovereign cloud divergence. GCC, GCC‑High, DoD, and other sovereign clouds will receive separate timelines (CY25H2), so organizations operating across environments must handle multi‑timeline migrations. (techcommunity.microsoft.com)

Community reaction and real‑world reports​

Discussion threads and early adopters highlight two recurrent themes: (1) immediate praise for the interface and the larger result sizes, and (2) strong concern about throttling and the loss of a public REST endpoint. Admins running large daily pulls for TLS/non‑TLS reporting and SIEM feeds called the 100/5min threshold restrictive and urged Microsoft for streaming APIs or a higher limit for verified scenarios. Community reaction was significant enough to trigger Microsoft’s update to the Reporting Webservice timeline in August 2025. (office365itpros.com, techcommunity.microsoft.com)
(WindowsForum community archives and threads have been tracking these reactions closely; internal forum snapshots show the same debate lines between convenience, performance, and tenant protection. )

Practical examples of changes you must make to scripts​

  • Replace old pagination logic like:
  • Get-MessageTrace -Page 1 -PageSize 500
  • With the V2 pattern using -ResultSize and progressive -EndDate + -StartingRecipientAddress. Use the MessageTraceId for very large recipient messages to guarantee completeness. Test for partial results and duplicates and add deduplication logic on recipient+networkmsgid if necessary. (learn.microsoft.com)
  • Add clientside throttling:
  • Implement a tenant‑aware request counter (resetting every 5 minutes) and failover queuing if the counter is at 100.
  • Implement exponential backoff for 429 responses, and alert if backoff is occurring frequently (indicates you need to rearchitect). (learn.microsoft.com)

Short‑term (next 30–90 days) action plan — prioritized​

  • Immediately inventory message‑trace users and automation. Tag items by business impact.
  • Install/validate Exchange Online PowerShell V3 (≥3.7.0) in each automation environment.
  • Begin converting your most critical scripts to V2 and run V1+V2 in parallel to validate results.
  • Implement tenant‑aware throttling and queueing in your orchestration layer.
  • Schedule large daily exports to run at off‑peak times and spread across multiple windows.
  • If you depend on Reporting Webservice REST, plan to replace it by February 28, 2026 — but do not delay migration because Graph timelines are tentative.
  • Subscribe to the Microsoft 365 Message Center entry (MC1092458) and the Exchange Team TechCommunity post for live updates. (mc.merill.net, techcommunity.microsoft.com)

Long‑term considerations​

  • Monitor Microsoft Graph API announcements: Graph support for Message Trace is planned, and when available it will be the preferable long‑term API for many integrations. However, Graph capabilities and throttling models may differ — treat Graph as a future target, not a guaranteed immediate replacement. (techcommunity.microsoft.com)
  • If your organization needs high‑throughput, streaming, or certified REST APIs for compliance, push Microsoft through official channels (support or tenant contacts) to request quota increases, early access programs, or alternative APIs for enterprise telemetry ingestion.
  • Where possible centralize message‑trace requests behind an internal microservice that:
  • Enforces tenant‑level throttling and retry logic.
  • Caches recently requested results for short windows to reduce repeated queries from multiple teams.
  • Authenticates and logs access for audit.

Final assessment​

The new Message Trace in Exchange Online is an explicit modernization: better UI, larger result chunks, and alignment with message tracking logs make interactive troubleshooting and many scripts easier to write and understand. That said, the combination of a tenant‑wide 100/5‑minute throttling limit and the lack of a ready REST replacement at GA creates a genuine operational risk for large tenants and programmatic integrations.
The good news: Microsoft recognized the disruption and adjusted the Reporting Webservice timeline (delaying retirement until February 28, 2026) and committed to Graph API support (tentative preview). But the only guaranteed programmatic interface available today is PowerShell V2, so organizations must act now to migrate and to architect around the new throttling model. Treat the Graph API plan as promising but provisional; do not delay remediation planning on the assumption it will solve your immediate integration needs. (techcommunity.microsoft.com, learn.microsoft.com)

Quick checklist (copy/paste)​

  • Inventory scripts using Get-MessageTrace, Get-MessageTraceDetail, or Reporting Webservice (today).
  • Verify Exchange Online PowerShell V3 ≥ 3.7.0 in automation hosts.
  • Migrate scripts to Get-MessageTraceV2 / Get-MessageTraceDetailV2 and adopt -ResultSize + round logic.
  • Implement tenant‑aware client throttling to keep ≤100 queries per 5 minutes.
  • For large extractions, time‑window the jobs and centralize orchestration.
  • Replace or wrap Reporting Webservice integrations before Feb 28, 2026.
  • Monitor Exchange Tech Community and Message Center for updates and Graph API previews. (mc.merill.net, techcommunity.microsoft.com)

The technical controls Microsoft added protect service reliability and prevent abuse, but they also shift implementation complexity onto tenant automation. Prioritize conversion of your critical traces, add defensive throttling and queuing, and validate outputs carefully during the final months before legacy retirements. Community feedback has already influenced Microsoft’s timeline; continued engagement with the Exchange team and early testing of Graph previews (when available) will help smooth the transition. (learn.microsoft.com, office365itpros.com)

Source: Microsoft Exchange Team Blog Announcing General Availability (GA) of the New Message Trace in Exchange Online | Microsoft Community Hub
 

Back
Top