Analyzing Microsoft 365 logs to find root causes

Start by turning the symptom into a narrow search: what failed, who was affected, and when. To find and fix a Microsoft 365 problem from logs, capture the exact symptom and timestamp, pick the log source that records that symptom, filter by user/time/error code, correlate events across services, then act on the evidence. Below are where each log lives, how to access it, practical queries (KQL and PowerShell), how to interpret entries into actions or escalations, and a short troubleshooting workflow you can follow immediately.

Prerequisites

• Admin account(s) with the appropriate role(s) for the logs you need.
• Tenant ID and the user UPN or object IDs involved in the incident.
• Time range or at least an approximate timestamp (include timezone).
• Tools: browser to access the admin portals, PowerShell modules (ExchangeOnline, AzureAD/MSGraph) or Graph API client if you automate, and a text editor to collect IDs and raw log snippets.
• Least-privilege roles that allow read access: Security Reader, Compliance Administrator, Exchange Administrator, Reports Reader, or Global Admin depending on the log.

What specific symptom should I look for first

Begin with one clear observable symptom in a single sentence. That determines which log you open first.

• User-facing symptom examples to note before opening logs:
• Mail delivery failure: include message ID, sender, recipient, and delivery time.
• User can't sign in: include username, exact error text, device ID/OS, and timestamp.
• Teams call failure or poor media: include meeting ID, participant list, and approximate start time.
• SharePoint file access error: include file path, operation (read/write), and timestamp.

Record these key fields before you dig into logs:

• User principal name (UPN) or object ID.
• Exact timestamp (include timezone) or narrow range.
• Tenant ID (if you manage multiple tenants).
• Device identifier or client IP if available.
• Exact error text or code string.

If you only have a rough time, start with a 30–60 minute window centered on the reported event and tighten once you see hits.

Where to find the right Microsoft 365 logs right now

Pick the log closest to the symptom. Each service records different facts; use the paths below to get the right data quickly.

• Azure AD sign-ins (authentication, conditional access): use the Azure portal or Graph API.

1. Open Azure Active Directory > Monitoring > Sign-ins.
2. Example Graph query (requires appropriate app permissions):

Connect-AzureAD
# Graph REST example (use your toolchain) GET https://graph.microsoft.com/v1.0/auditLogs/signIns

• Microsoft 365 Audit log (cross-service user and admin actions): use Microsoft Purview compliance portal or the unified audit logs via Graph.

1. Compliance portal > Audit > Search.
2. PowerShell example to start audit retrieval:

Connect-ExchangeOnline
Search-UnifiedAuditLog -StartDate 01/01/2025 -EndDate 01/02/2025 -RecordType MailboxLogin

• Exchange Online message trace (mail flow, delivery status): use Exchange Admin Center (Mail flow > Message trace) or the Get-MessageTrace cmdlets.

1. EAC > Mail flow > Message trace.
2. PowerShell example:

Connect-ExchangeOnline
Get-MessageTrace -SenderAddress [email protected] -StartDate 2025-01-01 -EndDate 2025-01-02

• Teams diagnostics and call analytics (meetings, PSTN): use Microsoft Teams admin center > Analytics & reports > Call quality dashboard, or the Teams troubleshooting pane for a user.

1. Teams admin center > Users > select user > Troubleshooting.

• SharePoint and OneDrive activity: use the Microsoft 365 compliance audit log or SharePoint admin center > Site usage and health; for file-level events, use the unified audit log.

1. Compliance portal > Audit > Search and filter by SharePointFileOperation.

• Service health and outages: use Microsoft 365 admin center > Health > Service health.

A practical habit: note which portal and the exact click path that produced useful entries so you can repeat queries quickly.

How to narrow and search logs to isolate the incident

Narrow by time, user, device/IP, and error code. Use iterative narrowing: start broad and tighten filters as you find identifiers.

1. Start with a time window that definitely includes the failure.

Start time: 2025-01-15T10:30:00Z
End time:   2025-01-15T11:30:00Z

2. Filter by user or message ID.

Get-MessageTrace -SenderAddress [email protected] -StartDate 2025-01-15 -EndDate 2025-01-16

3. Use KQL in the compliance or Azure portals to filter logs. Example: find failed sign-ins for a user with an MFA failure.

SigninLogs
| where TimeGenerated between(datetime(2025-01-15T10:00:00Z) .. datetime(2025-01-15T11:00:00Z))
| where UserPrincipalName == "[email protected]"
| where ResultType != 0
| project TimeGenerated, UserPrincipalName, ResultDescription, ConditionalAccessStatus, ClientAppUsed, IPAddress

4. Correlate events across services. Example scenario: failed MFA leads to mail access problems.

4.1 Find Azure AD sign-in failure with conditional access block.

SigninLogs
| where TimeGenerated between(datetime(2025-01-15T10:30:00Z) .. datetime(2025-01-15T10:45:00Z))
| where UserPrincipalName == "[email protected]"
| where ConditionalAccessStatus == "failure" or ResultDescription contains "multifactor"

4.2 Find Exchange access attempts from the same IP or client around the same time.

OfficeActivity
| where TimeGenerated between(datetime(2025-01-15T10:25:00Z) .. datetime(2025-01-15T10:50:00Z))
| where UserId == "[email protected]"
| where Operation == "UserLoggedIn" or Operation contains "Send" or Operation contains "Mail"
| project TimeGenerated, Operation, ClientIP, UserId, Detail

5. Map message trace results to authentication events. If message trace shows client submission failure, check sign-in logs for the same IP and user agent at that time.
6. Search for correlated alerts across logs: conditional access logs, Exchange reject codes, and audit events. Look for repeating IPs, matching device IDs, or identical error codes across services.
7. If searches return too many events, add filters like ClientAppUsed, DeviceDetail.osPlatform, or ResultType. Iterate until you have a small set of suspicious events to interpret.

How to read common log entries and decide the next action

Translate key fields to actions. Below are common log snippets and the typical next steps.

• Azure AD sign-in: ResultType/ResultDescription and ConditionalAccessStatus
• If ResultType shows an MFA error or ResultDescription contains "A requirement for multi-factor authentication was not satisfied": action: verify the user's MFA registration, check conditional access policies, and guide the user to re-register MFA. Escalate to the identity team if the policy looks misconfigured and affects many users.
• If ConditionalAccessStatus == "failure" and the reason is "Device not compliant": action: check Intune compliance policies and device state; ask the user to sync or enroll their device. Escalate if many corporate devices show the same failure.
• Exchange message trace: Status and EventSummary
• If trace shows "Failed" with a 5xx SMTP code from Exchange Online Protection: action: inspect SPF/DKIM/DMARC and sending IP reputation; check transport rules. Escalate to Microsoft support for backend service errors or tenant-level blocks.
• If trace shows "Delayed" or "Transient": action: retry or monitor; transient issues often clear. Collect message ID and timestamps; escalate if the delay persists beyond normal retry windows.
• Teams call logs: media stats and QoE metrics
• If packet loss, jitter, or RTT values are high for a client: action: check client network (Wi‑Fi vs wired), firewall port rules, and proxy. Ask the user to test on a different network. Escalate to the network team if multiple users in the same subnet are affected.
• SharePoint/OneDrive audit entries: Operation and ObjectId
• If an access denied appears for a file and the user should have access: action: check site permissions, group memberships, and sharing links; check conditional access policies. Escalate to SharePoint admin if permissions appear correct but access is still denied.

Mapping log text to fixes — short examples:

• Log: "A requirement for multi-factor authentication was not satisfied" → Fix: guide user through MFA prompt or reset phone app. Escalate: if MFA prompts are not reaching multiple users, file a support ticket.
• Log: "550 5.7.1 Access denied" in message trace → Fix: check anti-spam policy or transport rule and sender authentication. Escalate: if message is blocked by Microsoft-managed spam filters with tenant-wide impact.
• Log: "Device not compliant" in sign-ins → Fix: trigger Intune device sync or update compliance policy assignment. Escalate: if compliance policy recently changed and many devices fail.

Escalation triggers to watch for: multiple users showing identical errors within the same 15–60 minute window; service health indicates a tenant-impacting incident; inability to authenticate despite correct configuration and successful reproductions.

What to watch out for and common traps to avoid

Common mistakes that waste time:

• Local client timestamps: client logs often use the device's local clock. Convert reported times to UTC or confirm timezone alignment before correlating logs.
• Overlooking service-wide incidents: check the Microsoft 365 Service health before heavy investigation. A tenant-wide outage can produce consistent failures that aren't caused by tenant configuration.
• Misreading generic error messages: many front-end errors are placeholders. Look for correlated backend error codes in the same time window.
• Making live changes without capturing raw logs: collect sign-in IDs, message trace IDs, and raw audit records before changing policies. That record lets you confirm whether a change fixed the exact problem or merely changed symptoms.
• Ignoring client-side problems: network, local cache, or outdated client versions can cause failures that look like server problems.

don't disable security controls (MFA, conditional access) as a quick test in production. Use targeted test accounts or controlled policy exclusions.

Capture reproducible steps and keep a log of the actions you take so you can roll back if necessary. When you escalate, include exact log extracts, timestamps, and reproduction steps.

Troubleshooting workflow: reproduce, capture, correlate, remediate, and verify

Follow these steps in order when you start an incident.

1. Reproduce the issue or get a clear report: collect exact error text, UPN, message ID, device ID, and timestamp.
2. Capture raw evidence: collect sign-in IDs, message trace IDs, audit record IDs, and raw log exports.
3. Search the closest log source using the identifiers and time range you captured.
4. Correlate events across services: match IPs, device IDs, and timestamps in Azure AD, Exchange, Teams, and Audit logs.
5. Apply the least-impact remediation that addresses the logged cause (for example: reset MFA registration for a single user, trigger device sync, correct a transport rule).

avoid tenant-wide policy changes as a first-step test.

6. Verify the remediation by reproducing the original symptom and checking the same log IDs for successful events.
7. If the fix didn't work or the logs show backend errors you can't remediate, escalate with the collected evidence and reproduction steps.

Expected result: after step 6 you should see a successful sign-in, message delivered, or file access allowed for the same identifiers and within the same time window used earlier.

Completion criteria

You know the incident is resolved when:

• The original symptom can be reproduced and now succeeds, and
• The same log IDs (sign-in ID, message ID, audit record) show a successful result, and
• Any remediation changes are limited in scope and documented, and
• If you escalated, the ticket includes raw log snippets, timestamps, and reproduction steps.

Conclusion

Define the symptom, pick the closest log, narrow by time/user/error, correlate across services, then act on the evidence. Start with non-destructive checks (service health, sign-in logs, message traces), collect identifying IDs before you change configuration, and only escalate with log snippets and reproduction steps when the issue is outside your control.

Frequently Asked Questions

How long do Microsoft 365 logs retain data?

Retention varies by log type and your tenant settings. Azure AD sign-ins and some audit logs have default retention limits; compliance audit log retention depends on your licensing and retention policies. Check the specific service settings in the admin portals for exact retention in your tenant.

Can I search logs programmatically for multiple tenants?

Yes, with appropriate app credentials and permissions for each tenant. Use Microsoft Graph or PowerShell modules with delegated or application permissions; build automation to handle rate limits and secure credential storage.

What minimum permissions do I need to access these logs?

You typically need one of the admin roles: Global Admin, Security Reader/Administrator, Compliance Administrator, Exchange Administrator, or Reports Reader depending on the log. Apply least-privilege principles and assign the narrowest role that provides read access.