A cloud-based service included in Microsoft 365, delivering scalable messaging and collaboration features with simplified management and automatic updates.
Submit the analysis through a Microsoft 365 administrator support request referencing EX1550543 and MO1550821, because Microsoft Q&A cannot directly forward material to Exchange Online incident engineering or provide a public incident-team contact.
Submit the technical package
- Sign in to the Microsoft 365 admin center with an administrator account.
- Go to Health → Service health.
- Search current issues and Issue history for
EX1550543andMO1550821. Open each record and review All updates for the latest scope, status, mitigation, and any published root-cause information. Issue history retains resolved incidents and advisories for the previous 7 or 30 days. ^1^ - Record whether each incident appears for your tenant and whether your organization experienced matching impact.
- Select Help & support at the bottom-right of the admin center.
- Enter a request such as:
Technical evidence and recovery recommendations related to EX1550543 / MO1550821. Please associate this submission with the incidents and route the attached diagnostic package to the responsible Exchange Online incident engineering team.
- If the suggested results do not address the request, select the Contact Support (headset) icon.
- Choose phone or email, confirm the contact details, and select Contact me. Microsoft documents this as the administrator route to technical support. ^2^
Ask the support engineer to:
- Link the case to both incident identifiers.
- Add the material as engineering evidence rather than a request for end-user troubleshooting.
- Confirm whether the case can be escalated to the Exchange Online incident owner.
- Provide the support-request number and note the requested internal routing in the case record.
Package the evidence for review
Attach a concise document or archive containing:
- Tenant impact, timestamps in UTC, regions, affected clients, and connection methods.
- A clear distinction between observations, hypotheses, and proposed experiments.
- Sanitized KQL and Python files with no tenant IDs, access tokens, mailbox addresses, hostnames, or other sensitive data.
- Time-series evidence correlating handshake rate, session resumption, CPU, queue depth, retries, node-health transitions, and transaction success.
- Canary scope, ramp stages, stability windows, stop conditions, and rollback thresholds.
- A short
READMEexplaining prerequisites, expected output, and whether each query applies to customer-visible telemetry or Microsoft-internal telemetry.
Do not present TLS processing, health-check eviction, load-balancer redistribution, or retry amplification as the established cause unless an official incident update or post-incident report confirms it. The Service health record distinguishes investigation, restoration, service-restored, and post-incident-report states and is the appropriate place to monitor that progression. ^1^
Access and eligibility requirements
- Service Support administrators and Helpdesk administrators can view Service health. ^1^
- Opening the documented business-support request requires an administrator and at least one subscription purchased directly through Microsoft. If every subscription was purchased through a partner, contact that partner and ask it to open and escalate the case. ^2^
- If administrator access is unavailable, contact the organization’s internal help desk or the person who supplied the Microsoft 365 account; Microsoft identifies those contacts as the route to the tenant administrator. ^3^
- Unified/Premier customers can alternatively create the case through Engage Center. ^4^
If an incident is absent from the tenant dashboard but the tenant experienced matching impact, use Health → Service health → Report an issue. Microsoft correlates those reports across organizations and adds an incident or advisory when service-side impact is established. ^1^
References