Last Updated on March 31, 2024 by rudyooms
This blog will be about a big under-estimated schedule!! I am going to dive into the PushLaunch scheduled task once again. This Task is responsible for delivering push notifications from Intune (and MMP-C?) to our device. I am going to show you what you need to be aware of when you are abusing Windows LAPS (or any other feature that relies on the PushLaunch tas) to deliver the notification to the device.
I will divide this blog into multiple parts.
1. Introduction
This blog is going to zoom in on the PushLaunch task and the corresponding dmwappushservice. You could start wondering where you have heard about that service before. Almost a year ago I wrote a blog about why the corresponding dmwappushservice is very important.
Intune | Device not Syncing | Missing dmwappushservice (call4cloud.nl)
In that blog, I mentioned the fact that when you are sending out a push command to the device, such as a “Rotate local admin Password” action, the PushLaunch scheduled task will be triggered.
When this PushLaunch is triggered, it will instantly kick off the schedule to run the omadmclient.exe and will start syncing the device with Intune. At the moment the device syncs it also executes the push command that was sent over to the device (for example rotating the laps password)
But what if…. What if the PushLaunch ends up with the error 0x82AC0204? When the pushlaunch task gives you this error, the remote command to reset the LAPS password will no longer be executed immediately! I am going to show you why and what exactly changed
2. Has the PushLaunch task changed?
When we take a closer look at what will happen and what happened in the past, we will notice that the pushlaunch task will still be executed but from there on it kicks off a different schedule than I was expecting.
Instead of kicking off the Microsoft Phone Provider omadmclient immediately, it will now create an additional task schedule. This schedule will be created temporarily and this nice new scheduled task is named: “Queued schedule created for queued alerts”
You would expect this task to appear in the main enterprisemgt\enrollmentguid folder but somehow a new folder named: EnterpriseMgmtNonCritical will be created. (the same folder which the Config Refresh task schedule will appear in)
I guess it’s all in the name… schedule for queued alerts. This task will scheduled to be executed 5 minutes after the pushlaunch task is completed (with a nice error. So don’t mind the error.. which is not an error at all)
But what does this task do? Almost the same as the PushLaunch task will do but with 1 small difference.
Instead of executing the deviceenroller with the regular /z parameter, it will now pass the /q parameter. When this queued schedule is executed it will kickoff the schedule to run the omadmclient.
If this schedule exits.. even when it’s a bad exit, the OMADMPRC.exe will trash that scheduled temporarily queued task.
So the bottom line? Please beware of the fact that a push notification will not be executed on the fly but could take another 5 minutes. Patience we must have, and one thing is for sure… people working in IT, don’t have patience.
3. Why I was looking
Okay… so I stumbled upon a 5-minute delay… no big deal, right? Let me show you why this behavior caught my attention.
A couple of my VMs are running the Windows Insider build. Almost every week, when a new version arrives, I will copy the most important DLL and exe files to my device and do a wild text search at it. So for example, I am always making sure I get a copy of the important enterprisecsps.dll file.
Guess what it showed me? Besides the Windows MDM Push notification, we suddenly have a new Windows MMPC Push function
When switching back to the insider preview build, I noticed that we now have a pushlaunch task inside the MMP-C enrollment
Does this mean that we are going to get a new button in Intune? As shown below, maybe a nice new button to initialize a Microsoft Management Platform -Cloud sync would show up?
Some months after releasing this blog, it became obvious why we got this new WindowsMMPCPush WNS app, delivered to our devices. The support-approved EPM Feature is using this WindowsMMPCPush app to deliver the Time To Live EPM elevation rule to our device, once we approved it in Intune.
Support Approved | EPM | Endpoint Privilege Management (call4cloud.nl)
4. The flow
When we take a look at the flow, we will notice that a particular function inside the omadmapi.dll is responsible for queueing those alerts (shouldmsgbequeued), and from there on I created the flow
Conclusion
When looking at all the features that are relying on the PushLaunch task, such as
LAPS Password retrieval, Remote Syncing the device, On-demand Pro active Remediations, EPM Support Approved (MMPC Channel), and also Device Query it is becoming obvious why Microsoft added a queue to the flow.
If we perform multiple remote actions at the same time, the Omadmclient would start going crazy. When you perform a remote action, it would kick off the sync. You don’t want to have the device checking in to the service on each remote action. When you hammer the service, they will throttle you!
