Intune Win32 App Push Notifications Delayed: Check WNS Before Repackaging

An Intune Win32 app assignment changed, but the Windows device has not started downloading it. If the package works elsewhere, rebuilding the .intunewin file is usually the wrong first move. The delay may be before the Intune Management Extension (IME) evaluates the app at all.

Microsoft’s October 2026 Intune update says service-side and admin-initiated Win32 app changes use push notifications so managed devices can check in sooner. That improves responsiveness; it does not guarantee an immediate install. The device must be online, able to receive its notification, correctly targeted, and then able to download and evaluate the app.

Quick triage

Confirm whether the assignment is Required or Available. Microsoft notes that adding an app as Available does not trigger an immediate device notification.
Verify the affected device or user is in the assigned group and passes any assignment filter and app requirements.
Confirm the device is online and can reach Windows Push Notification Services (WNS) over TCP 443.
From the device, initiate an Intune sync and note the time. Allow for policy processing and portal reporting delay.
Check IntuneManagementExtension.log for check-in and policy processing, then AppWorkload.log for app deployment activity.
If the app reaches IME but does not download, test the Win32 content endpoints for your tenant region. Only investigate install commands and detection after logs show an install attempt.

Understand which delay you have

“Push notification failed” is often used as a catch-all for several different stages. Separate them before changing policy:

No policy change or wrong target: Check assignment intent, group membership, filter mode, and device applicability.
Change made, but device has not synced: Check device connectivity and WNS; then force one controlled sync.
Policy reaches the device, but app is absent from IME activity: Recheck assignment eligibility and whether the app is Available rather than Required.
IME records the app and starts processing: Continue with content download, requirement rules, install context, exit code, and detection.
Device completed work but portal remains stale: Compare local logs with Intune reporting; the portal can lag behind the device.

This boundary check prevents packaging changes from masking a network or targeting fault.

Check the Windows push path

Microsoft lists these WNS endpoints for Intune-managed Windows devices:

*.notify.windows.com
*.wns.windows.com
sinwns1011421.wns.windows.com
sin.notify.windows.com
TCP 443

Have the network team verify that the device can establish outbound TLS connections to the required WNS destinations through the organization’s firewall or proxy. Do not assume that general web browsing proves WNS is reachable: proxy authentication, TLS inspection, or endpoint allowlists can affect notification traffic differently.

WNS is used for device actions and other immediate activities. When a device is offline or disconnected, it may not receive a notification until its next sync. Microsoft also says change-based notification timing can vary from immediately to a few hours, and reports may take longer to reflect the device’s latest status. Treat a short delay as a timing clue, not proof of a broken app.

Run a controlled sync and capture evidence

In the Intune admin center, open the affected device and select Sync. On the endpoint, you can also start a sync from Settings > Accounts > Access work or school > connected work account > Info > Sync. Record the time and keep the test to one device before changing a broad assignment.

Review the IME logs here:

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs

Start with IntuneManagementExtension.log to see check-ins, policy requests, processing, and reporting. Then use AppWorkload.log for Win32 app deployment activity. Search for the app name, app ID, or a unique policy string around the sync time. If no app-specific activity appears, do not jump to the installer: the device may not have received or qualified for the assignment.

If IME begins a content download but it stalls or errors, verify the additional tenant-region endpoints documented under Network requirements for PowerShell scripts and Win32 apps in Microsoft’s Intune endpoint list. Those content endpoints are distinct from WNS. A successful WNS connection does not prove the app content CDN is reachable, and a content CDN issue does not explain a missing policy check-in.

Why an Available assignment behaves differently

An Available app is offered to users in Company Portal. Microsoft explicitly notes that adding an app as Available does not cause an immediate notification to devices. Do not use a newly added Available app as your test for the faster push behavior described for Win32 app changes.

For an urgent deployment, confirm the intended assignment type and audience first. Changing Available to Required has user-impact and deployment consequences, so do not do that solely to test WNS. Use a small pilot assignment with the approved intent, then confirm the resulting policy and app activity.

When to troubleshoot the package

Move downstream only after AppWorkload.log shows that the device processed the app. Then check:

requirement rules and applicability;
content download and cache activity;
install command and silent switches;
System versus user install context;
installer exit-code mapping;
detection rule path, registry hive, and 32-bit/64-bit view.

If the app has no attempt in IME, these installer settings cannot explain the absence. For deeper branches, see Intune Win32 app assignment filters, IME and AppWorkload log reading, and Win32 app detection error 0x87D1041C.

Prevent repeat incidents

Include WNS destinations in Windows endpoint allowlist reviews and validate them from representative network segments.
Keep WNS notification connectivity separate from Win32 content-CDN connectivity in network tests.
Record whether an app is Required or Available when triaging delayed delivery.
Capture the assignment change time, device sync time, IME policy-processing time, and first app-processing event.
Use one test device to distinguish targeting, notification, policy, content, and installer stages before broad remediation.
Avoid repackaging until client logs establish an install-stage failure.

Intune Win32 App Push Notifications Delayed: Check WNS Before Repackaging

The Win32 Deployment Doctor