Last Updated on February 5, 2024 by rudyooms
In this blog, I am going to take a closer look at how we could troubleshoot A new feature in Intune called DeviceQuery AKA IntunePivot.
I will zoom in on which troubleshooting steps you could take when the DeviceQuery push notification fails to be sent to your device. I will divide this blog into multiple parts.
- Introduction
- An error occurred
- Troubleshooting WNS
- DisallowCloudNotification
- Other Device Actions
- GenericWorkload
- ImeNotificationApp
- Fixing the Push!
1. Introduction
If you don’t have heard about the new magical feature in Intune called: Device Query (internal name Intune Pivot) you have missed something big.
In one of my latest blogs, I showed you how you could use Intune Pivot to query your device to have some good insights into what is happening on your device. To do so, you will need to run a KQL device query.
If you haven’t had the time to read, you will need to drop everything and start reading it! It contains some critical information that I used when the device query wasn’t giving me the proper results!
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 over to my device showed me a weird error mentioning the fact 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 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 are we going to 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 to find a working device so I could compare the outcome. Once I found a working device, I opened Fiddler on my device and made sure that I captured everything that was going on, on my device.
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 on my not working device, something else happened. Instead of showing me that an error occurred, I got the message: An Internal Server error has occurred
An Internal Server error occurred, sound like an internal server error? In the devicequery 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 over to your device. From there on you could watch the Intune Management Event log executing the device query.
If the WNS service is able to communicate with your device, a Push notification will be sent to your device. One of the places 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, nothing is being sent over 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 was not going to 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.
Besides the Push Notification itself, 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 initialized the sync with Intune.
PushLaunch | Intune | OMADMCLIENT | queued for 5 minutes (call4cloud.nl)
After that 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 client (initializing the sync) started and also the 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 is started 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 there are possible IME check-in failures 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, it will trigger the IMENotificationApp to kick off the devicequery.
Here comes the stupid idea… I was wondering if removing the ImeNoticationApp in the registry could trigger a repair of the push notification (found the registry location in the IME code)…So I did…
After removing the above pushnotifications registry key I restarted the IME service.
After again 10 minutes of waiting, the IME log showed me that it was indeed trying to register the App for notifications.
That same moment, the ImeNotification registry key I 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)
As this registry key holds the deviceid 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 just 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 am going to uninstall the IME and syncing the device with Intune it will receive the notification that the IME is missing and will 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!
