Forum Discussion
Intune On-Demand Proactive Remediation API Reliability for Large-Scale Usage
Hi Team, We are testing the Intune On-Demand Proactive Remediation API: POST /deviceManagement/managedDevices/{managedDeviceId}/initiateOnDemandProactiveRemediation In our environment, the remed...
We've seen the same pattern. As far as I understand it, the on-demand call doesn't run anything directly: it sends a push notification asking the Intune Management Extension to check in, and that push is best effort. If the device is asleep, on a flaky network, or the IME is busy, the nudge can simply be missed, so a 30-second gap between calls won't change much.
What has worked for us in practice:
- Treat the API as "request", not "guaranteed delivery". Record the request time per device.
- Verify through the run state, not the 202 response. Poll deviceManagement/deviceHealthScripts/{scriptId}/deviceRunStates and compare lastStateUpdateDateTime with your request time.
- If nothing has changed after a timeout you're comfortable with (we use about 15 minutes), send the request again, up to a couple of retries.
- Respect Graph throttling: handle 429s and honour the Retry-After header rather than a fixed delay.
- On a device that keeps missing, IntuneManagementExtension.log and HealthScripts.log under C:\ProgramData\Microsoft\IntuneManagementExtension\Logs usually show whether the request arrived at all.
Since it's still beta there's no SLA behind it, so I'd only build a large-scale workflow on it with the verify-and-retry loop in place.