Intune 2609: Faster Win32 App Delivery, Defender AI Protection and the New Device Page

The words you need, in one line each

The problem: the assignment lands, and the device has no idea

Here is the scenario every Intune admin has lived through.

You add a required Win32 app, assign it to a device group, and confirm the assignment saved. The device is online, healthy and checked in. You tell the requester it is on its way.

Then nothing happens. Not for ten minutes, not for an hour. You open the device in Intune, hit Sync, and it installs a few minutes later. So the deployment was fine all along — something just was not asking.

The second version of this is worse because it hits new starters. A device finishes Autopilot, the Enrollment Status Page completes, the user reaches the desktop — and the required apps that were not marked blocking for ESP simply are not there yet. The user's first experience of a corporate laptop is a half-built one.

Both symptoms have the same root cause, and 2609 addresses both.

Why it happens: the IME check-in is not the MDM check-in

The Intune Management Extension (IME) is a separate agent from the Windows MDM stack. It is what actually delivers Win32 apps, PowerShell scripts, remediations, custom compliance discovery scripts and platform scripts. It installs automatically the first time you assign any of those to a device or user. We pulled the agent apart in detail in why your Win32 app is stuck at "Processing".

And critically, per Microsoft's own documentation:

"The IME checks for new or updated installations with Intune services every 8 hours. This check-in process is independent of the MDM check-in."

That single sentence explains the shape of the problem. Your device can be checking in with MDM perfectly happily, showing a recent Last check-in time in the console, and still not have noticed a new Win32 app. The two clocks are unrelated.

But 8 hours is not the number most admins actually experience, and it is worth being precise because the difference changes how you set expectations. That 8-hour figure is the documented interval for the IME checking for new or updated installations generally. Required apps are handled on a shorter timer: Microsoft MVP Rudy Ooms, investigating IME build 1.106.102.0 for this very release, found that "the required-app timer defaults to 60 minutes", that other triggers can fire sooner, and that the service can adjust the interval.

So the realistic pre-2609 picture for a required Win32 app was a wait of up to about an hour, not up to eight — with the 8-hour cycle sitting behind it as the general check-in. Either way it was a wait you could not shorten without telling someone to press Sync.

This is also why hitting Sync appears to "fix" it. A Sync from the Company Portal or from the Intune console triggers an MDM check-in and an IME check-in, so the app is discovered immediately. You were not fixing a broken deployment; you were short-circuiting a timer.

What 2609 changes

Two separate items, both in the App management section of the release.

First, push-triggered check-ins. Microsoft's wording:

"Microsoft Intune now uses push notifications for admin-initiated and service-side changes to Win32 apps. Managed devices can check in sooner after app changes, reducing delivery and refresh delays compared with waiting for normal polling intervals."

Read the qualifiers carefully. It says can check in sooner, and it covers admin-initiated and service-side changes to Win32 apps — not every kind of IME payload. No timer is removed; a faster trigger is added alongside them.

Second, the post-ESP assignment check:

"After the Windows enrollment status page (ESP) or Windows Autopilot device preparation finishes, the IME immediately checks for new Windows app assignments. This behavior reduces the delay before required Win32 apps that weren't installed during provisioning begin to install."

Note that this one explicitly covers Windows Autopilot device preparation as well as classic ESP. If you have migrated to APDP, you get this too.

The real-time channel doing the work

"Push notifications" is doing some heavy lifting in that release note, and it is worth knowing which channel is involved, because it determines what you have to unblock.

Two things in Microsoft's documentation give it away.

The first is the IME's own log list, which includes a log file dedicated to exactly this: NotificationInfra.log, described as tracking "notifications sent through the Microsoft real-time communication channel."

The second is the network requirements page. Under Network requirements for PowerShell scripts and Win32 apps, alongside the familiar imeswd* content endpoints, Microsoft lists a per-region trouter endpoint:

trouter is Microsoft's real-time notification transport — the same family of endpoints Teams uses for live signalling. That is the channel a push-triggered check-in rides on.

Independent hands-on investigation confirms it and names the layer above it. Rudy Ooms captured the traffic during a real deployment and reports that IC3 — Microsoft's real-time communication service — "delivers the notification over the IME's configured Trouter connection", observing the arriving notification as a DirectSync with NotificationIntent value 2, preceded in the log by a PushNotification workload thread start entry. So: IC3 is the service, Trouter is the pipe, and the FQDN above is what your firewall has to let through.

Separately, Windows Push Notification Services (WNS) remains a documented IME dependency. Microsoft lists a missing WNS path as a direct cause of the IME failing to check in at all:

How to verify: the agent, the channel, and the log that proves it

Before changing anything, confirm what your devices are actually running.

1. Confirm the IME version floor

Microsoft sets a hard minimum, and it is stricter than most admins realise:

"Devices must run Intune Management Extension version 1.58.103.0 or later. Devices on earlier versions don't receive configurations or updates that depend on the Intune Management Extension, including Win32 app deployments, PowerShell scripts, remediations, and platform scripts."

Not "some features degrade" — they do not receive Win32 apps or scripts at all. The IME self-updates, so most devices are fine, but a device that has been offline or has a broken sync path can sit below the floor indefinitely.

This checks the installed agent version and the service state on a single device. Run it in an elevated PowerShell session.

# The IME agent binary. The service name is IntuneManagementExtension.
$exe = 'C:\Program Files (x86)\Microsoft Intune Management Extension\Microsoft.Management.Services.IntuneWindowsAgent.exe'

if (-not (Test-Path $exe)) {
    Write-Warning 'IME is not installed. Assign a Win32 app or PowerShell script to trigger install.'
    return
}

$ver = (Get-Item $exe).VersionInfo.FileVersion
$svc = Get-Service IntuneManagementExtension -ErrorAction SilentlyContinue

[pscustomobject]@{
    IMEVersion    = $ver
    MeetsFloor    = [version]$ver -ge [version]'1.58.103.0'
    ServiceStatus = $svc.Status
    StartType     = $svc.StartType
} | Format-List

Here is what a healthy device looks like. MeetsFloor must be True, and the service must be Running with StartType: Automatic.

IMEVersion    : 1.90.104.0
MeetsFloor    : True
ServiceStatus : Running
StartType     : Automatic

2. The IME log catalog

This is the reference table worth bookmarking. All of these live in one directory, and you read them with CMTrace rather than Notepad — they are CMTrace-format logs and are close to unreadable otherwise.

3. Look at the log directory on a device

Open the directory and you will see the set above. This is what it looks like on a device that has the real-time channel working — note NotificationInfra.log present and recently written.

4. Test the network path properly

Rather than guessing at firewall rules, Microsoft publishes a connectivity test script that checks DNS resolution, outbound TCP on 80 and 443 to the Azure Front Door ranges, and HTTPS reachability of the Intune service.

The important part is running it as SYSTEM, because that is the context the IME actually runs in. A test that passes as your signed-in user proves very little.

# Run as SYSTEM - the context the IME uses. PsExec from Sysinternals.
.\psexec.exe -accepteula -i -s powershell.exe

# In the new SYSTEM window, from the folder holding the script:
.\Test-IntuneAFDConnectivity.ps1 -LogLevel Detailed -OutputPath 'C:\Logs' -Verbose

# Then check the regional real-time channel by hand. Swap the FQDN
# for your tenant region: go-amer / go-eu / go-apac.
Test-NetConnection 'go-eu.trouter.communications.svc.cloud.microsoft' -Port 443 |
    Select-Object ComputerName, TcpTestSucceeded

Find your tenant region in the Intune admin center under Tenant administration › Tenant details › Tenant location. It reads as something like Europe 0202; the region word is what picks your row in the table above.

The fix: four changes to make for 2609

Step 1 — Clear the network path for push

This is the only item that needs action before the feature can help you. Three separate requirements, all easy to get wrong.

1. Allow your region's go-*.trouter.communications.svc.cloud.microsoft endpoint on TCP 443.
2. Allow the WNS endpoints: *.notify.windows.com and *.wns.windows.com on TCP 443.
3. Allow HTTP partial response on your proxy. Microsoft states this outright for the Scripts and Win32 Apps endpoints — without it, content download breaks even when the notification arrives.

Step 2 — Check the IME version floor across the fleet

One device tells you nothing about 10,000. Use the single-device check from the previous section as the detection logic for a fleet-wide remediation, or query it through your existing reporting. What you are looking for is any device below 1.58.103.0, because those devices are not receiving Win32 apps or scripts at all — with or without 2609.

Step 3 — Deploy Defender AI agent runtime protection, in Audit first

This is the most interesting item in 2609 if your developers use AI coding agents, and it is worth being precise about what it does.

Local AI agents run with the signed-in user's privileges. They read files, fetch web pages and invoke tools, and they cannot reliably separate content they are meant to act on from instructions hidden inside that content. That is prompt injection, and it is the specific threat this protects against. We covered the Defender side of this when discovery and runtime protection first appeared in June; what 2609 adds is the Intune profile to configure it at scale.

Microsoft's own worked example: a coding agent fetches project documentation to answer a question. The page contains hidden text telling the agent to read the local .env file and post its contents to an external URL. The agent treats that as part of the page and is about to comply — and Defender detects the injection in the tool response and blocks it before anything leaves the device.

Defender inspects three points in the agent loop: the user prompt, the pre-tool call, and the post-tool response.

Supported agents, as documented:

Now the configuration. The new profile covers agent-native event inspection only. Here are the exact console steps:

1. Sign in to the Microsoft Intune admin center.
2. Go to Endpoint security › Manage › Antivirus.
3. Select Create policy.
4. Set Platform to Windows.
5. Set Profile to Microsoft Defender AI agent runtime protection.
6. On the Configuration settings page, set Ai Agent Protection to Audit.
7. Complete the wizard and assign it to a limited device group where supported agents are actively used.
8. Monitor alerts for one to two weeks, classify any inaccurate detections as false positives, then change the setting to Block when you are satisfied.

The three values, and what each one actually does:

To configure a single device locally, or to test before you deploy, the same settings are exposed as Defender preferences. Verify your signature version first — Microsoft requires 1.451.224.0 or later.

# 1. Signature version must be 1.451.224.0 or later.
Get-MpComputerStatus | Select-Object AntivirusSignatureVersion

# 2. Agent-native event inspection (the Intune profile sets this one).
Set-MpPreference -AiAgentProtection Audit

# 3. Network inspection - NOT covered by the Intune profile.
#    Deploy this via a platform script, run in SYSTEM context.
Set-MpPreference -AiAgentNetworkInspection Audit

# 4. Confirm both. Valid modes: Disabled, Audit, Block.
Get-MpPreference | Select-Object AiAgentProtection, AiAgentNetworkInspection

To deploy network inspection at scale, wrap Set-MpPreference -AiAgentNetworkInspection Audit in a platform script and set Run this script using the logged on credentials to No — it needs SYSTEM context to change Defender preferences. Remember that Intune runs a platform script once; it runs again only if you change the script or its policy, so switching Audit to Block means editing the script, not re-assigning it.

Licensing, because it is not included everywhere: you need Defender for Endpoint Plan 2, Microsoft 365 E5, Microsoft Agent 365 or Microsoft 365 E7. Devices must be onboarded to Defender for Endpoint with Microsoft Defender Antivirus in active mode and real-time protection on. To create the policy in Intune you need a role with device configuration permissions, such as Policy and Profile Manager.

One genuinely useful detail: the setting is protected by tamper protection, so a local user cannot quietly turn it off.

Step 4 — Accept that the old device page is gone

This one needs no configuration, only expectation management. The two-release sequence matters:

If any of your runbooks, training material or screenshots still show the old device page, they are now wrong. So is any instruction that tells an engineer to flip the toggle back. Search your documentation for that toggle name and remove it.

Proof it worked

Four checks, one per change.

Push delivery. Assign a small required Win32 app to a single online test device and do not press Sync. Watch NotificationInfra.log, then IntuneManagementExtension.log, then AppWorkload.log in CMTrace. A working push shows a notification arriving on the real-time channel, followed by the agent requesting policy and the app workload starting — minutes after the assignment, not hours. If the app arrives but only after a long gap with nothing in NotificationInfra.log, you fell back to the ordinary timer and your network path is still blocked.

The exact strings to search for, so you are not reading the whole log:

Compare the DirectSync timestamp with the Win32AppWorkload completion timestamp. That gap, not the release notes, is your environment’s real number — and it is the figure to quote internally rather than anything you read in a blog post, including this one.

Post-ESP delivery. Provision a test device through Autopilot or APDP with a required Win32 app that is not set to block ESP. Previously that app waited for the next IME poll. It should now begin installing as soon as ESP completes.

IME version. The single-device script returns MeetsFloor: True and a Running / Automatic service, and your fleet report shows no device below 1.58.103.0.

Defender AI protection. Confirm the effective value rather than trusting the policy status, then trigger a real detection:

1. In the Microsoft Defender portal, open the device page.
2. On the Configuration management tab, select Effective settings.
3. Find Ai Agent Protection and confirm both its value and its configuration source.
4. Close every terminal window used for agents, then open a fresh one.
5. Run Microsoft's AI agent runtime protection demonstration, which uses a benign test string, and confirm a detection appears.

A successful detection raises a Suspicious AI prompt injection alert. In Audit mode it arrives as Informational, so your SOC can see what would have been blocked without triaging it as a live incident. Users can also see detections locally under Windows Security › Virus & threat protection › Current threats and in Protection history.

References

• What's new in Microsoft Intune — Week of September 28, 2026 (Service release 2609)
• Understand Microsoft Intune Management Extension — the 8-hour interval, the 1.58.103.0 version floor, the log catalog, post-ESP behaviour
• Network endpoints for Microsoft Intune — the regional trouter endpoints, WNS dependencies, HTTP partial response
• AI agent runtime protection with Microsoft Defender for Endpoint (Preview) — what it detects, supported agents, inspection approaches
• Set up AI agent runtime protection with Microsoft Defender for Endpoint (Preview) — the Intune profile, exact values, prerequisites, phased rollout
• Service information for Microsoft Intune release updates — how gradual rollout works
• CMTrace — the log viewer for IME logs

Microsoft MVP community deep-dives