Device Query: A Mad Max Intune Suite Feature

This blog will show you how Microsoft is stepping up the real-time reporting game by introducing a new wonderful feature called: Intune Pivot Device Query.

1. Introduction

I decided to take a peek at a new cool Intune feature from the Intune Suite called: Device Query and how this real-time reporting tool is performing its query job on the device.

Before I dip my toes into the Device Query flow and the Intune Management Extension (IME) that is giving us the power to give us some real-time insights into what is going on, on the device, I need to explain a bit about what Device Query is.

Please Note: The bare minimum version of the IME, to have Device Query working should be at least. 1.73.202.0 but preferably 1.75.4.0 (to get the proper datasets/entities)

With Device Query, we will get the possibility to retrieve some real-time insights from the device within a few seconds. We can do so by selecting a device and defining a KQL (Kusto) query in the “Device Query” tab.

If we want to start using Intune Pivot/Device Query, you must have a valid license. Besides having the proper license, we also need to make sure that the Intune Management Extension is active on the device (pretty obvious) and that the device is enrolled in Endpoint analytics

Quickstart – Enroll Intune devices – Microsoft Intune | Microsoft Learn

If all of the requirements are met, we can start playing around with it. Now let me show you how we could start creating a KQL query to retrieve some information about the Bitlocker Status.

EncryptableVolume
| join Tpm
| project WindowsDriveLetter, ProtectionStatus, EncryptionMethod, EncryptionPercentage, Activated, Enabled, SpecVersion, Manufacturer
| where ProtectionStatus == 'protected'

In this example above, I am using the EncryptableVolume Entity/Dataset and adding the TPM Entity to it. If you want to learn more about how you could use KQL to query your device, read this blog from Joost Gelijsteen!

When we take a look at the datasets (Entities) available, we will notice that we are still restricted to a couple of WMI queries (QueryWMIEntity). You could spot them all if you check out the IME Pivot DLL!

I assume the number of available datasets/Entities will increase later on once Intune Pivot is being used broadly. Once we have defined the KQL query and pressed the run command, a push command will be sent to the device, triggering the IME to execute the Device Query.

After the query is executed successfully, it will send back the device query results to the service. This flow only takes a few seconds (if everything checks out!) Thats fast!!!!

For everyone familiar with CMPivot, let me show you something! CmPivot is a feature in Microsoft Endpoint Configuration Manager (ConfigMgr) that allows administrators to query and retrieve real-time information from managed devices in their environment. (sounds familiar,right?)

Once we open the IntunePivotPlugin.dll in the Intune Management Extension folder, we will spot something funny (at least in my opinion)

The Intune Pivot code has “some” references to CMPivot in it. Does it smell like a copy-paste? Let’s get back to the Intune Pivot game.

2. What’s happening

So, let’s take a closer look at what happens when we press the “Device Query Run” button in the Intune Pivot device blade. First, I will walk you through it. Once I am done talking, you can take a look at the Intune Pivot mspaint flow!

Once we press the Run button, a Post command will be sent to Microsoft Graph and a new query will be created. (createQuery)

After this query is created, a Push command (WPN)will be sent to the device

The IME will first check if a certain Feature/Flight is enabled. It does so by checking the Notification\EnableDeviceActionFeature in the registry. This registry key will be set/checked by the IME once it starts.

Once the registry keys are checked, the IME will start the IntunePivot Workload and kick off the PilotDeviceQuery flow. It does so by sending a policy request to the service (Fef.amsub0302.manage.microsoft.com) with the device token (SendWebRequestInternal). This policy request will ask for the DeviceQueryDetail payload.

The Intune service will respond with a policypayload. In this policypayload we will notice the KQL query we entered in the Intune Portal (QueryAsString) This query is a base64 encoded string.

Once the device receives the Device query, it will decode the base64 string and run the query (RunPivotQuery). To do so it will reach out to the IntunePivotPlugin.PivotRunner.Runner function in the intunepivotplugin.dll.(that’s already loaded when the IME service starts)

This DLL holds the knowledge to execute all of the KQL commands, which seem to be OS WMI queries (OSQueryWmi). Once the query is executed, it will reach out again to the service by providing the query results (DeviceQueryResult).

The result is another base64 encoded value and corresponds to the output/results we will get in the Intune Portal.

If everything checks out, the service will respond with an acknowledgment and will tell the device that the repsonsepayload with the query result it sent was successful. From there on the DeviceAction thread would stop.

So, now that we know the complete flow, let’s zoom in on the OSQueryWMI a bit more so we can fully understand what is going on when the query is being executed on the device itself.

3. OSQueryWMI

When the device query arrives on the device, Intune Pivot must execute it. To get the proper results for the query, it must load the proper WMI Provider first. In this example, I was using the EncryptableVolume WMI Provider.

So when we want to get the Encryptionstatus of the device, Intune Pivot will start querying the proper WMI Entity (querywmientity) and will load the corresponding DLL file (wbem\win32_encryptablevolume.dll)

The KQL language is different than what we used with WMI. To get the proper fields of data it will need to parse and map the KQL properties to the proper WMI properties. So for example, when we ask for VolumeID in the KQL query, this will be “mapped” to the DeviceID

Once the query has been parsed and it knows how to ask for the required data, it executes the WMI query and, as we noticed, sends back the results to the service.

4. The Flow

Now that we have zoomed in on the OSQueryWMI, let’s zoom out again and take a look at the total Device Query Flow!!!

Please Note: this flow is without the data protection enabled

Did you spot end-to-end encryption of the query results in it? Shall we take a closer look at it and how that part works?

5. End-to-End encryption

End-to-End Encryption….. Do you know where I got that sentence from? I “stole” that part from the Advanced Analytics Technical Takeoff

I was curious what this could refer to. To silence my curiosity, I opened the IDA tool and started sniffing around. I started to take a closer look at which possible flights/Client Features that could be enabled in the IME. The first thing I noticed was that the list of possible IME features also contained the EnableDeviceActionFeature we noticed earlier.

As shown above, Microsoft added a new flight to the IME, called IntunePivotUseProtectedData. This flight is going to add more security to the whole device query process.

If this flight is not yet enabled in your tenant, you could run into some issues when you want to perform a WindowsRegistry entity device query

These IME flights are defined by the service when the IME checks in. As shown below, in the response payload we will notice the EnabledFlights in it that mentions that the IntunePivotUseProtectedData flight is enabled!

Once the end-to-end encryption is enabled (IntunePivotUseProtectedData.) the Intune Management Event log will mention the fact that the data protection flight is: True.

If this feature is turned on, it will now try to retrieve the device query but this time with data protection.

We will notice that every device query we send to the device will now be Encrypted and Signed

By the looks of it, this data protection feature will embed the Azure Cert into the response

So… yeah… end-to-end encryption of the device query !!!!!! Nice!

6. Troubleshooting DeviceQuery

Please keep an eye out for my next blog if you want to know how you could troubleshoot the message : “An Error Occurred. Try running the query again”, when you want to Run a Device Query to a device.

This error will prevent a successful Device Query! So we need to make sure that this ain’t happening! If you want to know how to solve it, check out this blog!

Conclusion

Having the power to execute on-demand real-time queries to gain insights into the device is fantastic. It seems very reliable in my tests, and Intune Pivot Device Query would be a great addition to Endpoint Analytics. I can’t wait until this Pivot feature expands even more!