A new DLL just appeared inside the Intune Management Extension, AKA Sidecar Agent folder.
It references IC3… which is the same platform that powers real-time communication in Teams.
So why is it showing up in the IME? Well, let me show you what I think will happen!
Introduction
A while back, I wrote about how Intune relies heavily on WNS push notifications. The Windows Notification Service was the middleman (The Blackbox), Intune sends a nudge/push, WNS tries to deliver it, and if it makes it through, the device checks in. That model works, but the WNS is just a bit fragile. Sometimes pushes vanish in thin air, sometimes they’re delayed, and Intune has no clue if the device actually received them…. Because…WNS is a block box.
Now something new has appeared in the Intune Management Extension (IME) folder: Microsoft.IC3.Trouter.dll
That name might ring a bell…not because IC3 sounds like “I see three” when you are standing in line at the supermarket, but because it is the core component of Microsoft Teams.
If you’ve ever looked at how Teams works, IC3 is the Intelligent Conversation and Communications Cloud. It’s the backbone/platform that keeps Teams messages, calls, and presence flowing across millions of devices in real time. It doesn’t just “send and hope.” It maintains a persistent, stateful connection and knows exactly whether a client is online…. or not.
So why is the IC3 Dll suddenly part of IME, and why are we noticing the EnableIC3Feature flight showing up in the IME log?
A First Small Peek Inside the IC3 DLL
Let’s start with a quick peek inside the IC3 to see what we are looking at. Good to know is that the IC3 DLL isn’t another DLL. This IC3 DLL ships with a full Trouter client IC3 implementation. Some things that immediately stood out when we opened up that DLL:
- Connection states:
Initial → Connecting → Connected → Disconnected → ErrorConnecting
This isn’t a fire-and-forget model like WNS. Intune will actually know when the device is online.
- Registration logic:
- Posts to v4/users/ME/endpoints
- Declares a transport type of TROUTER
- Provides a context, forwarderUrl, and a ttl (time to live)
- Enforces rules: TTL must be at least 300 seconds, refresh must happen at least 30 seconds before expiration
- Uses correlation vectors (MS-CV) for end-to-end tracing
- Auth flow:
- All requests are wrapped with whatever headers the IAuthenticationHeadersProvider supplies.
- The code even supports client certificates (RegistrarApiClientV4 switches modes when a cert is passed).
- Retry & resilience:
- Exponential backoff (1, 2, 4, up to 64 seconds) if registration fails.
- Automatic refresh scheduled before TTL expiry.
- Clean unregistration on shutdown.
In other words: this isn’t “maybe we’ll try to check in.” This is persistent registration with retries, telemetry, and state changes.
What Does IC3 Mean for Intune?
If the IME is maintaining a TROUTER registration with IC3, it suddenly looks a lot more like a Teams client than a passive MDM agent. Which hints at some pretty cool changes:
- Direct channel: Instead of waiting on built-in IME timers, the IME could keep a socket open to Microsoft’s IC3 backbone.
- Real-time awareness: The client knows if it’s connected or not (Connected vs. ErrorConnecting). Which means Intune could know this, too. Imagine seeing an “online/offline” signal for devices, instead of guessing. Did I spoil something here :)?
- Device Action notification delivery: The payloads show context and forwarderUrl. That suggests notifications can be routed more precisely, not just “go sync,” but “send this here.”
- Resilience: With retry, TTL refresh, and clean unregistration, this channel is built for continuous reliability.
Let me zoom in a bit more on Device Actions and Real-time Awareness, and how they connect to the Intune Windows Agent and the IC3 DLL.
WNS vs IC3
Right now, we’ve only seen the IC3 DLL and its registration logic. But combined with what we know from the WNS story, it paints a pretty clear picture:
- WNS was the middleman for the Policy Delivery.
- IC3 is direct
- IME is quietly learning how to be an always-connected client.
And there’s one more detail hidden in the DLL that explains why this matters. When an IC3 message arrives, it doesn’t just drop a ping or set a flag. The IME has a listener directly in the notification flow.
Whatever comes in is decoded, logged, and pushed straight into the IME’s internal device action callback. That callback is where IME decides what to do with the notification payload.
The DeviceActionCallBack
And the interesting part is what this Device Action callback actually is. When you follow the reference inside the DLL, the IC3 deviceActionCallback doesn’t point to some new or experimental handler. It lands straight inside EmsAgentService.DeviceActionCallbackAsync in the IntuneWindowsAgent.
That’s the same method the IME already uses for SideCar notifications today. The IC3 listener is simply feeding that pipeline. Nothing new runs next to it. IC3 just delivers the payload, and the IME processes it with the same logic it already has for device actions.
Each notification is archived under the SideCar DeviceAction registry path together with its action name, timestamp, and notification ID.
That got me thinking… with IC3 adding its own notification payload to the IME… what else could it bring?
Could Other Device Actions Move to IC3?
When you look at how things work today, most Intune remote actions still depend on the same pattern Intune has used for years. Intune sends a request to the device; WNS tries to deliver the push; if the push makes it through, the device wakes up, and the MDM stack takes action. If the push doesn’t make it through, Intune waits for the device to check in on its own. That is precisely why WNS has always been the weak link, aka the Black Box.
It’s outside Microsoft’s control, completely opaque, and Windows can’t tell whether a notification was delivered or silently dropped somewhere along the way…. Neither can Intune.
Now compare that to IC3. The IME is sitting there with a real listener, a persistent registration, and a direct callback for device actions. Nothing needs to “wake up.”, nothing needs to poll, and nothing has to rely on WNS making it through the Black Box. If Intune ever decides to use this channel, the IME would react the moment the message arrives.
And that brings up an obvious question. If the IME already handles certain actions internally, such as BitLocker key rotation and the logic behind Remote Help, what prevents Microsoft from routing other actions through IC3 instead of WNS? Wipe, restart, sync, retire… all of them suffer from the same WNS fragility today.
IC3 Device Actions
That idea triggered me to dig deeper into the IME code… until I noticed the current ActionName list. All the current remote device actions are in the list. From a remote wipe to InitiateMDMKeyRecovery
Why would the IME know every device action when today the flow still leans on WNS to deliver a push before the CSP command ever arrives? Well… I think it’s pretty clear.
It doesn’t yet prove that Microsoft is moving on those actions, but the pieces are starting to line up. WNS is the one part of the chain Microsoft can’t fully control, and WNS has its flaws. IC3 is entirely theirs. The IME now maintains a live, persistent connection and a direct device-action callback. Put that together, and the direction becomes hard to ignore. The IC3 channel is quiet for now because the IC3Feature flight isn’t active, but the plumbing is already in place. The moment Microsoft turns it on, the IME can react the second a push notification message lands via IC3.
And that brings up another question. Device actions may be the obvious focus… but what if that’s only the beginning?
Real-time awareness:
So what could follow? Faster Win32 App installations? Real-time script triggers? Or even just something as simple and as powerful as a green/red Online Status switch in Intune that finally tells you whether a device is truly online?
Please note that this picture above is a mock-up… I think?
Still, it’s worth remembering that a green “online status” doesn’t automatically mean “healthy.” A device might show green because its IC3 channel is alive, while SideCar or other Intune components could still be having an issue. IC3 is about presence… knowing the line is open… not about verifying that every service behind it is working as expected.
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 device actions no longer have to wait for timers, polling, or the uncertainty of WNS delivery. Anything routed through IC3 can reach the IME the moment Intune sends it, so app installs, script executions, and remediations can react instantly instead of on the next check-in.
At the same time, this takes pressure off WNS. If IC3 carries the time-sensitive work, WNS can focus on its original job of handling policy delivery without being responsible for actions that require immediate execution. IC3 handles the instant signalling. WNS handles the background flow.
The IME is quietly gaining the ability to respond in real time, but you’re still the one keeping the environment stable, fast, and reliable.