How to Troubleshoot Intune-Managed Windows Devices Day to Day

Find the failing layer before you try fixes

Most reports of 'Intune isn't working' are one of four different problems wearing the same coat. The PC never enrolled properly. It enrolled but isn't checking in. It checks in but a policy hasn't landed or is fighting another policy. Or policy is fine and an app simply isn't arriving. Each has different evidence and a different fix, and each depends on the one before it, so check them in that order.

The Intune admin center is a record of what the device last told Intune, not a live camera feed. Microsoft notes that reports can take longer to reflect a device's latest policy state than the device takes to apply it. That is why a clean-looking portal and a misbehaving PC can both be true at once, and why the local evidence in this article matters.

Retire, Wipe and Delete come last. They end or reset a device's relationship with your tenant, so they belong to lifecycle events such as a leaver, a lost laptop or a hand-me-down, not to diagnosis. Sync is the one action here that you can repeat freely.

• Enrolment: is the PC joined or registered with Microsoft Entra and enrolled in Intune under the right user with a valid licence? Evidence: the Enrollment failures report, dsregcmd and the device's own event log.
• Check-in: is the device actually talking to Intune? Evidence: last check-in time and the Device sync status tab.
• Policy: have the profiles arrived, and does anything conflict? Evidence: per-device policy status and the MDM diagnostic report.
• Apps: is the Intune Management Extension present, and what do its logs say? Evidence: the Managed Apps view and AppWorkload.log.

Before you start: access, risk and evidence handling

Reading reports and running the local checks below changes nothing. Sync and Collect diagnostics are low-impact: Sync prompts a check-in, and Collect diagnostics gathers logs from a corporate-owned Windows device without interrupting the user. Retire, Wipe and Delete are the disruptive ones, covered in their own section.

Roles matter. Sync needs Help Desk Operator, School Administrator, Endpoint Security Manager or a custom role with the Remote tasks/Sync devices permission. Retire and Wipe need Help Desk Operator, School Administrator or a custom role with Remote tasks/Retire or Remote tasks/Wipe. Delete is different: it lists School Administrator, Endpoint Security Manager or a custom role with Managed devices/Delete, and Help Desk Operator is not among them. Your tenant may also require a second administrator to approve Retire, Wipe and Delete through multiple administrative approval.

Treat everything you collect as personal data. Logs, dsregcmd output and diagnostic zips can include user principal names, device names, device and tenant IDs, and network or certificate details. Intune keeps a Collect diagnostics result for 28 days (up to 10 per device) and warns that Microsoft personnel might access device diagnostics while troubleshooting. Redact before sharing, keep evidence out of public forums and open tickets, and never paste a BitLocker recovery key anywhere that is not your approved secret store.

Start in the admin centre, then sync

Sync forces the device to check in. That is a device contacting Intune to collect pending actions, policies and apps. It is cheap and repeatable, and it separates 'hasn't arrived yet' from 'won't arrive'. What it cannot do is repair a broken identity, reach a powered-off PC or revive a device whose TPM was reset. In that last case Windows may report 'The sync could not be initiated (0x80072f9a)' and the device has to re-enrol.

Timing is worth knowing before you declare anything broken. A newly enrolled Windows device checks in every 3 minutes for 15 minutes, then every 15 minutes for 2 hours, then roughly every 8 hours. After that, a maintenance check-in is estimated at about every 8 hours, and a device only gets one maintenance sync every 6.5 hours regardless of schedule. Assigning, changing or removing a policy also triggers a notification, which can reach an online device anywhere from immediately to a few hours later.

1. In the Microsoft Intune admin center, go to Troubleshooting + support and choose Select user. Pick the affected user. The page lists their devices, assignments, enrolment failures and app protection status. If the Enrollment failures metric is non-zero, select it for the failure reason and recommended remediation.
2. Go to Devices > All devices and open the device. Note the primary user, OS version, compliance state and last check-in time. A last check-in far older than the eight-hour maintenance cycle, on a PC that has been switched on and online, points at the device or its network rather than at policy.
3. Select Sync, then Yes. Open the Device sync status tab to follow progress. If you do not see that tab, switch on Preview new device view at the top right of the console. Microsoft states the tab applies to Windows and iOS/iPadOS devices.
4. If the user is at the PC, they can start the same check-in themselves. In Company Portal, they select Settings > Sync. Alternatively, in Windows Settings they go to Accounts > Access work or school (labelled Work access on some builds), select the work account, then Info > Sync. A Company Portal sync starts an Intune Management Extension check-in as well as the MDM check-in.
5. If the complaint is blocked access rather than a missing setting, have them open Company Portal, go to Devices, select the device and choose Check access under Device status. It can take a few minutes. The result is one of 'Can access company resources', 'Cannot access company resources' or 'Can access company resources, but action required', with remediation links where available.
6. Give it a sensible interval, then check the device page again. A device that is online and still shows nothing new after a sync has told you something useful: move on to local evidence for the layer you suspect.

Enrolment problems: licence, scope and stale registrations

Failed enrolments usually trace back to who is enrolling (licence and scope), what the tenant allows (restrictions and device limits) or what the PC remembers (an earlier registration). Check the portal side first, because those fixes are quick and local work is unnecessary if the tenant is saying no.

Match the message or code you are seeing to the likely cause:

The local steps below tell you how the PC sees itself. In dsregcmd output, AzureAdJoined YES with DomainJoined NO means Microsoft Entra joined, and YES with YES means Microsoft Entra hybrid joined. A Microsoft Entra registered device, typically a personal one with a work account added, shows WorkplaceJoined YES under User State instead.

• 'This account is not allowed on this phone': the user does not hold a valid Intune licence. Assign one in the Microsoft 365 admin center, then try again.
• Error 0x80180014, 'Your organization does not support this version of Windows': Windows MDM enrolment is blocked. In the Intune admin center, go to Devices > Enrollment restrictions, open the device type restriction, then Properties > Edit next to Platform settings and set Windows (MDM) to Allow.
• Error 8018000a, 'The device is already enrolled': another user has already enrolled the PC or joined it to Microsoft Entra ID. Settings > Accounts > Access work or school (or Work access) shows the other connection. That user has to remove it before the intended user enrols.
• Error 0x8007064c, 'The machine is already enrolled': the PC was enrolled before, is a clone of an enrolled machine or still holds an old account certificate. The documented fix involves deleting a stale enrolment certificate and registry keys, which is specialist work. Hand it over rather than improvising.
• Auto MDM Enroll failed (0x8018002b, Event 76 in the device's Admin event log): the user's UPN uses an unverified or non-routable domain such as .local, or MDM user scope is None. In Microsoft Entra ID, go to Mobility (MDM and MAM) > Microsoft Intune and set MDM user scope to All, or to Some including the user's group. Microsoft also advises setting MAM user scope to None for this Windows scenario.
• Error 80180026: automatic MDM enrolment is on and the legacy Intune PC software client is still installed. Remove the old client or switch off automatic enrolment.
• Enrolment succeeds for one device but not the next: check Maximum devices per user under Microsoft Entra device settings, and remove stale device records the user no longer needs.

1. On the affected PC, sign in as the affected user and open PowerShell without elevation. Run dsregcmd /status. This only reads state. Run it in the user's own context because the User State and SSO State sections need it. Output includes DeviceId and TenantId, so redact those before sharing.
   powershellCopy

   dsregcmd /status

2. Read three areas of the output. Under Device State, confirm the join state is what you expect. Under Device Details, DeviceAuthStatus should read SUCCESS. Under Tenant Details, MdmUrl, MdmTouUrl and MdmComplianceUrl being blank suggests MDM is not configured or the user is outside MDM user scope. Populated URLs do not prove the PC is managed, only that the tenant offers automatic enrolment.
3. Open PowerShell as an administrator and read recent warnings and errors from the MDM Admin event log. This is read-only. Messages may contain user and device names.
   powershellCopy

   Get-WinEvent -LogName "Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin" -MaxEvents 100 |
       Where-Object { $_.LevelDisplayName -in "Error", "Warning" } |
       Select-Object TimeCreated, Id, LevelDisplayName, Message |
       Format-List

4. If the portal and the device disagree, produce the MDM diagnostic report. By hand: Settings > Accounts > Access work or school, select the work account, then Info, then Create report, then Export. Or run the command below from an elevated prompt. It reads enrolment, provisioning and Autopilot data and writes a zip file.
   cmdCopy

   mdmdiagnosticstool.exe -area "DeviceEnrollment;DeviceProvisioning;Autopilot" -zip "c:\users\public\documents\MDMDiagReport.zip"

5. Open MDMDiagHtmlReport.html from the output to see management URL, device ID, certificates and policies, and open the .evtx files in Event Viewer if you need the detail. Both routes write to C:\Users\Public\Documents, which other local users can read. Move the evidence to your approved location and delete the copies on the PC.

Policy drift: when the device and the portal disagree

Windows applies Intune settings through configuration service providers. Some of them remove a setting when the profile goes away. Others leave it in place, which is called tattooing. So a setting that lingers after you unassign a profile is sometimes by design rather than a fault, and 'drift' is often a mix of timing, overlap and scope rather than anything dramatic.

Before you edit any policy, work out which of these you are looking at:

• Not delivered yet: the device is offline, or a change notification has not reached it. A sync answers this.
• Conflict: two configuration policies set the same setting to different values. Intune shows the conflict and you resolve it manually. Compliance policy settings take precedence over the same setting in a configuration profile, and the most restrictive of competing compliance settings applies. Profiles can be created in several places, including the settings catalog, endpoint security, security baselines and Group Policy analytics, so check them all.
• Not applicable: some settings report Not Applicable because the Windows version or edition on that PC does not support them.
• Group membership lag: apps and policies assigned to a dynamic device group are not delivered until the device has been added to the group after enrolment. User groups, assignment filters or enrolment time grouping avoid the wait, because filters are evaluated at check-in and enrolment time grouping places the device in a group during enrolment.
• Removal lag: after you unassign a profile or remove someone from its group, the user may need to sign in and the device to sync. For user group removal it can take 7 hours or more for the settings to clear.

1. In the admin center, open the device and review the status of each configuration profile that applies to it. For anything showing Conflict or Error, open the profile's per-setting status to see which setting is involved and which other policy is competing. Menu layout differs between the new and classic device views, so follow the policy name rather than a fixed click path.
2. Sync the device and wait for the interval described earlier. Check the status again before changing anything, since statuses lag.
3. If the portal says the setting succeeded but the PC behaves differently, produce the MDM diagnostic report as above and compare the policies listed in MDMDiagHtmlReport.html with what you expect.
4. Make the fix at the source: remove the overlapping assignment, narrow the scope or correct the setting. Trial any change on a pilot group first, because a profile edit reaches every assigned device. Sync a pilot device and confirm the status changes before widening the assignment.

App delivery and the Intune Management Extension

Win32 apps, PowerShell scripts, remediations and similar workloads arrive through the Intune Management Extension (IME), a separate agent that installs itself when you first assign one of those things to a user or device. If nothing assigned to a PC needs it, the agent will not be there, and that is not an error. The IME also keeps its own check-in cycle, independent of the MDM check-in, which is why a PC can be up to date on policy while an app still waits.

It also helps to know the rules the agent plays by before you read any logs:

• Intent matters. Required apps install automatically. Available apps appear in Company Portal and install only when the user asks. A Win32 app installed through an Available assignment is not reinstalled automatically if the user later removes it.
• Deadlines delay installation. If a Win32 app has an installation deadline, it downloads but does not install until the deadline, while Company Portal already shows Installing.
• Installs must be silent. Intune does not support interactive installers, and a user-targeted app that needs admin rights the user lacks will fail.
• Windows Home and S mode are out. The IME needs a supported Windows edition and does not support S mode.
• Antivirus can interfere. Microsoft recommends excluding the IME Content folder and C:\Windows\IMECache from scanning, otherwise installs can fail without an obvious reason.
• Unenrolling does not uninstall. Win32 apps installed by Intune are not removed when a device is retired or unenrolled.

1. In the admin center, go to Troubleshooting + support, select the user, choose the device, then Managed Apps. Open an app whose Installation Status shows a failure and read the error. Check the resolved intent too: an app excluded in one assignment shows as excluded, even if another group includes it.
2. For a failed Win32 app, open Installation details and use the diagnostics option, which some Microsoft pages call Collect logs. You supply full file paths for the logs you want, and supported types include .log, .txt, .dmp, .cab, .zip, .xml, .evtx and .evtl, up to 25 paths and 250 MB. Collection can take around 15 to 20 minutes and needs Windows 11 or Windows 10 version 1909 or later, so go and answer something else in the meantime. A download link appears when it finishes.
3. At the PC, sync from Company Portal (Settings > Sync) so the MDM and IME check-ins both run, then give the app a few minutes to react.
4. Open PowerShell as an administrator and confirm the IME service exists and is running. This is read-only.
   powershellCopy

   Get-Service -Name IntuneManagementExtension | Select-Object Name, Status, StartType

5. List the log folder to see which files were written recently. The folder is the same on current IME versions.
   powershellCopy

   Get-ChildItem -Path "C:\ProgramData\Microsoft\IntuneManagementExtension\Logs" |
       Sort-Object LastWriteTime -Descending |
       Select-Object Name, Length, LastWriteTime

6. Search the main app log for failures. AppWorkload.log holds app check-ins, installs, applicability and detection. IntuneManagementExtension.log covers agent check-ins and policy processing, AgentExecutor.log covers PowerShell scripts, and HealthScripts.log covers remediations. Older copies are kept with a leading underscore after a log rolls over.
   powershellCopy

   Select-String -Path "C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\AppWorkload*.log" -Pattern "error|fail" |
       Select-Object -Last 30 Filename, LineNumber, Line

7. For readable context around a hit, open the log in CMTrace, the Configuration Manager log viewer, which sorts and highlights lines far better than a text editor.
8. Compare timestamps. If AppWorkload.log shows no activity after your sync, the agent is not receiving the assignment, so go back to targeting, group membership and the device's join state. If it shows an attempt and a failure, the failure text, not the portal summary, tells you whether detection, download or the installer itself broke.

Retire, wipe and delete: what each one does before you press it

These three have separate consequences, and none of them is a troubleshooting step. Retire, Wipe and Delete also take precedence over every other pending action on a device. If one is queued, a pending Sync or diagnostics request is ignored. Tenants have daily submission limits of 500 Wipe, 1,000 Retire and 1,000 Delete actions, shared across single actions, bulk actions (up to 100 devices) and Graph requests.

Each action runs at the device's next check-in, so a PC that is off or offline keeps its data and its management until it next connects.

• Retire removes company data and settings and leaves personal data. On Windows it uninstalls apps pushed through MDM, removes sideloading keys and Wi-Fi, VPN and certificate profiles, and stops enforcing settings. A Microsoft Entra joined device is unjoined and its Entra record removed, so afterwards no one can sign in with a Microsoft Entra account. Recovery is by signing in with a local administrator account in Safe mode. Microsoft 365 Apps and IME-installed Win32 apps are not removed.
• Wipe is a factory reset. With no options ticked, all user data, settings and MDM policies are removed, and an interrupted wipe attempts to roll back and may leave the device needing a full Windows reinstall. Keeping enrollment state and the associated user account removes MDM policies but keeps user data and accounts. The protected option continues even if power is lost and overwrites free space. Microsoft warns it can leave some devices unable to start again, so use it only on corporate-owned devices where full destruction is required and recovery procedures exist.
• Delete removes the device record from Intune. For Windows it hides the device immediately and triggers a Retire. A Delete showing Completed means the server side finished, not that the PC has completed the Retire. Use it to tidy stale records, not to fix a stuck enrolment.
• Fresh Start and Autopilot reset also exist for Windows. They are reset tools rather than diagnostics, and this article does not cover them.

1. Identify the device unambiguously. In Devices > All devices, check device name, serial number, primary user, ownership and last check-in against the request. Names get reused, so do not rely on the name alone.
2. Choose the action from the situation. A personally owned device should only ever be retired, never wiped. A corporate device being redeployed or lost is a Wipe candidate. A record for hardware that no longer exists is a Delete candidate.
3. For any Retire or Delete of a Microsoft Entra joined, BitLocker-protected device, first confirm you can retrieve the BitLocker recovery key and that local administrator credentials are recorded. Intune triggers a sync that removes key protectors and suspends BitLocker on the OS volume as a safeguard, and Microsoft tells you to back up the key and local administrator credentials first.
4. Confirm with the user or owner that nothing exists only on that PC. A Wipe with no options deletes user data, and Retire on an Entra joined device ends access to local data through a Microsoft Entra sign-in.
5. Check your role and whether multiple administrative approval applies. If it does, tell the approver exactly which device and action, and why.
6. Open the device page. For Retire or Wipe, select Remove data, then the action. For a Wipe on Windows, choose the option that matches the decision from the list above. For Delete, select Delete. Confirm when prompted. These actions are not safe to rehearse on a device you care about, so use a dedicated test device when you want to see the behaviour first.
7. Go to Devices > Device actions to follow the result. Allow for the device's next check-in before you treat the outcome as final. If the PC is being reused or retired, also deregister it from Windows Autopilot when applicable and remove its stale Microsoft Entra record.

If a Windows device is lost

Windows differs from phones here. Microsoft's Windows action list includes Locate device, Retire, Wipe and Delete, but it does not include Lost mode, which appears for iOS/iPadOS and ChromeOS, and it does not list Remote lock for Windows. Check the Locate device page for its prerequisites before relying on it, because this article does not cover them.

Our own judgement, rather than a Microsoft procedure, is that a lost PC should be handled as a protection question first and a Wipe question second. Remote actions only act when the device connects, and a stolen laptop may never do so. That makes BitLocker and your account controls the real safeguards.

• Confirm the device is encrypted with BitLocker and that its recovery key is retrievable. That protects the data even if the Wipe never reaches the PC.
• Ask whoever manages identity to reset the user's password and revoke their active sessions, so a lost laptop with a signed-in profile cannot be used to reach company data.
• For a corporate PC that will not be recovered, submit a Wipe. If a recovery is plausible, record the decision, because a submitted Wipe runs when the device next connects and should be treated as irreversible. Consider the protected option only where full destruction is required and you accept the boot risk described above.
• For a personally owned device, use Retire. That removes company data and leaves the owner's data alone.
• Record who decided, when and why. Follow up at Devices > Device actions and keep any recovery key access logged in your normal process.

Triage checklist and when to escalate

Keep the checklist short enough to be used mid-call. Run it top to bottom and stop when you find the cause.

If it still fails after the local checks, gather one tidy evidence pack for whoever picks it up next: the enrolment failure reason from the portal, the time of your Sync, the Device State and Tenant Details sections of dsregcmd with identifiers redacted, any warnings from the MDM Admin event log, the MDM diagnostic report, and the matching AppWorkload.log lines. Collect diagnostics from the admin center is the least intrusive way to get logs from a corporate device that cannot be reached. Microsoft support can see more than you can, and a clear timeline shortens that conversation.

• Confirm the user, licence, device and ownership are what you expect.
• Check the device's last check-in and compliance state in the admin center.
• Sync from the admin center and from Company Portal, then wait a realistic interval.
• Enrolment failure: read the Enrollment failures report, then dsregcmd and the MDM Admin event log.
• Policy: look for Conflict, Not Applicable, group lag or a setting that tattoos.
• App: check intent, deadline, assignment, the IME service and AppWorkload.log.
• Collect evidence with redaction and handle it as personal data.
• Only then decide whether the situation really calls for Retire, Wipe or Delete, and run the pre-action checks first.