📱 Recipe · Intune & Device Management
Audit a Slow Windows Device via Intune and Apply Safe Remediations
Investigate a user's slow computer end-to-end: check device health, compliance, policies, apps, and storage — then trigger a sync and remote reboot as first-line remediation.
Complexity
Intermediate
Impact
endpoint-health + user-support + device-compliance + remote-remediation
Context
Why This Matters
"My computer is slow" is one of the most common helpdesk tickets — and one of the easiest to misdiagnose without data. Before you remote-control a user's machine or schedule a reimage, you can answer most of the diagnostic questions from Intune in under two minutes: when did the device last check in, is it compliant, are policies applying cleanly, is storage exhausted, is there malware, and what's installed?
This recipe walks through a structured audit of a single user's Windows device using Intune / Microsoft Graph, then applies two safe, non-destructive remediations — a device sync (to force policy re-evaluation) and a remote reboot (to clear memory, restart services, and apply pending updates). Run this as your standard first response to any performance complaint before escalating to hands-on troubleshooting.
Expected Outcomes
After running this recipe you will have:
- The user's device identity in Intune (device ID, name, enrollment type, ownership)
- Compliance state and per-policy evaluation results (including any errored policies)
- Configuration profile assignment status
- Storage utilization, encryption state, and malware counts
- A list of installed/detected applications
- Last check-in timestamp (to detect stale or offline devices)
- A triggered device sync so the endpoint picks up latest policy
- A triggered remote reboot to clear transient performance issues
- A structured finding report you can hand back to the user or paste into your ticket
Risks & Considerations
Warnings and gotchas
- Remote reboot is immediate. The
rebootNowaction gives the user only a short warning. Confirm with the user first, or at minimum notify them, before triggering it — they may lose unsaved work. - Compliance state vs. policy state are different things. A device can report as "compliant" overall while an individual policy is in an "error" state (common with the Default Device Compliance Policy). Always check
deviceCompliancePolicyStates, not just the top-levelcomplianceStatefield. - Virtual machines often report 0 physical memory. Don't mistake this for a hardware fault — VMware/Hyper-V guests frequently don't expose physical memory to Intune. If the device is a VM, check the hypervisor host's resource allocation before assuming a guest-side problem.
- $filter has limits on managedDevices. The Intune Graph endpoint does not support
$filteronuserIdor some property combinations. UseuserPrincipalName eq '...'for reliable filtering. - Sync is not instant. The sync action queues a check-in request; actual completion depends on the device being online and responsive. Allow 5–15 minutes before re-auditing.
- Don't reimage on the first report. Always capture the audit data first — it's what lets you distinguish a policy problem from a hardware problem from a user-behavior problem.
Required Permissions
| Permission | Why It's Needed |
|---|---|
| User.Read.All | Look up the user's account from display name or UPN |
| DeviceManagementManagedDevices.Read.All | Read managed device properties, compliance states, configuration states, and detected apps |
| DeviceManagementManagedDevices.PrivilegedOperations.All | Trigger remote actions such as syncDevice and rebootNow |
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 Pro
For End Users
How an employee would ask Dex for help
Audit and remediate via the Intune admin center
1. Open the device record
- Go to .
- Search for the user's name or the device name. Click the device to open its overview blade.
2. Review the Overview tab
- Compliance — should read Compliant. If not, note the reason.
- Last check-in — anything older than ~24 hours suggests the device is offline or the MDM agent is stuck.
- Primary user — confirm it matches the reporting user.
- Storage — check free vs. total. Below ~10% free can directly cause slowness.
3. Drill into policy health
- In the device blade, open — confirm each assigned policy shows Compliant, not Error or Conflict.
- Open — check each profile's state. Errors here often indicate settings that can't apply on the device (e.g., missing hardware, wrong OS version).
- Open and — scan for unexpected or resource-heavy software.
4. Trigger a sync
- On the device overview toolbar, click Sync.
- Confirm the action. Intune queues a check-in request to the device.
5. Trigger a reboot (if appropriate)
- Notify the user first to prevent data loss.
- On the toolbar, click Restart (or More → Restart).
- Confirm. The device restarts within a few minutes.
6. Report findings
Paste key fields — compliance state, last sync, storage, any errored policies, remediation actions taken — into the ticket.
Audit and remediate via Microsoft Graph
1. Resolve the user
GET https://graph.microsoft.com/v1.0/users?$filter=startswith(displayName,'{firstName}') or startswith(userPrincipalName,'{upnPrefix}')&$select=id,displayName,userPrincipalNameCapture the user's id and userPrincipalName.
2. List the user's managed devices
Important: The managedDevices endpoint does not support $filter on userId. Filter on userPrincipalName instead:
GET https://graph.microsoft.com/beta/deviceManagement/managedDevices?$filter=userPrincipalName eq '{upn}'Key response fields to capture: id, deviceName, operatingSystem, osVersion, complianceState, lastSyncDateTime, enrolledDateTime, model, manufacturer, totalStorageSpaceInBytes, freeStorageSpaceInBytes, isEncrypted, windowsActiveMalwareCount, joinType.
3. Get per-policy compliance state
GET https://graph.microsoft.com/beta/deviceManagement/managedDevices/{deviceId}/deviceCompliancePolicyStatesLook for any entry with "state": "error" or "nonCompliant".
4. Get configuration profile state
GET https://graph.microsoft.com/beta/deviceManagement/managedDevices/{deviceId}/deviceConfigurationStates5. List detected apps
GET https://graph.microsoft.com/beta/deviceManagement/managedDevices/{deviceId}/detectedApps?$top=50Page through with $skip if @odata.count exceeds 50.
6. Trigger a device sync
POST https://graph.microsoft.com/beta/deviceManagement/managedDevices/{deviceId}/syncDeviceReturns 204 No Content on success.
7. Trigger a remote reboot
POST https://graph.microsoft.com/beta/deviceManagement/managedDevices/{deviceId}/rebootNowReturns 204 No Content. The device will restart shortly after.
Automate with PowerShell + Microsoft.Graph
The downloadable script below takes a user identifier (UPN or display name), runs the full audit, and optionally triggers sync and/or reboot. It's designed to be safe to run read-only by default — remediation actions require explicit switches.
Prerequisites
- PowerShell 7+
Microsoft.Graphmodule:Install-Module Microsoft.Graph -Scope CurrentUser- Sign in with:
Connect-MgGraph -Scopes 'User.Read.All','DeviceManagementManagedDevices.Read.All','DeviceManagementManagedDevices.PrivilegedOperations.All'
Typical usage
# Read-only audit
.\Invoke-IntuneDeviceAudit.ps1 -User 'AlexW@contoso.com'
# Audit + trigger sync
.\Invoke-IntuneDeviceAudit.ps1 -User 'AlexW@contoso.com' -Sync
# Audit + sync + reboot (after user notification)
.\Invoke-IntuneDeviceAudit.ps1 -User 'AlexW@contoso.com' -Sync -RebootWhat it does
- Resolves the user by UPN or display name.
- Fetches all managed devices for that user.
- For each Windows device: pulls compliance policy states, configuration states, detected apps, and storage info.
- Prints a formatted report with health flags (errored policies, low storage, stale check-in, no encryption).
- If
-Syncis specified, callssyncDevice. - If
-Rebootis specified, prompts for confirmation then callsrebootNow.
Next steps