What Really Happens When You Press Remote Sync in Intune

Pressing the Sync button in Intune looks simple, but it is not a command sent straight to the device. It sends a signal, and then Windows decides if and when anything should run. This blog explains, step by step, what actually happens when you press the magical remote sync button in Intune. Not conceptually, but technically. From the moment Intune requests a push notification to the point where policies are evaluated on the device.

Introduction to Remote Sync

When IT admins press the Remote Sync button in Intune, they expect the device to begin processing everything immediately.

All of the Policies should be refreshed. Required apps should begin installing. PowerShell Scripts should run. If nothing happens, it looks like something is broken. Most of the time, it isn’t.

The confusion comes from what the button actually does. “Sync” sounds like a universal command (which it could be), but Intune does not have a single sync engine to talk with the device. Windows uses multiple management paths, each with its own trigger model. The Remote Sync device action only talks to one of them.

Pressing Remote Sync does not contact the device directly. The Intune sync does not start app installs. It does not wake the Intune Management Extension (IME). It just sends a push notification, and then Windows decides if and when anything should happen. Once that scope is clear, the rest of the flow becomes much easier to follow.

What Remote Sync actually does

As mentioned before, performing a remote sync of the device in the Intune portal does not contact the device directly.

Intune cannot open a management session on demand. Instead, Intune marks the device as needing a check-in and requests a push notification through Windows Push Notification Service (WNS).

At this point, nothing has happened on the device. No SyncML has been exchanged, no policies have been evaluated, and no management engine has started. Intune has only asked WNS to notify the device that something changed. Everything that follows depends on whether that push arrives and how Windows processes it.

The Sync Push Does Not contain the Policy

As discussed in our previous blog, discussing the 8-hour Intune sync maintenance myth, the push payload is not a policy update, nor does it contain any other policy information. It just is a small base64 encoded JSON structure containing a notification identifier, a version number, and minimal metadata. It carries no CSP data and no commands.

Decoded, the Push Channel Payload looks like this:

Its only purpose is to signal that something has changed and that Windows should consider starting a management session later. Policy processing comes after that decision, not inside the push.

How the push reaches Windows

When you press Remote Sync in Intune, Intune does not open a live connection to the device. Instead, it asks Windows to notify the device that something may need attention.

That Push notification is delivered using the Windows Push Notification Service. WNS is the same delivery system Windows uses for other system notifications. Its only job is to deliver a small message to the device, not to execute management actions.

When the device receives the push, Windows accepts it and stores it internally. At this stage, the push is persisted in the Windows notification database and logged by the Push Notification Platform.

Nothing starts syncing at that moment. No policies are evaluated. No management engine wakes up. Windows has simply recorded that a push arrived.

How Windows records the Sync Push using WNF

When the Windows MDM push arrives on the device, nothing starts syncing yet. There is no instant policy evaluation and no management engine waking up on delivery. The first thing Windows does is make the push visible inside the system so that other components can detect it.

That is handled through the Windows Notification Facility.

WNF is an internal mechanism Windows uses to store small pieces of state and to signal when that state changes. Instead of passing around events or commands, Windows updates a WNF state value. Other components that care about that state can observe it and react when it changes. The value does not represent a queue of notifications. It only reflects the current state, together with a change stamp that shows it was updated.

When the enterprise push is delivered, Windows updates the WNF state that belongs to that management channel to show that a push has been recorded.

At this point, nothing is executed. No sync session is started, and no process is launched. The update simply makes the presence of the push visible to anything that listens for that state. This update is not an instruction and does not require immediate action. It answers only one question inside the system: a push has been received for this channel, yes or no.

That moment marks the boundary between delivery and execution. The push is now stored in a specific state, but the decision about what to do with it is deferred. One component that observes this WNF ENTR PUSH Received Trigger state is the PushLaunch scheduled task, which responds to the state change and becomes the first point in the chain where execution can begin.

How The Push Launch Task Listens to WNF

The PushLaunch scheduled task is registered in the system during enrollment and it is wired to react to changes in enterprise WNF states (WnfStateChangeTrigger).

When WNF_ENTR_PUSH_RECEIVED changes, the Task Scheduler fires the PushLaunch task… because that Push Launch task is wired to the specific WNS State Change: 75E0BEA328998213

From that point on, PushLaunch does exactly one thing: it launches the deviceenroller.exe.

Push delivery does not mean immediate execution.

The Deviceenroller does not immediately start an OMA-DM session after validation. Even a valid push does not automatically trigger immediate policy processing. Instead, deviceenroller evaluates whether the sync should run now or be queued. This decision is influenced by system state and push handling rules. One of those rules is whether the push message is treated as critical or non-critical. (more on this flow in a future blog)

If the Push message is not critical, a new temporary scheduled task will be created called: queued schedule created for queued alerts.

That queued scheduling for queued alerts seems to exist to protect the system. It allows Windows to throttle push notification processing but adds a 5-minute delay before the device starts syncing. This is exactly why a remote Intune sync feels like nothing happened on the device.

The Deviceenroller decides what happens next.

Up to this point, Windows has only received a push notification and scheduled an Intune check-in for later, typically five minutes in the future. No MDM session has started yet. When Windows decides it is time to execute that queued schedule, it again launches the deviceenroller.exe.

The deviceenroller now starts an OMA-DM session. At that moment, omadmclient.exe takes over. SyncML is exchanged, the change nodes (policies) are evaluated, and changes are applied.(get-set-get)

This is the moment the device finally starts a real Intune sync. Everything before this was delivery, state updates, and scheduling. Once deviceenroller starts the OMA DM session, SyncML begins to flow, the device requests its policies, evaluates them, and applies any changes. This is the first point in the entire flow where policy processing actually happens.

The full technical flow

Putting it all together, the actual Intune Sync sequence looks like this:

• Admin presses Sync
• Intune asks WNS to deliver a push notification
• WNS delivers the push to Windows
• WNF state is updated to reflect the received enterprise push
• PushLaunch task fires based on the WNF state change
• deviceenroller.exe starts
• GetPushAlertInfo validates the push payload
• deviceenroller decides whether the OMA-DM session runs now or is queued
• omadmclient syncs policies

The flow above shows exactly what happens when someone presses the Sync button in Intune and what happens from the moment Intune sends a push notification until policies are evaluated on the device.

What it does not show is just as important. Nowhere in this flow does the Intune Management Extension appear. There is no handoff, no trigger, and no wake-up for app or script processing. The Remote Sync Device Action’s job is done once the OMA-DM session is executed. That is where most expectations break.

Proving that the MDM push arrived

Everything so far is theory until you can prove it.
Because the PushLaunch task is wired to the WNF_ENTR_PUSH_RECEIVED state, you can just attach your own scheduled task to the same WNF state and watch the push notification arrive in real time.

The idea is simple:

• Reuse the same WNF trigger (75E0BEA328998213) as the built-in PushLaunch task
• Run your own script when that WNF state changes
• log an event (and optionally show a pop-up) every time a push comes in

A minimal PowerShell script for that task could look like this:

$logName = 'Application'
$source  = 'MDMPushMonitor'
$eventId = 50001

if (-not [System.Diagnostics.EventLog]::SourceExists($source)) {
    New-EventLog -LogName $logName -Source $source
}

Write-EventLog `
    -LogName  $logName `
    -Source   $source `
    -EventId  $eventId `
    -EntryType Information `
    -Message  'MDM push notification WNF state change received'

# Optional: notify the active user
$s = (quser 2>$null | Select-String 'Active' | ForEach-Object {
    ($_ -replace '^\s+','' -split '\s+')[2]
})
if ($s) {
    msg $s 'MDM push notification received'
}

You then create a new scheduled task that:

• runs as LocalSystem
• has a WnfStateChangeTrigger with the same state name as the EnterpriseMgmt PushLaunch task (75A0BCA328009213 for WNF_ENTR_PUSH_RECEIVED)
• uses powershell.exe -File <path-to-script> as its action

From that moment on, every time you press Remote Sync and Intune sends an MDM push, you will notice a couple of things:

• an event in the Application log with source MDMPushMonitor and event ID 50001
• the popup message on screen if the Push Notification made it to the device!

Check out the Video Below what it looks like

Intune Remote Sync Triggering Policy Sync and the IME

That proves the important first part of the chain:

• Intune asked WNS to send a push
• WNS delivered it
• Windows updated the WNF state

If your custom scheduled task never fires, the problem is in the push delivery path.
If it is executed every time but policies still lag, the issue is in the later stages (deviceenroller queue logic, OMA DM session, or IME timing), not in the push itself.

The funny thing, it that you could also use the same WNF trigger to launch a script that starts an OMA DM sync immediately instead of waiting for the queued task.

That may work in a lab, but it bypasses the built in throttling and validation in deviceenroller, so it should stay a troubleshooting experiment, not a permanent production fix…. well maybe you still yeet it to prod.

Why apps still do not react

Let’s be clear about one thing first: The Intune Remote Sync device action does not trigger the Intune Management Extension. (well with my adjustment it does). The MDM push generated by the Remote Sync Device action in Intune is consumed by the OMA DM client only (MDM). Its sole purpose is to signal Windows that a policy session may need to run. That signal can result in an OMA DM session and policy evaluation, but it has no authority over IME.

Applications, PowerShell scripts, and remediations live entirely inside IME. IME evaluates them on its own schedule and based on its own triggers. Even if policies arrive immediately through OMA DM, IME may do nothing at all. It will wait until its next evaluation cycle or until a separate trigger occurs, such as a Company Portal sync, an assignment change, or internal scheduling logic.

This separation is intentional. Remote Sync was never designed to be a universal “do everything now” button. It is a Windows policy signal, not an execution command. This is also where the so-called eight-hour sync myth comes from. When push delivery fails or never occurs, devices fall back to periodic behavior. What looks like a fixed interval is usually just IME waiting because no valid push ever reached the OMA DM side to begin with.

One interesting development is that IME is starting to gain its own real-time signaling channel through IC3, the same communication stack used by Microsoft Teams. That does not change how Remote Sync works today, but it does explain why IME may eventually become more responsive without relying on OMA DM push at all. For now, though, the separation remains absolute. Remote Sync talks to OMA DM. IME listens to something else.

Final takeaway

The Sync Device action in Intune is not a command. It is a signal. It sends a small JSON payload through WNS. Windows receives it, exposes it through WNF, schedules execution, and lets deviceenroller decide whether a management session should start. Only after that decision does SyncML flow and policies apply.

Once you understand that chain, Remote Sync stops being confusing. It becomes traceable, explainable, and predictable.