When Intune deployments fail, the biggest challenge usually isn’t fixing the issue. It’s finding the right log.
Most of us lose hours jumping between devices, portals, and assumptions. The difference between a few-minute fix and a week of confusion often comes down to knowing where to look first and how to interpret what you’re seeing.
This guide is how I approach Intune troubleshooting across Windows, macOS, iOS/iPadOS, Android, and the cloud.
1) Intune’s moving parts (and why logs are scattered)
Intune uses different channels and components depending on the scenario:
- MDM channel for device-level management (profiles, compliance, configuration, app install status).
- MAM channel for app-level protection (App Protection Policies, aka APP), often enforced alongside Conditional Access (CA). On iOS, the Microsoft Authenticator broker is pivotal when CA uses Require approved client app or Require app protection policy. Without a healthy broker, sign-in and policy evaluation can loop or fail.
- Conditional Access in Entra ID gates access based on device/app state. The sign-in logs are authoritative for why access was allowed or blocked (e.g., compliant device required, approved client app required).
Because each piece evaluates different conditions, you’ll often need both device logs and cloud logs to tell the full story.
2) Cloud logs—always my starting point
Before touching any endpoint, I check the cloud.
2.1 Entra ID → Sign-ins (Conditional Access tab)
For access issues, always begin with Entra admin center → Monitoring → Sign-ins for the specific user. Open the failed entry, and the Conditional Access tab shows which policy enforced a Block or failed a grant control (e.g., Require device to be marked as compliant, Require approved client app). This is where you confirm whether the problem is compliance, broker, app type, location, or session controls—and which policy caused it.
Tip: Many “Intune problems” are actually CA evaluations working as configured. Fix the policy or the prerequisite (e.g., enroll the device, use the approved app, ensure broker registration).
2.2 Intune admin center → Troubleshooting + diagnostics
From the Devices and Apps blades, you can see deployment status, profile install status, script outputs, and device compliance. Microsoft’s troubleshooting flow suggests verifying prerequisites, targeting, and sign-in context before diving deeper—a great triage checklist.
2.3 Audit logs
When behavior suddenly changes, I check:
Tenant administration → Audit logs: See who changed what (policies, assignments, roles).
It’s extremely useful when something “worked yesterday.” Audit logs help you correlate the exact admin action and timestamp with the first symptoms.
3) Windows endpoint logs
Windows is the richest platform for local telemetry.
3.1 Event Viewer → DM-WMI Provider & MDM channel
- Event Viewer → Applications and Services Logs → Microsoft → Windows → DeviceManagement-Enterprise-Diagnostics-Provider (DMEDP)
Here you’ll find MDM enrollment, policy processing, OMA-DM sessions, and result codes for profile installs (configuration, compliance) and app policy communications—your first stop for device-side MDM failures.
3.2 Intune Management Extension (IME) logs
For Win32 app deployments and PowerShell scripts deployed via Intune, inspect IME logs on the device. These logs explain detection rules, content download/execution, exit codes, and retry logic, exactly what you need to troubleshoot an “App failed to install” status in the portal.
Technique: Use a CMTrace-style log reader to colorize and filter by timestamp, and jump to [error] lines quickly. Then align with the Intune portal app install status to match failure timestamps.
3.3 Autopilot / ESP logs
When Autopilot hangs during the Enrollment Status Page (ESP), collect Autopilot and provisioning logs from the device. Cross-reference with portal deployment status to find the first failing workload (e.g., a Win32 app stuck in “installing”).
4) macOS logs
macOS offers less than Windows but still enough to diagnose most issues:
- Profiles & MDM payloads: Use Console and system logs during profile installation to see MDM responses and payload errors.
- Company Portal for macOS: Collect diagnostic logs when app installs or compliance states don’t align with Intune.
5) iOS & iPadOS logs (MDM & MAM realities)
Apple’s tight sandboxing means you won’t get Windows-style logs, but you still have options:
5.1 Company Portal / Authenticator diagnostics
For MAM-only or app-based CA scenarios on iOS, Microsoft Authenticator serves as the broker that registers the device/app context for Conditional Access and SSO. If it gets into a bad state, apps can enter a loop (e.g., “Org Data Removal … (607/614)”). The typical remediation is to clear per-app credentials and/or reset the broker (remove and re-add the work account, or reinstall).
These loops are a known iOS MAM phenomenon that Microsoft has documented. The fix is often an on-device credential/broker reset even if the portal shows policies are fine.
5.2 Sysdiagnose / device logs (advanced)
If you need low-level logs (networking, MDM command responses), collect an iOS sysdiagnose while reproducing the issue and filter for MDM, SSO/broker, or specific bundle IDs (e.g., com.microsoft.Outlook). Combine with Sign-ins (CA tab) to confirm whether the failure is policy evaluation (cloud) vs. token/broker (device). Apple doesn’t expose all internals, so Entra sign-in logs remain critical to root-cause access failures.
6) Android logs
Android gives you more app/broker visibility than iOS:
- Company Portal and the managed app often provide exportable diagnostics.
- In Android Enterprise (Work Profile) deployments, the work profile generates telemetry about app installs, compliance checks, and policy application.
The troubleshooting sequence mirrors Microsoft’s guidance: Validate prerequisites, targeting, and app state, then read device/broker logs to decode install or APP enforcement failures.
7) App Protection (MAM) logs and what they really show
App Protection Policies (APP) enforce data protection and access requirements inside the app (PIN, wipe on sign-out, block Save As, cut/copy/paste control). On iOS, remember that the share extension can sometimes appear to bypass restrictions. Intune mitigates this by encrypting “corporate” data so that unmanaged apps can’t read it.
When you see repeated dialogs like:
- “Your organization has removed its data associated with this app (607/614)”
- “Your organization is now protecting its data in this app. Restart to continue.”
It’s typically a sign-in state/broker issue rather than a configuration problem. Clearing app sign-in credentials (Settings → <App> → Reset → Delete Sign-In Credentials) and ensuring Authenticator re-registers the account usually resolves it.
8) Reading logs effectively (techniques that save hours)
- Always anchor on the cloud truth first.
Entra → Sign-ins tells you whether CA blocked the session for compliance, approved client app, MFA, location, or session controls. Don’t guess. Read the CA decision. - Confirm Intune prerequisites & targeting.
Is the user licensed? Is the device/app in scope of the policy? Are you looking at the correct identity (personal vs. work profile)? Microsoft’s recommended investigation flow puts this step up front, and it prevents wild goose chases. - Time-sync your evidence.
Align device timestamps (Event Viewer/IME on Windows, app diagnostics on macOS/iOS/Android) with portal status and the sign-in log. If CA blocked at 10:03:12, look at device/app logs at 10:02–10:04 for token refresh, app startup, or policy evaluation events. - Know when to suspect the broker.
iOS MAM loops, sudden “data removal” after working fine, or an app that signs in but can’t apply APP = check Authenticator health first; remove and re-add the account or reinstall. - Use a consistent naming & grouping strategy.
This isn’t a “log,” but it dictates how easily you can correlate what’s targeted where. Poor structure leads to ambiguous signals in the portal.
9) Real-world troubleshooting playbooks
Scenario A: “iOS MAM loop (614) after weeks of stability”
- Cloud: Check Sign-ins → CA tab for Require approved client app / Require APP decisions. If failure, the session didn’t meet the broker/app requirements.
- Device: In iOS Settings → <Affected Microsoft app> → Reset → Delete Sign-In Credentials, then force-quit and reopen. If it repeats, remove and re-add the Authenticator work account (or reinstall Authenticator).
- Prevent: Keep Authenticator and the Office apps up to date. If a CA policy was newly introduced or modified, verify it aligns with MAM-only expectations (don’t require compliance for BYOD if you intend MAM-only).
Scenario B: “Windows app won’t install via Intune”
- Cloud: In Apps → Monitor → Installation status, find the exact result code and timestamp.
- Device: Open IME logs and filter around that timestamp. Check detection rule evaluation, content download, and process exit codes to pinpoint the failure (wrong detection, content not cached, install switch error).
- Fix: Correct the detection logic or the installer command, reassign, then verify success both locally and in the portal.
Scenario C: “Autopilot stuck at ESP”
- Cloud: In the device’s Enrollment → ESP status, identify which app/profile is blocking.
- Device: Collect provisioning/Autopilot/IME logs. Usually a large Win32 app or dependency chain is failing silently.
- Fix: Convert that workload to post-ESP, split the app, or adjust the detection timeout.
10) Best practices for collecting, storing, and sharing logs
- Standardize a log kit. Document which logs to collect for common issues (Windows IME + DMEDP, macOS Company Portal diagnostics, iOS app credential state + broker steps, Android Company Portal logs, and Entra sign-in evidence of the CA decision).
- Retain evidence. Export device diagnostics and relevant portal CSVs (deployment status) when cases are intermittent.
- Centralize where possible. Use Log Analytics/Azure Monitor or Defender integration to aggregate device signals and correlate with cloud events (especially helpful for large estates).
Takeaways
- Cloud truth first: Entra sign-in logs explain why an authentication/authorization decision was made. Device logs show how the device tried (and maybe failed) to meet it.
- Validate scope and prerequisites before deep dives. Most “mysteries” are mistargeting or missing dependencies.
- On iOS MAM, a broken broker looks like a policy problem but is often a token/state issue. Fix it with a credential/broker reset and re-registration.
Mastering where logs live (and how to correlate them) turns chaotic symptoms into a structured, repeatable investigation and that’s the fastest route to root cause.
