Start by identifying whether an Intune problem is affecting a tenant, user, device, policy, app, or service. Then check service health, confirm the user and device are correctly targeted, inspect deployment status, request a sync, and collect device logs if the result remains unclear. This sequence helps isolate the failure without jumping straight to deleting policies or resetting a device.
First, identify where the failure occurs
Intune management is a chain: an assignment targets a user or device, the device checks in, the setting or app is processed, and the user experiences the result. Find the stage that is failing before changing configuration.
| Symptom | First area to inspect |
|---|---|
| Device cannot enroll | Licensing, enrollment restrictions, identity, and enrollment diagnostics |
| Policy is not applied | Assignment scope, group membership, filters, and last check-in |
| Configuration profile reports an error or conflict | Per-setting status, overlapping policies, and OS support |
| App is missing or installation failed | Assignment type, requirements, dependencies, detection rules, and app logs |
| Device is marked noncompliant | Compliance-policy results and device health |
| Remote action is pending | Device connectivity, last check-in, and action history |
| Many unrelated devices fail at once | Service health and recent tenant or network changes |
Also note whether the problem affects one user, one device, one platform, or many users and devices. That scope is often the quickest clue to whether the cause is local or tenant-wide.
Check Intune and Microsoft 365 service health
In the Intune admin center, open Tenant administration → Tenant status → Service health. Also check the Microsoft 365 admin center’s Service health dashboard and the Message center for active or recently resolved incidents. The troubleshooting starting points and user-level checks are also outlined in HTMD’s Intune troubleshooting guide.
#1 Best Overall
- If many users or devices began failing at about the same time, compare the incident’s platform, region, and affected services with your symptoms.
- Record any relevant incident ID and its status. If an active incident matches, avoid unrelated policy changes while the service issue is being addressed.
- If only one device is affected, continue with its enrollment, connectivity, identity, and local logs rather than assuming a service outage.
Service health is a lead, not proof: an incident can be limited by region or service and may not explain every symptom.
Use the user troubleshooting view
In the Intune admin center, go to Troubleshooting + support → Troubleshoot and search for the affected user. The available information depends on your permissions, platform, enrollment type, and available telemetry. If labels differ in your tenant, use the admin center’s search.
- Select the correct user account and verify that it is the account used on the affected device.
- Confirm the affected device appears in the user’s results.
- Review the user’s license, group memberships, compliance state, assigned apps, configuration profiles, compliance policies, and app-protection information where available.
- Open the relevant policy or app to inspect its assignment and device-level or setting-level status.
This view helps connect a user to their managed devices and assignments; it does not by itself prove that a device received or successfully applied every setting.
Verify licensing, groups, and assignment scope
Check that the correct work or school account has an eligible Intune entitlement, and that the user is signing in with that identity. A valid license is necessary in applicable scenarios, but it does not guarantee successful enrollment or deployment. See Microsoft’s Intune licensing documentation for licensing details.
Free tools Windows power users keep installed
One-click scans. No signup required.
- Confirm the actual Entra ID user or device object is in the intended group. Check dynamic membership and allow for membership processing rather than assuming a change is immediate.
- Review whether the assignment targets users, devices, or both, and whether the policy or app supports that target.
- Check included and excluded groups, assignment filters, platform and OS conditions, ownership conditions, and any other targeting criteria.
- Confirm the device is associated with the intended user and object. A deleted and recreated device can leave assignments aimed at an old object.
Seeing a user in a group is not enough: the assignment must target that group, the user or device must not be excluded, and the target must satisfy the assignment’s conditions.
Inspect the device record and check-in time
Open the affected device in Intune and verify its name, operating system and version, ownership, primary user, management state, join or registration type, enrollment date, compliance state, and action history. Check whether there are duplicate, stale, deleted, or recently re-enrolled records.
- An old last check-in can explain why a new assignment has not reached the device.
- A recent check-in does not establish that every policy or app succeeded.
- A compliant state does not mean every configuration profile is applied.
- A device can appear in the portal even when its local management enrollment is damaged.
Interpret configuration-profile status
For a profile, open Devices → Configuration profiles, select it, and review Device status and, where available, Per-setting status. These views help distinguish a targeting problem from a setting-level failure. The reported labels and detail available can vary by profile type and portal version.
| Status | What to check next |
|---|---|
| Succeeded | Confirm the intended user or device received the setting. If the behavior is still absent, check for an overriding policy or local configuration, and whether a restart, sign-out, or app restart is needed. |
| Error | Open the affected setting, capture its error code, and check platform and OS support, policy overlap, permissions, and device-side MDM logs. |
| Conflict | Find other profiles configuring the same setting, including security baselines, settings catalog profiles, and administrative templates. Decide which policy should govern, then consolidate or adjust assignments rather than deleting policies at random. |
| Not applicable | Check platform, OS version and edition, assignment filter, user-versus-device targeting, and whether the setting is supported on that device. |
A profile-level result can hide a problem in one setting. Use the most specific status available before changing the whole profile.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Rank #3
Request a sync, then check whether it arrived
A sync is a reasonable low-risk step after changing an assignment or policy, when a device has not checked in recently, or when a remote action is pending. You can initiate it from the device’s Intune record or use the organization’s Company Portal sync option; the exact device-side route varies by platform.
- Confirm the device is powered on, online, and enrolled under the expected work or school identity.
- Request a sync from Intune or Company Portal.
- Allow time for the device to contact Microsoft management services and process the request.
- Refresh the device record and relevant policy or app status. Check whether the last check-in advanced and whether the specific result changed.
A sync cannot correct a wrong assignment, missing eligibility, unsupported setting, policy conflict, broken enrollment, app detection error, or Conditional Access configuration. If the last check-in does not advance, investigate network or proxy access, device identity, enrollment health, and the management components for that platform.
Troubleshoot app deployment as its own path
Policy status and application installation status are different problems. First establish whether the app is assigned as Required or Available: an available app may need the user to install it from Company Portal. Then check whether the assignment is user- or device-targeted and whether the device meets its requirements.
- Review requirements, dependencies, supersedence, and the intended installation context.
- For Win32 apps, inspect the install and uninstall commands, return-code handling, detection rule, architecture, and OS requirements.
- If the app appears installed but Intune reports failure, verify that the detection rule matches the actual installation. An installer exit code of zero alone does not prove Intune will detect success.
- Check whether an existing installation, user permissions, licensing, store availability, or device restrictions explain the result.
For Windows Win32 deployment, use Microsoft’s Win32 app troubleshooting guidance and collect the relevant Intune Management Extension logs. Do not assume a package rebuild is necessary before checking detection and requirements.
Recommended Free Tools
Separate compliance from configuration and Conditional Access
A configuration profile sets or manages device behavior; a compliance policy evaluates whether the device meets specified conditions; Conditional Access uses identity and device signals to control access. App-protection policy status is another distinct area. A change in one does not automatically repair the others.
For a noncompliant device, open the compliance policy’s results and identify the exact unmet condition. Common areas to investigate include encryption, password or PIN requirements, antivirus or firewall state, minimum OS version, jailbreak or root detection, threat-level integrations, evaluation timing, exclusions, and stale check-in. Use Intune’s compliance-policy monitoring documentation to interpret the available reporting.
If the device appears compliant in Intune but access is blocked, inspect the relevant Conditional Access policy and device identity signals rather than changing a configuration profile blindly.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Collect evidence before disruptive fixes
Capture evidence while the failure is present. Portal status can show assignment and service-side results; device logs are often needed to investigate local enrollment, connectivity, or installation behavior.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →- User principal name, device name, Intune device ID, and Entra object ID.
- Policy or app name, assignment group, targeting type, and relevant filter or exclusion.
- Operating system and version, enrollment type, ownership, and last check-in.
- Exact status, error code, screenshots, and timestamps with time zone.
- Company Portal diagnostics, Windows MDM diagnostic report, relevant Event Viewer records, or platform-specific management logs.
- For Win32 apps and scripts, relevant Intune Management Extension logs and installation details.
Microsoft provides guidance for Windows MDM policy failures and Intune device-enrollment troubleshooting. Follow the instructions applicable to the affected OS and scenario.
Choose the next step without losing evidence
Use the least disruptive action that matches the failure. Syncing is generally a safer early check than re-enrollment. Re-enrollment can help when enrollment is damaged, but it may disrupt the user and create duplicate records. Retire, wipe, delete, or remove policies only after verifying the action, target, ownership, data impact, and recovery plan.
- For broad failures, correlate service health with recent changes to assignments, authentication, certificates, connectors, and network or proxy rules.
- For one user, focus on identity, license, membership, user-targeted assignments, and access policies.
- For one device, focus on its record, check-in, enrollment, connectivity, OS compatibility, and local logs.
- For a conflict, identify the competing settings and set a clear policy owner.
- For unexplained backend failures, widespread Conditional Access impact, data-loss risk, or a repeatable failure after basic checks, escalate internally or open a Microsoft support case with the evidence package.
Microsoft’s Intune help and support guidance describes support and help-desk resources. A case that includes IDs, timestamps, status details, and relevant logs is more actionable than a report that a policy is simply “not applying.”
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
