Intune diagnostic logs come from a remote action that looks like one click and is actually a round trip. The request has to reach the device. The device has to run the collectors, then upload a zip to a regional storage address the network must allow. Any leg can fail without an error that names it, and when the zip does arrive it contains a fixed list that may not include the log you needed.
This post covers where each leg breaks, what the collection contains and what it leaves out, and when to skip the remote action and collect by hand. It is one step in the order set out in Intune device not syncing, and usually not the first. Every Microsoft fact below was checked against Microsoft Learn on 26 September 2026.
What Collect diagnostics actually does
The Collect diagnostics device action runs from Devices > All devices, then the device, then Collect diagnostics in the action row. A pending notification appears on the device’s Overview page, and the status is under Monitor > Device diagnostics on that device. When it completes, the zip downloads from the same row.
| Fact | As documented |
|---|---|
| Windows scope | Corporate-owned Windows, and Windows Holographic. Mobile platforms only through app protection |
| Minimum version | Windows 10, version 1909 and later, or Windows 11 |
| Default state | Enabled by default. Tenant switch at Tenant administration > Device diagnostics |
| Permission | Remote tasks/Collect diagnostics, or the Help Desk Operator or School Administrator roles |
| Retention | Stored for 28 days, up to 10 collections per device |
| Bulk | Up to 25 Windows devices at a time |
| Autopilot | Automatic capture on Autopilot failure, enabled by default, one set of logs per device per day |
Two lines in the documentation are easy to miss and matter more than the rest. Only non-user locations and file types are accessed, so nothing from the user’s profile is collected. And Microsoft notes that its own personnel might access device diagnostics while troubleshooting incidents, which is worth knowing before you collect from a device that holds anything sensitive.
Why Intune diagnostic logs never arrive
Microsoft documents two main known issues. First, a time-out can occur on devices without KB4601315 or KB4601319, which fix the DiagnosticLog configuration service provider so it does not time out during upload, and the device must be rebooted after the update. Second, the device wasn’t able to receive the device action within a 24-hour window, which happens when it is offline or turned off.
The network requirement is the one that catches locked-down estates. The documentation says to make sure the URL for your region isn’t blocked, and lists regional blob storage addresses ending in lmsas.blob.core.windows.net. It also says the device must be online and able to communicate with the service during the whole collection. A proxy that allows Intune enrolment and check-in but not that storage endpoint produces a collection that starts and never finishes.
If the device is not receiving device actions at all, collecting diagnostics is the wrong first step, because the request travels the same path as every other action. Start with forcing an Intune sync, and come back once the device is checking in.
The failure modes
These are the ways a request for Intune diagnostic logs goes wrong, in the order I would check them.
| What you see | What is happening | What to do |
|---|---|---|
| Action greyed out or missing | The tenant switch is disabled, the device is personally owned, or your role lacks the permission | Check Tenant administration > Device diagnostics, ownership and role |
| Pending for more than a day, then failed | The device did not receive the action within 24 hours | Confirm the device is online and checking in first |
| Starts, then times out | Missing the DiagnosticLog CSP fix, or the regional storage URL is blocked | Check the update and reboot, then test the storage endpoint from the device network |
| Zip downloaded but the log you need is absent | The collection is a fixed list. User profile locations are never collected | Collect that log by hand |
| An older collection has disappeared | Collections are kept for 28 days, and 10 per device at most | Download what you need before starting a new round |
| Only one Autopilot capture for several failures | Automatic capture is limited to one set of logs per day | Collect manually for the later failures |
What the zip contains, and what it leaves out
The collection is four sections, in the same order as the zip: registry keys, commands, event logs and files. On devices with KB5011543 on Windows 10 or KB5011563 on Windows 11, the zip is flattened and each item is named for the data it holds.
The command list is where most of the value is. It includes dsregcmd /status, ipconfig /all, certutil -store, mpcmdrun -GetFiles, msinfo32 and mdmdiagnosticstool. The files include the Intune management extension logs under ProgramData, which is where Win32 app and script evidence lives, as described in the Intune management extension. Configuration Manager client logs are collected too, which helps on co-managed devices.
The registry list includes the MDM firewall policy key under SharedAccess, which is useful evidence when Intune firewall rules silently fail. It shows what the MDM channel wrote, even when the rules never became active.
What is missing is just as informative. The documented event log list includes Application, Setup and System plus a set of operational channels such as AppLocker, BitLocker Management, Windows Hello for Business and the Defender SENSE channel. The Security log is not on it. Neither is anything from the user profile. If the question is about sign-in auditing or a per-user application, the remote action cannot answer it.
When to skip the remote action
Two local routes cover most of what the remote action leaves out. The Collect MDM logs article documents Settings > Accounts > Access work or school, then Create report, which writes to C:\Users\Public\Documents\MDMDiagnostics. It also documents the command line tool.
# Enrolment, provisioning and Autopilot logs in one zip, collected locally.
# Runs without the Intune service, so it works when device actions do not.
mdmdiagnosticstool.exe -area "DeviceEnrollment;DeviceProvisioning;Autopilot" -zip "c:\users\public\documents\MDMDiagReport.zip"
The same article points to the DeviceManagement-Enterprise event channel under Applications and Services Logs > Microsoft > Windows, where the Admin channel logs by default and the Debug channel has to be shown through the View menu in Event Viewer.
For a single Win32 app, the Win32 app troubleshooting article documents a Collect logs option in the app’s Installation details pane. It also names the agent log folder, C:\ProgramData\Microsoft\IntuneManagementExtension\Logs, readable with CMTrace. That is a narrower request than a full device collection. The failure patterns it tends to reveal are covered in Intune Win32 app deployment.
What I would do differently
I have not collected Intune diagnostic logs from a production fleet. My tenant is a lab with no enrolled devices, so the following is judgement from the documentation above.
Test the regional storage endpoint from each network segment before you need it. A blocked endpoint only shows up as a failed collection during an incident, which is the worst time to raise a firewall change.
Treat the 28 day retention as a deadline. Download every collection you might need into the ticket on the day it completes, because the tenant will not keep it for you, and a device holds at most ten collections at a time.
Know the list before you ask. If the answer needs the Security log or anything in a user profile, go straight to a local collection. The remote action will report success and hand you a zip without it.
Last verified: 26 September 2026
