In this blog, I am going to take a closer look at how we can troubleshoot a new feature in Intune called Device Query, also known as Intune Pivot.
I will investigate which troubleshooting steps you could take when the Device Query push notification fails to be sent to your device.
1. Introduction
If you haven’t heard about Intune’s new magical feature, Device Query (internal name Intune Pivot), you have missed something big. In one of my latest blogs, I showed you how to use Intune Pivot to query your device and gain valuable insights into its activities. To do so, you will need to run a KQL device query.
If you haven’t had the time to read, you must drop everything and start reading it! It contains some critical information I used when the device query didn’t give me the proper results!
https://call4cloud.nl/2024/02/device-query-a-mad-max-feature
If you have read the blog, I can start telling you what happened and how I started troubleshooting! I was playing around with Device Query in our production tenant some time ago and wanted to learn more about the KQL language. But somehow, the first KQL query that I wanted to send to my device showed me a weird error message mentioning that an error occurred.
2. An error occurred
I entered a simple KQL command and pressed the run command to start querying the 10 processes on my device. Somehow, as shown below, it immediately showed me a weird error.
It mentioned that “an error occurred. Try running the query again” A nice error that doesn’t tell us anything.
Of course, I tried to run it again and..yeah, again, but you can guess the outcome: An error occurred. I guess the question we now need to ask ourselves, is how will we troubleshoot such kinds of errors? Well let me take you with me on a journey to start troubleshooting devicequery and let me guide you through all the stuff you need to check if you are experiencing issues with this new Intune Suite Addon.
3. Troubleshooting WNS
The first thing I needed to do was find a working device to compare the outcomes. Once I found a working device, I opened Fiddler on my device and made sure that I captured everything that was going on.
I pressed the run command to kick off the KQL query and started watching Fiddler. On a working device, it should get the devicequeryresults in the response, but something else happened on my not working device. Instead of showing me that an error occurred, I got the message: An Internal Server error has occurred
An Internal Server error occurred. Does this sound like an internal server error? In the device query blog, I showed you how Intune performs a device query to retrieve the information. One of the most important parts of this flow is the Push Notification that needs to be sent to your device. From there on, you could watch the Intune Management Event log executing the device query.
If the WNS service can communicate with your device, a Push notification will be sent to it. One place you will need to start looking is the PushNotification-Platform event log.
This event log should mention the push notification the second you press run to execute the device query. As shown below, in a working situation we will spot the event 1225, which mentions that WNP Transport Layer received a command.
If the event log doesn’t mention this push notification, you can be sure that no push notification was sent to your device. You can be sure of that!
So, on my device, that push notification didn’t show up, and with it, I was pretty sure that the Intune Management Extension log would not mention anything.
Besides not having anything in the Push notification event log, and the IME Log, Procmon also didn’t show anything that was trying to reach out to the push notification database. Additionally, you will also notice this message. As shown below, as long as it is mentioned, the fact that MDMPolicyValue is true…. you are good to go!
But what if, Cloud notifications aren’t enabled? Does it break this new Intune feature called Device Query? Let’s find out, shall we?
4. DisallowCloudNotification
let’s suppose you are doing some troubleshooting and you discover that all of the Push Notifications aren’t arriving on the device; we need to be sure that we are not using this stupid DisallowCloudNotification policy, which originates from the CIS Baseline.
18.7.1.1 Ensure ‘Turn off notifications network usage’ is set … | Tenable®
Let me show you DON’T want to use this policy by looking at the IntunemanagementExtension\Notification registry key
Of course, you could also spot the same kind of error in the IME log.
As shown above, the Error Message is the one you will need to keep an eye out for! It will mention the Error Message. The error message shows us that the Cloud Notifications have been turned off. Besides this error message, it was also NOT showing the proper ChannelAddress.(which we will get to in part 6)
So, if you are not receiving any push notifications at all, make sure that you are NOT applying this DisallowCloudNotification policy!
I guess Microsoft is pretty clear about this one! A nice warning mentions that this policy could break some processes.
Let’s switch back to my issue with Device Query because I wasn’t blocking Cloud notifications! I guess the next step in line would be to find out if other Device Actions are working….. or not!
5. Other device Actions
I guess it is pretty obvious that somehow my device has issues with push notifications. I was wondering if other remote device actions would also cause push notification issues. I selected my device and performed a Remote Sync, and executed a Bitlocker Key rotation
The moment I pressed sync, the Push notification arrived on my device (the event log showed the arrival of the push notification). From there on, a queue was created with a delay of 5 minutes for the queued alert, and eventually, the sync with Intune was initialized.
PushLaunch | Intune | OMADMCLIENT | queued for 5 minutes (call4cloud.nl)
After that, the Remote sync push command was successfully sent over to my device. I also tried to perform a Remote BitLocker key rotation. The same thing happened with the remote sync command; the push command showed up in the event log, and 2 minutes were added to the start time of the queued task schedule.
After waiting for exactly 5 minutes, the schedule to run OMADMCLIENT by the client (initializing the sync) started, and recovery password rotation was initiated.
So to resume, my device seems to have issues with the IME push notification but NOT with the Windows MDM push notification.
I decided to start taking a closer look at the Intune Management Extension log file itself to find out if I could spot the culprit
6. GenericWorkload
When the IME service starts in about 10 minutes, a queue is triggered to fetch the WNS channel URI from the registry and WNS.
The Intune Management extension should perform a regular Workload sync following a specific maintenance timer. So, the first thing to look at is if the “ChannelUriLastSucessSyncTime” is up to date in the GenericWorkLoadSettings. If it’s not mentioning a proper date or if FailsSyncTime is also mentioned, I guess you are up for some fun!
As shown above, when you are experiencing issues with Push Notifications that are not arriving on the device, you will need to check if the outbound data connection is being mentioned in the IME log. If it’s totally not being mentioned in any of the IME logs, that will mean that possible IME check-in failures are occurring.
While looking at the genericworkload and trying to figure out why the IME push notification wasn’t arriving on my device and why my device was failing the IME GenericWorkload, I stumbled upon the IMENotificationApp
7. IMENotificationApp
Yep…. you read it correctly the IMENotificationApp.
So, how are we going to troubleshoot this fancy IME Notification app any further? Well, let me show you first what stupid things I tried to fix this.
Good to know is that if your device just booted, you will need to wait a bit until everything is started before you can perform a device query. If you don’t have that patience…(10 minutes) this is what you would notice. “Running Query”
After those 10 minutes and sending a device query that would send a push notification, the IMENotificationApp will trigger the device query.
Here comes the stupid idea… I was wondering if removing the ImeNoticationApp from the registry could trigger a repair of the push notification (I found the registry location in the IME code), so I did.
After removing the above pushnotifications registry key I restarted the IME service.
After 10 minutes of waiting again, the IME log showed me that it was indeed trying to register the App for notifications.
At that same moment, the ImeNotification registry key I had deleted came back to life. Problem solved? Nope! I restarted the device again and waited but the devicequery was still failing. I thought of deleting the same kind of registry key which is stored in the s-1-5-18 (system user)
This registry key holds the device ID that I also noticed in the WPR traces, but somehow, I didn’t feel that comfortable doing that.
7. Fixing the Push!
I was almost out of ideas until it hit me….What if I remove the Intune Management Extension (IME) and let Intune reinstall it again? You might wonder why did I decide to do this? Well, this is why!
- Intune Device Query uses the IME!
- The WNS channel error and the fact that it is mentioning NoSync?
- The GenericWorkload wasn’t checking in?
- The IME Notification Push App that I stumbled upon
The IME is a tracked app, so when I uninstall it and sync the device with Intune, it will receive a notification that the IME is missing and trigger the reinstall of the IME.
So, I uninstalled the IME and started the sync with Intune. After a minute or 2, a lot of events started popping up in the push notification event log. First, it mentioned that it added the user with a specific device ID to the Windows Push Notification Service.
From there on it requested a device compact ticket for the data connection, which is indeed a requirement
With the device compact ticket, it started the data connection with client.wns.windows.com
This looks good, way better than I expected! I wasn’t expecting that removing and reinstalling the IME could trigger this. I watched the IME and waited again for 10 minutes for this message to show up
After the above message was shown in the IME, I executed a new device query, which took a bit longer than I expected
As shown above, IntunePivot/ Device Query was initialized by the working Push notification!!! It seems that the reinstallation of the IME also repairs the Windows Push Notification connection! That’s good to know!
Conclusion
When you are having issues with DeviceQuery and somehow the push notification isn’t sent over to the device, you should check out the Intune Management Extension and its Event log! If it’s giving you the same issues as I have shown you, an official reinstall by Intune could solve it!