Intune Device Query returns the state of a managed device in near real time, which is why people reach for it the moment a report looks stale. The assumption underneath that reach is usually that it ships with Intune. It does not. Device query sits inside Advanced Analytics, and Microsoft Learn states that Advanced Analytics needs a subscription in addition to Intune Plan 1 or Plan 2. This post covers what that licence buys, the limits that are documented but easy to miss, and the failures that look like a broken device. Every fact below was verified against Microsoft Learn on 16 September 2026.
The distinction is worth holding on to, because this is the tool you reach for when you cannot wait for the reporting cycle. In practice that means you have already tried forcing an Intune sync and you want to know what the device holds right now. Advanced Analytics reports are a different thing: the FAQ puts their refresh at roughly every 24 hours and says real time troubleshooting might require direct device queries. When the query fails instead, you are back to guessing, which is why the failure modes below are the useful part of this page.
What Intune Device Query requires before it will run
The prerequisites are split across two Microsoft Learn pages, and that split is the first place this goes wrong. The device query article carries the device and role requirements. The licence requirement is not on it. That lives one level up, on the Advanced Analytics overview, behind a link labelled prerequisites.
| Requirement | What the documentation says |
|---|---|
| Platform | Windows only, for single device query |
| Ownership | Managed by Intune and marked as corporate owned |
| Join state | Microsoft Entra joined or Microsoft Entra hybrid joined |
| Role | A custom role including the permission Managed Devices/Query, plus read access such as Organization/Read and Managed devices/Read |
| Transport | Windows Push Notification Services, described as a mandatory dependency |
| Licence | A subscription in addition to Intune Plan 1 or Plan 2 |
| Cloud | Public, GCC High and DoD, but DoD support excludes device query |
Two of those rows catch people out regularly. Ownership is a device property in its own right and is not the same thing as the primary user: a Windows device that enrolled as personally owned will not be queryable no matter who is signed in to it. And the DoD exclusion is easy to miss because it is a note rather than a heading. The Advanced Analytics overview states that DoD support does not include device query or the resource performance report.
The licence question the device query page never answers
This is the part worth reading twice, because two live Microsoft pages describe it differently as of 16 September 2026.
The Advanced Analytics overview, last updated 21 May 2026, says:
This feature requires a subscription in addition to Microsoft Intune Plan 1 or Plan 2.
The advanced capabilities page at learn.microsoft.com/en-us/intune/fundamentals/advanced-capabilities, last updated 28 May 2026, says instead that advanced capabilities are available through Microsoft Intune Plan 2, the Microsoft Intune Suite, and select Microsoft 365 bundles.
Read literally, the first sentence means Plan 2 on its own does not entitle you and something has to be bought on top of it. The second reads as though Plan 2 is one of the routes in. I have not been able to reconcile those two sentences from the documentation alone, and I have not bought the add-on to find out, so I am not going to tell you which is operative in your tenant. What I would do is treat the more restrictive reading as the planning assumption and confirm entitlement against your own tenant before anyone promises a delivery date on it. The pattern is familiar from Endpoint Privilege Management cost, where what a base licence covers moved more than once.
The practical symptom of getting this wrong is not an error message about licensing. It is a device query blade that is present, visible and does nothing useful, which reads as a product fault rather than a purchasing one.
Single device and multiple devices are two different features
Intune Device Query is two features wearing one name. They share a query language and almost nothing else, Advanced Analytics lists them separately, and their documented limits do not match.
| Single device | Multiple devices | |
|---|---|---|
| Platforms | Windows | Windows, Android Enterprise COSU, COBO and COPE, iOS/iPadOS, macOS |
| Rate limit | 15 queries a minute | 10 queries a minute |
| Monthly cap | Not documented | 1,000 queries a month |
| Result ceiling | Result string truncated at 128kb characters | Around 50,000 records |
| Query length | 2,048 characters | Not documented |
| Joins | Not documented | Three, and a fourth fails the query |
| Role | Custom role with Managed Devices/Query | Help Desk Operator, or a custom role with read access |
The role row is the one I would check first in any tenant where this has been rolled out to a service desk. Help Desk Operator satisfies the multiple device path on its own. It does not include Managed Devices/Query, which the single device path explicitly requires. An operator can therefore run a fleet query happily and get nothing on the individual device they are actually on the phone about, and nothing in that experience points at RBAC as the cause. If your roles are carved up by Intune scope tags, check the permission and the scope separately, because they fail in the same silent way.
The 1,000 queries a month cap deserves more attention than it gets. It is published on the device query for multiple devices article alongside the join ceiling and the record limit, it is a budget rather than a throttle, and it is the kind of limit that stays invisible until the month a major incident eats it.
Where the KQL stops behaving like KQL
The query language is a subset, not the full thing, and the gaps are specific rather than general. Documented as unsupported: the !like operator, the offset parameter on now(), and negative values for the amount parameter of datetime_add() in the multiple device path.
The entity list is fixed at 21 names, so there is no discovery step and no custom schema. They are BiosInfo, Certificate, Cpu, DiskDrive, EncryptableVolume, FileInfo, LocalGroup, LocalUserAccount, LogicalDrive, MemoryInfo, OsVersion, Process, SystemEnclosure, SystemInfo, Tpm, WindowsAppCrashEvent, WindowsDriver, WindowsEvent, WindowsQfe, WindowsRegistry and WindowsService.
// Smallest useful shape: an entity and a documented table operator.
// count, distinct, join, order by, project, take, top and where are supported.
LocalUserAccount
| count
Two editor behaviours are documented as cosmetic rather than real. Entity type columns used inside aggregation functions can show a red underline because aggregations expect scalar values, and joins written with the left and right parameters can underline too. Both are noted as editor artefacts. That is a useful thing to know before you spend an afternoon rewriting a query that was already correct.
The failure modes
The query returns nothing and the device looks fine. Check ownership first. Corporate owned is a hard requirement for single device query, and a personally owned enrolment satisfies neither it nor any amount of retrying.
Every query against a subnet fails. Windows Push Notification Services is the transport, and the documentation is unusually blunt about it: because WNS is integral to this communication you cannot disable or bypass it, and if WNS is blocked or unavailable the device query will fail. This is a firewall and proxy conversation, not an Intune one. A site that filters outbound traffic aggressively will produce a device query that works from head office and fails everywhere else, which looks like an intermittent product fault and is not.
The query times out on a device that is switched on. Device query runs in real time and expects an immediate response. There is no queue and no deferred delivery, so a device that is asleep, on a metered connection or otherwise not reachable at that instant simply fails rather than answering later.
A large query returns partial data with no warning. The single device result string is truncated at 128kb characters. Truncation is the documented behaviour, not an error, so a query that quietly lost half its rows looks identical to one that found half as much.
A working query starts failing mid incident. Rate limits are per minute and, for the multiple device path, per month. A service desk pasting the same query repeatedly during a live incident is the exact traffic shape those caps are built to stop.
Nothing works in a sovereign tenant. DoD environments are excluded from device query entirely. No configuration change fixes that one.
What I would do differently
I have not run device query against a production estate. My tenant is a lab with no enrolled devices, so what follows is judgement about how the documented constraints interact rather than a report from an incident.
The first thing I would do is stop treating Intune Device Query as a troubleshooting tool and start treating it as a metered one. A documented cap of 1,000 queries a month on the multiple device path is small enough that ad hoc use by a whole service desk will exhaust it, and the failure arrives at the worst possible moment. Saved and reviewed queries are a better fit for that budget than a free text box.
The second is to settle the licence question in writing before any of this is designed into a process. Two Microsoft pages currently describe the entitlement differently, and a tool that turns out to need an add-on nobody bought is a tool that gets built into a runbook and then removed from it.
The third is to be honest about what device query does not replace. It reads state. It does not tell you why a policy did not apply or why an app failed, and for those the Intune management extension log is still the first place to look. Device query answers what is true on the device now, which is a narrower and more useful question than it first appears.
Last verified: 16 September 2026
