๐Ÿ“ฑ Recipe ยท Intune & Device Management

Audit an Intune-Managed Device and Trigger a Remote Sync

Diagnose device health, compliance, and check-in status, then force a policy refresh to remediate common issues

Complexity

Intermediate

Impact

device-support + endpoint-management + user-productivity + low-risk

Context

Why This Matters

When a user reports a performance issue, connectivity problem, or that a policy or app isn't applying correctly, the first step is almost always to audit the device's current state in Intune and force a check-in. A device that hasn't synced recently may be running stale policies, missing app assignments, or reporting outdated compliance โ€” all of which can manifest as slowness, login errors, or failed installs.

This recipe walks through the standard triage workflow: resolve the user, enumerate their managed devices, inspect health (storage, compliance, last sync, configuration profile state), and trigger a remote sync. It's a safe, non-destructive first-response procedure that resolves a surprising number of tickets on its own and produces the diagnostic data needed to escalate the rest.

Expected Outcomes

  • A clear snapshot of the user's device: OS, model, storage, compliance state, and last check-in time
  • Visibility into which compliance policies and configuration profiles are applied โ€” and which are in an error state
  • A remote sync command delivered to the device to refresh policies and update Intune reporting
  • Documented findings you can share with the user or attach to the ticket
  • A decision point: sync resolved it, or escalate to reboot / deeper investigation

Risks & Considerations

Safe operations (low risk)

  • Sync is non-destructive โ€” it just forces the MDM client to check in. Safe to run any time.
  • Read operations on managedDevices and compliance states are always safe.

Watch out for

  • Beta endpoints: This recipe uses /beta for richer device metadata. Beta APIs can change without notice; for production automation prefer /v1.0 where the fields you need are available.
  • Invalid $select fields: Field availability differs between /v1.0 and /beta and across OS types. If a $select returns HTTP 400, drop the offending field and retry.
  • Compliance "error" state: Often a reporting lag rather than a real failure. Always sync first and re-check before declaring the device non-compliant.
  • Reboot vs sync: A reboot disrupts the user's session. Only escalate to a remote reboot after sync fails and the user agrees.
  • User Experience Analytics: The userExperienceAnalyticsDevicePerformance endpoint requires the UXA feature to be enabled and licensed; expect 400s in tenants without it.

Required Permissions

PermissionWhy It's Needed
User.Read.AllResolve the reporting user's account by name or UPN
DeviceManagementManagedDevices.Read.AllRead device inventory, compliance state, and last check-in data
DeviceManagementManagedDevices.PrivilegedOperations.AllTrigger remote sync (and reboot, if escalated)
DeviceManagementConfiguration.Read.AllRead device configuration and compliance policy states

The fastest way to get this done โ€” just ask Dex. Copy the prompt below and paste it into your Dex conversation.

For IT Admins

Paste into Dex CoAdmin

{user} reports their computer is slow. Audit their Intune-managed device (compliance, last check-in, storage, policy/config state), trigger a remote sync to refresh policies, and report findings with a recommended next step.
Try in Dex CoAdmin

For End Users

How an employee would ask Dex for help

My work laptop has been really slow today โ€” can you take a look?
Try in Dex Playground