Intune troubleshooting usually goes wrong at the first step. Someone opens the failing policy, reads its settings, and edits them. But the policy is rarely the problem. A status of Succeeded is a statement about delivery, not about what the device is actually doing. Most wasted hours come from debugging the wrong layer: the device was never checking in, or the assignment never reached it, or Windows rejected something the portal reported as fine.
This page is the routing layer for every Intune post on this site. Find the symptom, check things in the order given, and each step links to the post that covers it in depth. Microsoft’s own Intune troubleshooting hub is organised by product area, and it is the right place for error code references. This page is organised by symptom, because that is how problems arrive. Microsoft facts quoted here were checked against Microsoft Learn on 26 September 2026. The spoke posts carry their own dated sources.
Quick symptom index
If you already know the symptom, jump straight to its section. The layer column tells you where the evidence will be.
| Symptom | Layer | Section below |
|---|---|---|
| Nothing reaches the device at all | 2 | Is the device actually talking to Intune |
| Feature missing, greyed out or refused for some users | 1 | Licence gates that look like faults |
| Policy reports Succeeded, nothing changed | 4 | The policy says Succeeded and nothing changed |
| Conflict, Error, Pending or Not applicable | 3 | The policy shows Conflict, Error or Not applicable |
| App failed, or installed but reports Failed | 3 or 4 | Apps that will not install |
| New device stuck, enrolled wrongly, or not blocked | 2 | Enrolment and Autopilot failures |
| Wi-Fi or VPN fails on managed devices | 4 | Certificates, Wi-Fi and VPN |
| Users suddenly blocked by Conditional Access | 3 | Compliance that lags |
| Security setting reports success, protection absent | 4 | Security settings that do not stick |
| Updates or drivers never arrive | 3 | Updates and drivers |
The four layers every Intune problem sits in
Every Intune fault lives in one of four layers, and each layer has its own evidence. Working from the top down, you never debug a setting on a device that was never going to receive it.
| Layer | The question | Where the evidence is |
|---|---|---|
| 1. Tenant and licence | Is the feature available to this user at all? | Tenant status, the user’s licences, add-on entitlements |
| 2. Enrolment and check-in | Is the device managed, and is it talking to Intune? | The device’s Managed and Last check-in columns |
| 3. Assignment and evaluation | Did this policy target this device, and did anything else collide with it? | Assignments, filters, per-setting status, conflicts |
| 4. Application on the device | Did Windows, macOS or the app actually apply what arrived? | Event logs, agent logs, the effective state on the device |
Microsoft’s troubleshooting policies and configuration profiles article follows the same shape for the first three layers. It says to check the tenant status and confirm the subscription is Active. It says the device’s Managed property must show MDM or EAS/MDM, because otherwise the device isn’t enrolled and receives no compliance or configuration policy. And it says devices check in every 8 hours by default, and a Last check-in older than 24 hours means there may be an issue with the device. A device that cannot check in cannot receive anything.
Start here: is the device actually talking to Intune
Before any policy question, answer three things about the device: is it managed, when did it last check in, and does a sync reach it. If the answers are not managed, more than a day ago, and no, no amount of work on the policy will help.
Do these checks in this order, because each one is cheaper than the next. The portal columns take seconds. A sync takes minutes and tells you whether the channel is open. Anything on the device itself, whether a log, a registry key or a command, costs a remote session or a site visit. An engineer who starts at the device and works back towards the portal has usually paid for the expensive evidence before collecting the free kind.
The full order for that check is in Intune device not syncing. Pressing Sync is covered in forcing an Intune sync, which also describes three problems that look exactly like a sync failure and are not. The most important point from that post is that the Sync button proves the MDM channel is working. It does not prove anything about the management extension, which runs on its own schedule.
That extension is the second channel on every Windows device, and a large share of Intune troubleshooting is really troubleshooting it. It installs only when something that needs it is assigned, removes itself when the last PowerShell script is unassigned, and logs to its own folder. All of that is in the Intune management extension. If a Win32 app, a script or a remediation is involved, check the extension before the policy.
Licence gates that look like faults
Layer 1 problems are the most frustrating to find, because a missing entitlement rarely produces an error that says so. The feature is absent, greyed out, or works for some users and not others. Before debugging any feature that is not part of base Intune, check who is licensed for it.
Several features that appear in the Intune admin centre are gated on something other than an Intune plan. Remediations are the clearest example. The Intune remediation script post sets out why the gate is a Windows entitlement, and why an Intune plan on its own does not settle the question. Device Query sits inside Advanced Analytics rather than base Intune, and its limits and licence position are in Intune Device Query limits.
Add-ons changed in July 2026. Endpoint Privilege Management and Cloud PKI both became included at no extra cost with Microsoft 365 E5, while remaining paid add-ons elsewhere, including E3. Endpoint Privilege Management cost covers the first, and the certificates section below covers the second. The practical consequence for troubleshooting is that the same feature can work for one user and fail for the next, purely because of the licence each holds.
The licence check also applies to app protection. A protected app on an unenrolled device that finds no Intune licence for its user backs off for hours before asking again. From the user’s side that looks like a policy that never applies.
The policy says Succeeded and nothing changed
This is the single most common Intune complaint, and it almost always means the fault is in layer 4. The portal reports that the device accepted the payload. It does not report whether the operating system applied it, whether something else overrode it, or whether it was ever meant to take effect straight away.
Check these in order.
- Is the setting actually applied? Read the effective state on the device, not the portal. For firewall policy this means querying the active policy store rather than the default one, as set out in why Intune firewall rules silently fail, where a single bad rule silently cancels the whole profile.
- Did a second policy set the same value? Two configuration profiles setting one value differently produce a conflict, and the rules for which one wins are different for compliance, configuration and app protection. Those rules are in Intune policy conflict.
- Is a security baseline involved? A baseline carries no special precedence. When it collides with another profile, neither value applies. Intune security baseline conflicts covers where the second profile usually comes from.
- Is the setting meant to wait? Some settings only take effect at the next sign-in, the next restart or the next scan. Kiosk configuration applies at the next sign-in of the targeted user, for example, which is one of several quiet failure patterns in Intune kiosk mode.
- Is it a legacy template? The Administrative Templates profile type is deprecated and read-only, and a half-finished migration leaves two profiles setting the same value. See settings catalog vs administrative templates.
The policy shows Conflict, Error or Not applicable
These states are more useful than Succeeded, because the portal is telling you something. Microsoft’s policy troubleshooting article defines them.
- Not applicable means the policy isn’t supported on that platform.
- Conflict means one of two things: an existing setting on the device that Intune can’t override, or two policies setting the same value differently.
- Pending means the device hasn’t checked in to get the policy, or received it but hasn’t reported back.
Conflict is a layer 3 question, so go to Intune policy conflict first. Pending is a layer 2 question, and belongs with the check-in steps above. An error with a code belongs with Microsoft’s error references, linked from their troubleshooting hub. Search the code there before searching anywhere else.
One state catches people repeatedly. A filter evaluation can show Not evaluated when the policy has a conflicting assignment on the device. Assignment filters add their own timing problems too: an app filtered on a property that did not exist at enrolment installs anyway and is never removed. Both are in Intune filters vs groups, along with the one combination of group assignment and group exclusion that Microsoft does not support.
Apps that will not install, or report the wrong state
App troubleshooting splits cleanly by app type. The Intune troubleshoot pane gives failure details per user, and Microsoft’s app installation troubleshooting article links the full error code reference. It also notes that when a required app fails, you or the help desk can sync the device and retry the install.
For Win32 apps, the status comes from detection rules, not from the installer’s exit code. That is why an app can install perfectly and still report Failed. The detection logic, the log that holds the answer and the other ways the pipeline breaks are in Intune Win32 app deployment.
For app protection on unenrolled devices, the question is usually timing rather than configuration. A protected app that gets an unusable answer from the service backs off for hours before asking again, as covered in MAM without enrollment.
Enrolment and Autopilot failures
Enrolment failures are the most expensive to debug late, because a device that enrolled wrongly can carry that mistake until it is re-enrolled. The posts below cover the three places it goes wrong.
Enrolment restrictions decide what may enrol, and they apply only to user-driven enrolment. Autopilot pre-provisioning, self-deploying mode, bulk enrolment and several other paths ignore the restriction you assigned and use the default policy instead. See Intune enrollment restrictions.
The enrolment status page decides what the user waits for, and it tracks less than its settings suggest. PowerShell scripts are not tracked at all. See the Intune enrollment status page.
The Autopilot path decides the rest. Autopilot device preparation is narrower than classic Autopilot rather than newer. Autopilot reset has four documented blockers. Who ends up as the device’s Intune primary user depends on the enrolment method, and it controls Company Portal access, not policy targeting.
Certificates, Wi-Fi and VPN
Certificate problems surface as network problems, which is why they get misrouted. A Wi-Fi or VPN profile that fails is very often a certificate profile that failed first, silently.
Start with the design question in SCEP vs PKCS. With SCEP the private key is created on the device. With PKCS it is generated on the connector server, and that changes both the security review and the infrastructure you have to run. If you use SCEP through an on-premises CA, the Intune NDES connector covers the predictable places it fails. The expensive one is a certificate that installs cleanly and then fails strong mapping at the domain controller. If you are weighing the hosted alternative, Intune Cloud PKI cost covers what it costs and what it replaces.
Route every Wi-Fi or VPN ticket through the certificate first. If the device holds a valid certificate from the expected issuer, the network profile is the problem. If it does not, the network profile was never going to work, and editing it only adds a second change to untangle later.
Compliance that lags
Compliance problems quickly become access problems, because Conditional Access reads the compliance state. The first question is whether the state is wrong or merely late.
Intune compliance policy status covers the reporting ceiling and why editing a policy resets every targeted device. That is the most common cause of a sudden wave of non-compliant devices after a harmless change. Custom compliance on macOS has its own strict typing rules, and a type mismatch simply reports non-compliant: see macOS custom compliance.
Security settings that do not stick
Security settings often fail quietly. Each of these posts covers a setting that reports success while doing less than you think.
- Intune BitLocker recovery key missing: the key lives on the Entra device object, not in Intune, and escrow has its own settings.
- Windows LAPS in Intune: a policy can back up nothing, because the backup directory defaults to disabled.
- Intune firewall rules: one malformed rule fails the whole profile.
Updates and drivers
Update policies do not conflict through the usual precedence rules. They conflict through timing, because several separate clocks decide when a device installs anything. Intune update rings sets out those clocks. Intune driver updates not working covers the settings that stop a device scanning for drivers at all, whatever you approve.
The trap with both is that nothing looks broken. An update that has not arrived is, from the portal’s point of view, still waiting. Before calling it a fault, work out which clock the device is currently on, and whether it has reached the point where anything should have happened yet.
Evidence: which log answers which question
Every layer 4 investigation ends with a log. Knowing which one saves the most time of anything on this page.
| Question | Evidence | Covered in |
|---|---|---|
| Did the MDM channel receive and process the policy? | The DeviceManagement-Enterprise event channel, and the MDM diagnostics report | Intune diagnostic logs |
| Did a Win32 app, script or remediation run? | The management extension logs under ProgramData | Intune management extension |
| What is the device’s state right now? | Device Query, where licensed | Intune Device Query limits |
| Can I fix it without touching the device? | A detection and remediation pair | Intune remediation script |
Collect diagnostics is the obvious remote option. Before relying on it, know that it has its own failure modes and a fixed list of what it gathers, with no Security event log and nothing from the user profile.
Intune troubleshooting mistakes that are documented behaviour
A large share of Intune tickets describe behaviour that is working exactly as Microsoft documents it. Recognising these saves the most time of all, because there is nothing to fix, only something to explain.
| What gets reported as a fault | What is actually happening | Read |
|---|---|---|
| A scoped admin can still see every device | Scope tags control console visibility, not deployment | Intune scope tags |
| Deleting a device did not remove its data | Retire, wipe and delete are different actions with different results | Intune wipe vs retire |
| The enrolment restriction did not block a device | Restrictions apply only to user-driven enrolment | Intune enrollment restrictions |
| A new filter did not remove an installed app | Installed apps are not automatically removed when a filter later matches | Intune filters vs groups |
| The Conditional Access device filter matches nothing | It evaluates the Entra device object, and unregistered devices have no properties | Conditional Access device filter |
Writing up an Intune ticket so it can be routed
Most Intune tickets arrive as “the policy is not working”, which tells the next engineer nothing about the layer. A short, fixed template turns that into something routable, and it costs the person raising the ticket about two minutes.
- The device name, its Managed value and its Last check-in time, copied from the portal at the moment the ticket is raised.
- The exact policy or app, its status for this device, and the per-setting status if the portal shows one.
- What the device actually shows, in the operating system, not in Intune.
- Whether anything changed recently: a new policy, an edited policy, a new group, a licence change.
- Which log was read, if any, and the line that matters.
The first item routes the ticket to layer 2 or rules it out. The second and fourth route it within layer 3. The third is the only honest evidence for layer 4, because it is the one item the portal cannot supply. A ticket with all five answered can usually be resolved from this page and the spoke it points to, without anyone touching the device again.
Keep the template short enough that people actually fill it in. Five questions is roughly the limit before tickets start arriving with the template deleted.
What I would do differently
My tenant is a lab with no enrolled devices, so this routing is built from Microsoft’s documentation and the research behind each spoke post, not from a production service desk. The judgement below is labelled as judgement.
Write the layer order into the service desk runbook, and make layer 2 mandatory before anything else. Checking Managed and Last check-in takes seconds. Skipping it is where most wasted Intune troubleshooting hours go.
Stop treating Succeeded as a result. Make “confirm the effective state on the device” a required step before any ticket about a policy closes. The firewall, LAPS and BitLocker posts all describe policies that report success while doing nothing useful.
Keep one owner per setting. Most layer 3 problems are two policies, or two management channels, setting the same value. A tenant where every setting has exactly one source has a fraction of the conflicts, and far easier ones to explain.
Finally, collect evidence before changing anything. Several of the failures above destroy their own evidence when you edit the policy again, and at least one log channel is off by default. Turn it on before you need it.
Last verified: 26 September 2026
