In a previous blog, we showed that something new is quietly showing up inside the Intune Management Extension…something called IC3. At first glance, it looked like just another component. But, believe me… it is not. This is the same communication platform used for real-time Teams messaging, and it now appears where Intune reaches the device.
But that first part mainly answered one question: what is IC3 doing in the IME? This second part answers the next one: What happens to the old Intune flow once IC3 starts taking over?
The Current Intune Flow
The deeper I looked into Intune timing, the clearer one thing became. Windows management never really behaved like one single communication model.
One part of the platform lived in the MDM world. Policies, remote device actions, and similar actions relied on a push notification that had to wake the device and to get the MDM stack running.
Another part lived in the IME world. Win32 apps, PowerShell scripts, remediations. Those IME/Sidecar workloads followed their own evaluation cycles, timers, and internal logic. That meant the device was already split into two different timing models. One side waited for a push notification to arrive. The other side waited on polling or timers. That is one of the real reasons Intune’s timing has always felt inconsistent.
IC3 Starts Replacing What WNS Used to Handle
That is where the story starts to change. For a long time, WNS was the path Intune relied on when something needed to happen quickly on the device. A policy changed, a remote action was triggered, Intune sent the nudge, and WNS was supposed to get that signal to Windows.
If that worked, the device woke up and checked in. If it did not, the device waited. That older design always had two weak spots. The first was WNS itself. Once the signal left Intune and entered that path, it disappeared into a black box.
The second was that this only helped part of Windows management. The IME side still lives on Internal timers, polling, and workload-specific logic.
IC3 totally changes that direction. It does not look like a small improvement to the old design. It looks like the beginning of a replacement for it.
What IC3 Starts to Look Like
If you put the old flow and the new direction side by side, the shift becomes much easier to see.
Instead of one side depending on WNS while the other waits for its next cycle, both the MDM world (policies) and the IME World (Win32Apps/Scripts) begin pointing toward the same notification channel….IC3. With it, WNS starts fading into the older path. Timers start fading with it. And IC3 is starting to look like the place where the IME and MDM worlds finally meet.
IC3 and Future Device Actions
The first blog already showed the most important technical clue: when an IC3 message arrives, it is decoded and pushed straight into the IME’s internal device action callback. Following that path lands you in EmsAgentService.DeviceActionCallbackAsync inside the Intune Windows Agent.
If IC3 already lands in the same callback pipeline, then this is no longer only about IME specific actions. It also opens the door for remote actions that live in the MDM words, like Sync, Wipe, Retire, SetDeviceName, and RotateBitlockerKeys, to move away from the opaque MDM WNS path and into the same stateful channel.
What That Means for Win32 Apps and Scripts
Our previous blog already pointed out the most obvious example: Win32AppWorkload.
That matters because required Win32apps have historically depended on the IME’s own evaluation timing (60 minutes), including the familiar pull cycle rather than an immediate push trigger.
If Win32AppWorkload moves over to IC3, Intune no longer has to wait for the IME’s next timer to come around. It can wake up the device, tell the IME to kick off the Win32 app workload, and start processing the app install right away.
That is the real change. Instead of sitting around waiting for the next scheduled IME cycle, the device can react when the IC3 push message arrives. And once that becomes possible for Win32 apps, it is hard not to look at PowerShell scripts, remediations, device inventory, EPM related actions, and other current Windows MMP-C push scenarios the same way.
Remote Help Already Points in That Direction
This is also why the Remote Help announcement in the “whats in development” matters.
Remote Help is one of the clearest signs that Microsoft is already moving time-sensitive IME device actions toward a more direct notification path (IC3). Once you see Remote Help show up in the same action model, it becomes much easier to understand where this is heading. The same communication layer that can handle Remote Help can just as easily become the place where other time sensitive actions land as well.
And that opens the door far beyond just apps. If IC3 becomes the shared path for real-time actions, then it is not hard to imagine more MMP-C style push notifications moving over to it. EPM-related actions, device inventory, policy-related triggers, and other Sidecar-style workloads all make more sense once the device no longer has to wait for a timer or rely on WNS to deliver the message.
Summary
The arrival of IC3 inside the Intune Management Extension marks a shift toward a more responsive Intune. A live IC3 connection gives the IME its own real-time channel, which means actions routed through it no longer have to wait for timers, polling, or the uncertainty of WNS delivery.
That matters for both sides of the story. On one side, older remote actions such as Sync, Wipe, Retire, SetDeviceName, and RotateBitlockerKeys can move away from the opaque WNS path and into a direct stateful channel that the agent maintains itself.
On the other side, Win32 app workloads, scripts, remediations, Remote Help, and other IME-driven actions no longer have to depend on their own isolated timing model before something finally happens. That is the biggest shift ever.
If IC3 becomes the channel for time-sensitive communication, then WNS can fall back to the broader background flow while the IME becomes the place where real-time actions actually land. That is why IC3 feels bigger than another protocol change.