Forum Discussion
[IME 1.106.151.0] Win32 app RequiredUninstall intent not refreshed until restart IME service
we changed assignment intent from Required to Uninstall for win32 app. However, AppActionProcessor.log continuously evaluates the app with the old target intent:RequiredInstall. It never enters the uninstall evaluation workflow during normal periodic check-ins, even after waiting for the default IME check-in cycle and triggering sync from Access work or school. Only after restarting the IntuneManagementExtension service will the IME process reload the payload, and AppActionProcessor.log finally show targeted intent:RequiredUninstall, then proceed to evaluating uninstall enforcement actions.
2 Replies
Your uninstall assignment is reaching the device only after restarting IME, while normal processing retains RequiredInstall. That identifies a reproducible refresh problem, but it does not by itself establish a confirmed defect in version 1.106.151.0.
One detail worth correcting: Microsoft’s current IME documentation says that Sync from Windows Settings or the Intune admin center initiates both MDM and IME check-ins. Company Portal > Settings > Sync is another documented trigger. The regular IME interval is eight hours.
On one affected test device, record the assignment change time, trigger Company Portal sync, and compare IntuneManagementExtension.log for the check-in and policy request with AppWorkload.log and AppActionProcessor.log for the same app. Then capture the corresponding entries after restarting IME.
If a successful policy refresh still retains the old intent until restart, provide that before-and-after evidence to Microsoft support. Avoid treating repeated fleet-wide service restarts as a confirmed permanent fix.
- WinEndpointOpsBrass Contributor
That matches what the IME does with its cached app state. The Win32 payload is reloaded when the service picks up a new policy cycle, and a sync from Access work or school only wakes the device up, it does not always make the extension re-read the assignment. Restarting IntuneManagementExtension forcing the reload is consistent with that.
A few things to check before treating it as a bug. Confirm the Required assignment was removed or changed in place, not left alongside a new Uninstall assignment for the same group or a nested group, because overlapping assignments can leave the old intent in the evaluation. Check AppWorkload.log as well as AppActionProcessor.log, and compare the timestamps of the last policy download with the time you changed the intent. If the payload really is not downloaded for hours after the change, that points at the service, not at your assignment.
For a workaround at scale, Restart-Service IntuneManagementExtension is safe to run, and you can push it as a one-off remediation or platform script. If you want it live on a few chosen devices without waiting for a check-in, a Windows remote management tool can run the same command now. I work on one of those, TFalke, so I am biased: it is Windows only and an operator approves each command. A plain remediation script covers the same need if you would rather stay inside Intune.
It would also be worth opening a support case with the IME logs attached, since needing a restart on 1.106.151.0 looks like a regression and Microsoft can only fix it if it is reported.