This blog dives into how Intune remote actions actually work. On day one, remote actions like BitLocker key rotation, diagnostics collection, or EPM support approvals are applied almost instantly. But after the first 8 hours, the same actions suddenly wait behind a five-minute delay, and we’ll explore why.
Remote Actions and the 5-minute delay
Have you ever triggered a remote action from Intune and noticed how quickly the device responds… on the first day?
Rotate a BitLocker key, pull the Diagnostics logs, or trigger a sync. During the first day (8 hours), the push notification arrives, the device checks in immediately, and receives the command.
The same is true when you approve an Endpoint Privilege Management Support Approved request. The user asks for elevation, you approve it in the Intune portal, and within those first 8 hours, the device gets the policy almost instantly, so the app can be launched with elevated rights.
But once the first day has passed, things change. Approve an EPM elevation request, and the device no longer checks in immediately to receive the policy. Try to pull diagnostic logs, and they don’t appear right away. Even a BitLocker key rotation waits its turn. Suddenly, every remote action seems to sit in a queue, held back by a built-in five-minute delay.
Why is everything so immediate on day one, but noticeably slower after that? We wanted to know why. Armed with IDA and Procmon, we pulled apart the DLL and traced every decision the system makes after a push notification arrives. That gave us a clear view of what is happening under the hood.
Remote Actions: Day One vs Day Two
On day one, right after enrollment, the behavior is clear. Intune sends a push notification to the device. The device wakes up, checks in, and executes the command. That’s why actions feel so quick during the initial hours.
But after roughly eight hours (and 1 minute), the device takes a different path. The push notifications are still sent, but they no longer trigger an immediate sync. Instead, the system creates a queued schedule created for queued alerts that waits five minutes before running omadmclient to check in.
That five-minute queued schedule created for queued alerts is the reason why all Intune remote actions suddenly feel slower the next day. Let’s find out how that task is created or when it is NOT created.
Remote Actions: The Actual Flow
Let’s examine when and why the remote actions from Intune could be executed with a delay of 5 minutes.
- Push notification arrives
Intune asks WNS to deliver the push to the device. - Build session key and load account info.
A new session is prepared, and account and config information is pulled in. - ShouldBlockMsg
The system decides if the message should be blocked. In most cases, it moves on, but we noticed a hidden check here: IsCriticalMsg. It is tied to a feature flight we are not going to explain in this blog, so for now, it remains a mystery. But the placement is important. If this flight is ever switched on, it could change how the push notification handles the 5-minute delay. - ShouldMsgBeQueued
From there on, the firstsessiontimestamp comes into play. The system compares the current time with the first session timestamp.
- If the timestamp is less than 8 hours old, the message is executed right away.
- If the timestamp is older than 8 hours, the message is flagged to be queued.
- Queued Schedule for queued alerts
Once marked for queuing, the device creates the Queued Schedule for Queued alerts scheduled task that triggers the device to check in, 5 minutes in the future. That is why on day two, remote actions executed from Intune suddenly feel slower.
The Mermaid Flow
Every step, we discussed above… and more 🙂
The Role of the FirstSessionTimestamp
When the device first enrolls, a timestamp is created, but as long as it’s still within the initial 8-hour window, push notifications (Remote Actions) are honored immediately. The device checks in right away and executes the remote action, which is why everything feels instant on day one.
But once the timestamp is written, the logic changes. The code checks the difference between the current time and the stored timestamp.
- If the difference is less than 8 hours, remote actions are performed immediately.
- If the difference is more than 8 hours, the push notification is queued, and the queued schedule kicks in with its 5-minute wait.
We confirmed this by removing the timestamp. The moment it was deleted, push notifications once again triggered instant syncs, even after the first day.
Beyond the Remote Actions Delay
Here’s the strange part. None of this is documented. Microsoft doesn’t mention that push notifications work differently in the first hours compared to later. There’s no official note about the firstsessiontimestamp, or about why devices switch from instant sync to a queued schedule after 8 hours.
And yet, once you know what to look for, the pattern becomes obvious. Day one: fast. Day two: queued with a 5-minute delay. Unless you stumble upon that hidden feature, there’s no way around it.
Closing Thoughts
EPM Support Approved is one of the best examples of why this matters. If you approve an elevation, you don’t want your user sitting around waiting 5 minutes for the device to sync. The same goes for Remote Diagnostics Collection or BitLocker key rotation.
The good news is that the push system itself is solid. The delay isn’t a failure…. It’s by design. But the timestamp and the queued schedule are what turn instant actions into delayed ones.
And the fact that a hidden feature exists that can bypass it? That part remains a mystery for now.