INTUNE: Report All Devices That Are Non-Compliant Because They Are Inactive

First published on TECHNET on Feb 23, 2019

It's me Anil Abraham again with a quick blog. These days my job involves walking into customers and talking about modern device management and shift from the traditional management methods to the new ways. Obviously, Intune plays a big part in modern device management.

More often these days, I get asked the question of how about reporting and the flexibility we had with SCCM in terms of capability that came with SSRS that let us create custom reports.

Customer Query:-

The other day one of the customers asked me a question, report all devices in Intune that are reported as non-compliant because they have not reported back to Intune in the last 30 days. 30 days because in Intune that is the default setting for a device to be marked non – compliant if it hasn't checked in.

Microsoft Graph is your answer. For those that are new to Microsoft Graph start @

The data that Intune exposes, be it inventory data, policy or apps, they are all exposed via Microsoft Graph.

For people familiar with Graph and Intune, the query that gives the result is
deviceComplianceSettingStates?$filter=state eq ‘nonCompliant'

For people who are new to this…

Sign into Graph Explorer ( ) using an account that has delegated permissions to read the properties and classes that you are after. More details @

For a quick view of the data that is held within Intune and exposed via Graph, an example of all the enrolled devices is as below.

Getting there…

I started looking at the API for Intune @…

From the request, I know, I am after a specific device compliance setting, so first step is to find all the device compliance policy settings, which I found was listed @…

From the above I could identify the query to be run in Graph Explorer as

This gives me a list of settings that are part of compliance policies as below in the graph explorer.

Going through the list I could identify the value that I was after as below.

I hear you ask, what is so much about it as there is this list you could Export from the Intune Web console. A sample from test tenant is below. The intention of this blog is to give an overview of the Graph and access to data within.

As you can see the numbers from the graph explorer matches what you see for the “Is Active” setting. You also have the option to export the report at this level. You could drill down further in the Intune Report as below.

There is an export option here too and you could get the data into Excel but it gives you all the devices, both compliant and non-compliant and then you should filter in Excel to get the data that you are after.

Let's look at do all this in Graph Explorer. From the previous exercise in Graph Explorer we know the ID of the setting that we are after is DefaultDeviceCompliancePolicy.RequireRemainContact.

Further constructing the query to report only on the above said setting and devices to show only that compliance setting value, I built the query as below

Result is as below

The result shows all the 12 devices in my test tenant and the compliance state for each of those devices against the DefaultDeviceCompliancePolicy.RequireRemainContact setting.

Sample data for a device that is non-compliant is as below.

As you can see the value that we are after is the value of the property “state”. So, with that knowledge building the query to show only the devices that are non-compliant for that setting would be… eq ‘nonCompliant'

In action the result would look like below.

The result is the 9 devices that are non-compliant because they have not contacted Intune for the last 30 days.

But, I can hear you say, Anil I want to report all this programmatically and reporting through Graph Explorer is not an option in an enterprise. If there is enough interest and I can find some time I will put a Part 2 to show how we could automate all this.

Hope you find this helpful….


This article was originally published by Microsoft's Core Infrastructure and Security Blog. You can find the original article here.