You’re facing a common, and frankly, annoying problem: Microsoft Intune works perfectly for one user but completely fails for another. You’re left wondering why Intune behaves so inconsistently and, more importantly, how to pinpoint the root cause. User-context policies are specifically applied to individual users when they log into a device, whereas device-level policies affect any user utilizing that particular machine. This guide is designed to help you troubleshoot Intune issues by providing a step-by-step plan. You’ll stop the guesswork and effectively resolve these user-specific problems.
Key Takeaways
Always begin fixing Intune problems. Use the ‘Troubleshooting + support’ section. It is in the Intune admin center. This tool shows important facts. It shows why user policies fail. It also shows error codes.
Check user group memberships. Check licenses. Check admin roles. Wrong settings here often stop Intune policies. They stop working for some users.
Look at the device’s sign-up status. Look at compliance rules. A device must be properly set up. It must follow rules. Then it can get Intune policies.
Look at policy assignments. Look for problems. Make sure policies go to the right users. Make sure they go to the right devices. Fix any settings that fight each other.
Look at device logs. Look at sync status. Do this right on the user’s computer. The MDM Diagnostics Report helps. Intune Management Extension health checks help. They show deep details. They show problems specific to the device.
Initial Intune Troubleshooting Steps
Intune might work for one user. It might not work for another. You need a plan. Start with these steps. They help find mistakes. They also find forgotten details. This part shows you what to check first. This helps fix Intune problems well.
Review Troubleshooting + Support Blade
Go to the Intune admin center first. Look for “Troubleshooting + support.” Then click “Troubleshoot.” This tool is very strong. It shows all info for one user. You can pick the user who has problems. This gives you full details. This part is key. It finds policy failures for users. It shows error codes. This happens when a policy fails. An onboarding profile is an example. It might not go to a device. Be careful with ‘App install lifecycle.’ Also, ‘App install history.’ They might show ‘Failure.’ But apps might install fine. Be careful with this data. Especially when fixing app policy failures.
Confirm User Group Membership
Wrong group membership often causes problems. Intune acts differently sometimes. Policies often go to certain groups. Check if the user is in the right groups. This is for the policies they should get. Mistakes often stop Intune policies. This happens for certain users. It often comes from Conditional Access policies. These policies can be tricky. They have inclusions and exclusions. You should keep ‘break-glass’ accounts out. This prevents being locked out. The system gives instant feedback. This is for user exclusions. It helps avoid full lockout. Groups inside other groups make things harder. Checking all group members is tough. Removing a group might seem okay. But it can mess up policies. This affects your users.
Examine User Licensing and Roles
Intune needs proper licenses. It also needs admin roles. A user must have the right license. This is for Microsoft Intune. Then they get Intune policies. They also get applications. Without the right license, Intune can’t work. It can’t manage their devices. It can’t set up things. Also, check the user’s admin roles. Is the user trying to do an admin task? Make sure they have the right Intune roles. Wrong or missing roles can stop a user. They can’t use certain Intune features. They can’t apply settings. This step is very important. It helps you fix problems completely.
Look into Device Setup and User Link
You must check how devices are set up. You also need to check how users are linked. These are common reasons for Intune problems. This part helps you see why a device acts weird. It helps for one user. It covers fixing device sign-up. It also covers user links.
Check Device Sign-Up Status
First, see if the device is signed up in Intune. Go to the Intune admin center. Find the device there. Look at its sign-up details. If sign-up failed, no policies work. You might see error codes. These codes give hints. For example, Autopilot problems can stop sign-up. DirSync issues can also block it. If a device is not fully signed up, it gets no Intune rules. This means policies fail.
Check Device Rules Status
Next, check if the device follows rules. A device not following rules often can’t get to things. This can happen for many reasons. A rule might not apply to the computer. This makes it not follow rules. This happens after checking. A login step might be missed. For example, a user might not type in their password again. Or a PIN or MFA after a long time. Devices can also stop following rules. This happens if they miss certain rule settings. These include needing data protection. Or needing antivirus software. A “high machine risk score“ can also make it not follow rules. This often happens when “Enable Defender for Endpoint” is “Not applicable.” This stops correct reports to Intune. This causes a rules failure.
Look at Main User Setting
Look at the main user set for the device. A wrong main user can cause issues. For example, the Company Portal app. Only the “signed up by” user can log in. This user checks if the device follows rules. It also starts app installs. This is a big problem for many users on one device. It also affects devices signed up by IT staff. If the main user is wrong, the real user can’t install apps. For BitLocker key recovery, only the DeviceRegisteredOwner can get the key. If the main user is wrong, the real user can’t get it. Windows MDM does not use the main user much. This is for applying rules. It uses device ID. Or device plus user ID. So, a wrong main user has less effect. This is on general rule use. But it still affects user things in Microsoft Intune.
Fix Old Device Sign-Ups
Old device sign-ups can stop new ones. This is a common problem. It happens when fixing Intune issues. If a device is only deleted from Azure AD, it can show up again as “Pending.” This happens in hybrid-joined setups. This is because of re-syncing. This “Pending” state makes managing hard. It also makes signing up hard. You must delete the device. Delete it from on-premises Active Directory. Then, run dsregcmd /debug /leave. Do this on the device. This cleans up old sign-ups. Old info might need to be removed by hand. This is for a good sign-up. This includes deleting old tasks. Also, registry keys. And the Intune sign-up certificate. The user must also be in the MDM user group. This is for automatic sign-up. They need the right licenses. An old sign-up can block a new user’s device sign-up. This happens if the user has too many devices. This often happens when users have many work devices. The system shows an error. It says the device limit is met. This stops more sign-ups. To fix this sign-up problem, remove old devices. Do this from the Intune Admin Center. Or, IT staff can raise the user’s device limit. Do this through Microsoft Entra settings.
Inspect Policy Assignments and Conflicts
You checked the user and device. Now, look at Intune policies. See how they are given out. Find any problems. Some policies go to some users. Others do not. This part helps you check policy targets. It also helps find overlaps. Remember different policy types. An Intune app protection policy is key. This is true if it relates to your problem.
Validate Policy Assignment Filters
Policies often miss users. This is due to wrong filters. Check if the user is in the right groups. These groups should get the policy. Mistakes happen with where policies go. Policies might not target the right user groups. So, the policy never reaches the user.
Filters and dynamic groups can cause issues. Your filter logic might be wrong. This sends policies to wrong devices or users. Or, policies might not go to the right ones. For example, an app protection policy uses a filter. If the filter logic is wrong, it won’t apply. This causes a problem for the user. Make sure your filters find the right user.
Analyze Policy Applicability Rules
Intune policies have rules. These rules decide if a policy applies. It applies to a device or user. You need to know these rules. You can test Intune policy rules by hand. This helps force configuration profiles to reapply. This is for Windows devices.
Make sure the user is logged in. This is key for user settings.
Open Task Scheduler as an admin.
Go to ‘Microsoft > Windows > EnterpriseMgmt > {the one GUID folder}’.
Find and run ‘Schedule #3 created by enrollment client’.
The profiles will reapply in seconds. This lets you test the rules. This only happens for logged-in users.
You can also check profile status. This shows if a policy applies. If a rule is met, the device is targeted. The profile will show ‘Succeeded’, ‘Error’, or ‘Failed’. If a rule is not met, the device is not targeted. The profile will show ‘Not applicable’. This means the policy’s rules were not met. This clearly shows why a policy might not work. An app protection policy is an example.
Identify Conflicting Policy Settings
To find conflicts:
Look at the Device configuration report. Do this for a device. Pick a policy to check issues or conflicts. This report shows settings. It shows those not ‘Not configured’. It also shows their status.
Select a specific setting. This opens its details. It shows the setting name. It shows its status on the device. It also shows ‘Source Profiles’. These profiles conflict. They set the same thing with different values.
From ‘Source Profile’ list, pick a record. This opens its overview. Review and change settings in that profile. This fixes the conflict.
Microsoft Graph can also help. It helps understand Configuration Profile Conflicts. Use deviceConfigurationConflictSummary. This is in its beta version. It gives info on conflicts. But it might not show security profile conflicts. Results can also take hours to appear.
Make sure policies do not overlap. Also, they should not contradict. Conflicts can happen. This is when policies target the same settings. But they have different values. For example, two app protection policy settings might clash. Watch policy refresh times. This helps you know when changes take effect. It also shows if devices are not getting updates.
To find devices with conflicts, go to ‘Device Status’. Devices with conflicts will show ‘Deployment status’ as ‘Conflict’. From there, you can look at the machine. Click ‘Device configuration’. View any profiles with conflicts. Selecting a conflicting profile will show the problem setting. It also shows its source profiles. This helps you fix Intune issues well.
Review Exclusion Groups and Scope Tags
Scope tags separate roles. They separate permissions. They separate devices and users.
A Global Admin sees all policies. This is in the Intune portal.
A mobile admin has specific scope tags. They only see mobile device policies. This is for BYOD devices linked to them.
An SRS admin has specific scope tags. They only see meeting room policies. They also see app protection policies. These are relevant to them.
Scope tags work with role-based access control. They make sure admins have the right access. They also ensure visibility. This is for relevant Intune objects. Scope tags are labels. You attach them to Intune objects. These include apps, policies, profiles, and scripts. They also attach to devices. This makes sure admins only see what is tagged for them. Roles say what an admin can do. Scope tags decide which objects they can see.
They let you give out Intune admin tasks. You can base this on region. Or department, or team. Scope tags support a ‘least privilege model’. This stops admins from seeing profiles. These are outside their assigned scope. For example, a London admin cannot see Paris profiles. They also keep the Portal view clean. Admins only see relevant objects. This reduces errors. If a user is not getting an Intune app protection policy, check scope tags. See if they limit its visibility or use. This is a key step to fix Intune issues.
Check Intune on the Device
You checked user and device settings. Now, look at the device itself. This part helps you find problems. It is right on the user’s computer. You will learn why Intune policies might not work. This includes an app protection policy.
Check Device Sync Status
A device must talk to Intune. This gets it policies and settings. If a device does not talk, it gets no updates. So, an app protection policy will not work. Other settings will not apply. You can make it talk from the device.
First, open Settings on your device. Then, pick Accounts. Under Accounts, choose Access Work or School. Pick the account with a briefcase. Click Info. Under Device Action Status, pick Sync. This makes it get new security rules. It also gets network settings. It gets managed apps from Intune.
You can also make it talk using PowerShell. Open PowerShell as an admin. Use this command:
Get-ScheduledTask | ? {$_.TaskName -eq ‘PushLaunch’} | Start-ScheduledTask
Check the sync. Look at the task scheduler history. Find new entries for ‘PushLaunch’. Also, find ‘Schedule to run OMADMClient by client’. Check the event log too. Look for a session that started. Make sure it finished well.
Sometimes, Intune sync fails. This is on Windows 10 devices. It happens if dmwappushservice is off. This service is key for Intune management. If it is off, the device cannot sync. A PowerShell script might turn it off. If this service is off, an app protection policy will not reach the device.
You can also use PowerShell. Check the last sync time. Install the Microsoft.Graph.Intune module. Open PowerShell as an admin. Run Install-Module -Name Microsoft.Graph.Intune. Connect to Microsoft Graph. Use Connect-MgGraph. Sign in as an admin. Agree to the needed scopes. Connect to device management scopes. Run Connect-MgGraph -scope DeviceManagementManagedDevices.PrivilegedOperations.All, DeviceManagementManagedDevices.ReadWrite.All,DeviceManagementManagedDevices.Read.All. Sign in again. Before syncing, check the last sync date. Check the time of a Windows device. Use Get-MgDeviceManagementManagedDevice -Filter “contains(deviceName,’CLOUDVM1’)” | fl lastsyncdatetime. This shows if the device talked to Intune. If not, an app protection policy will be old.
Look at Device Event Logs
Event logs on the device help a lot. They show what Intune is doing. If an app protection policy does not work, logs often have the answer.
Open Event Viewer on the device. Go to Start > Event Viewer. Go to Application and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider > Admin. Look for Event ID 813. This confirms a good result. It will show policy details. For example, ‘MDM PolicyManager: Set policy int, Policy: (LetAppsSyncWithDevices), Area: (Privacy), EnrollmentID requestinq merqe: (EB427D85-802F-46D9-A3E2-D5B414587F63), Current User:(Device), Int: (0x2), Enrollment Type: (0x6), Scope: (0x0)’.
These Windows Event Logs are helpful. They help find Intune problems.
microsoft-windows-devicemanagement-enterprise-diagnostics-provider-adminmicrosoft-windows-devicemanagement-enterprise-diagnostics-provider-operational
Other useful event logs are:
microsoft-windows-aad-operationalmicrosoft-windows-appxdeploymentserver-operationalmicrosoft-windows-assignedaccess-adminmicrosoft-windows-assignedaccess-operationalmicrosoft-windows-assignedaccessbroker-adminmicrosoft-windows-assignedaccessbroker-operationalmicrosoft-windows-crypto-ncrypt-operationalmicrosoft-windows-devicemanagement-enterprise-diagnostics-provider-debugmicrosoft-windows-moderndeployment-diagnostics-provider-autopilotmicrosoft-windows-moderndeployment-diagnostics-provider-managementservicemicrosoft-windows-provisioning-diagnostics-provider-adminmicrosoft-windows-shell-core-operationalmicrosoft-windows-user device registration-admin
Intune and Windows MDM logs are in event logs. You can get them from MDMDiagReport.cab. The main MDM event logs are key. They help fix Intune policy problems. The main path is Applications and Services Logs – Microsoft – Windows – Devicemanagement-Enterprise-Diagnostics-Provider – Admin. If an app protection policy is not working, these logs show why.
Common error messages show Intune policy problems. Look for these in device logs:
‘DMEnrollment’ and ‘MDMEnrollmentStatus’ show ‘NO/FAILED’. This means enrollment failed. This can be due to licenses. Or wrong policies. Or enrollment limits. If you see these, an app protection policy cannot start.
Use MDM Diagnostics Report
The MDM Diagnostics Report is a great tool. It shows what Intune settings a device has. This report helps find why Intune policies are not working. This includes an app protection policy. It helps for a user’s device.
The MDM Diagnostic Information report shows settings. It includes Policy CSP settings. It shows certificates. It shows where settings come from. It shows when the device last checked in. It shows BitLocker settings. It shows if GPOs are blocked by MDM policies. It points out ‘policies not being managed’. Or areas not managed. This means a policy for that area is not applied. For example, if BitLocker is not listed, its policy is likely not applied. This also applies to an app protection policy. If the report shows a problem for an app protection policy, you know where to look.
To make an MDM Diagnostics Report:
Sign in to the Microsoft Intune admin center.
Go to Troubleshooting + support > Troubleshoot > pick a user.
On the Summary page, pick App Protection > Checked-in.
Find the app you need to check. Use the “...” option. Pick Collect diagnostics.
Say Yes when asked.
To get the diagnostics:
Go to Troubleshooting + support > Troubleshoot > pick a user.
On the Summary page, pick the Diagnostics page. Download the diagnostics.
If uploads are too big, you cannot download them. This is for over 50 diagnostics. Or over 4 MB. For bigger uploads, call Microsoft Intune support. Diagnostics usually take 30 minutes. This is from a user’s device. The user might need to close the app. Then open it again. This is if asked for a PIN. This starts the diagnostics request. Diagnostics are saved for 28 days. Then they are deleted. Each device can save 10 collections. This report is key for unknown problems. You can run diagnostics to get this info.
Check Intune Management Extension Health
The Intune Management Extension (IME) is very important. It sends PowerShell scripts. It sends Win32 apps. If IME is not healthy, these will fail. This can affect an app protection policy. This is if it needs these deployments.
Signs of an unhealthy Intune Management Extension are:
Network problems stop IME from sending reports. Or getting content. (e.g., error 0x87D30065).
User logs off too soon. IME cannot send app results. Or a session changes. This means the app is not found. This is after it installed well. (error 0x87D1041C). This can make an app protection policy fail.
System goes to sleep. This is due to no activity. The app is not found. This is after it installed well. (error 0x87D1041C).
Client error in IME itself (error 0x87D300CA). You need to check
ClientHealth.log.IME cannot get an AAD token. This is for user/device policy.
Wrong detection logic. IME skips app steps. Or reports install as failed.
Cannot check requirements. This is due to system problems. It reports ‘Unknown’ (error 0x87D30000). This includes when device type or OS version does not fit.
RegistryRequirementNotMet. This is if a requirement is not met. This is during checks.
Download failures. These are often network issues. Or BITS service problems. This includes ‘Error downloading content’ (0x87D30068). Or ‘content delivery network timed out’ (0x87D3006A). Or ‘physical resources of this disk have been exhausted’ (0x8007013A).
Integrity check problems. Such as ‘Error unzipping downloaded content’ (0x87D30067). Or ‘The system cannot find the file specified’ (0x80070002). This often happens with antivirus.
Installation problems. This includes ‘access denied’ (0x80070005). This is if IME cannot get admin rights. Also, ‘user logging off while app policy was being processed’ (0x87D300CD). Or install timeout (0x87D300C9).
Cannot report status. This is to the service. For example, install works. But detection after install is wrong. This means the app is not found (0x87D1041C).
The AgentExecutor.log tracks PowerShell scripts. It tracks how they run. This log starts when PowerShell scripts are sent. Or Win32 apps are sent to devices. It mainly watches PowerShell scripts. It watches them run on the computer. The AgentExecutor.log tracks PowerShell scripts and commands. It records when scripts start and end. It records error codes. A code other than zero means failure. It records errors and warnings. For example, if a script fails with code 1, this log shows the problem. If an app protection policy needs a script, this log is key.
Use Better Logs and Reports
You have looked at basic fixes. You also checked what the user sees. Now, use better logging tools. Use reporting tools. These tools give you more details. They help find hard problems.
Check Intune Audit Logs
Intune audit logs track admin actions. They show who changed what. They show when changes happened. You can look at these logs. They help find wrong changes. Or accidental changes. These changes might affect a user’s setup. For example, an admin might remove a user. This is from a group. This can stop a policy from working.
Look at Microsoft Entra Sign-in Logs
Microsoft Entra sign-in logs give key info. They show every sign-in try. You can see if a user logged in. You can also see if a login failed. These logs show why a login failed.
50058: You logged in. But you did not finish the process. This might show an ID. Not a username.
90025: A Microsoft Entra service had a retry problem. This usually fixes itself. You might need to log in again. This is if it keeps happening.
500121: You did not finish Multi-Factor Authentication (MFA). MFA setup might not be done. You need to finish the setup.
70046: Your session ended. Or a recheck failed. This happens if a session token ran out. A Conditional Access policy might need you to log in again. This is due to risk.
Use Microsoft Graph Explorer
Microsoft Graph Explorer is a strong tool. It lets you ask for Intune data directly. You can get full policy assignment status. This helps you check policy use. This is for a certain user or device.
You can list all app protection policies:
Endpoint:
GET /deviceAppManagement/managedAppPolicies
You can get app protection policy device status:
Endpoint:
GET /deviceAppManagement/managedAppPolicies/{policyId}/deviceStatuses
You can get app protection policy user status:
Endpoint:
GET /deviceAppManagement/managedAppPolicies/{policyId}/userStatuses
These questions need DeviceManagementApps.Read.All rights. Many reports are also in the Intune portal. For example, find “DeviceStatusesByConfigurationProfile“. It is under Devices > Manage devices > Configuration > Policies.
Get and Check Device Logs
Beyond event logs, other logs help a lot. They are on the user’s device. You can get diagnostic logs from the device. These logs help you know what Intune is doing. For fix scripts, make a custom IntuneRemediations.log. This log is in the IME folder. It keeps a record of all commands. This helps fix script running problems.
IntuneManagementExtension.log: This is the main log file. It is for the Intune Management Extension (IME). It records most main actions.HealthScripts.log: This log shows details. It shows how detection scripts ran. It also shows remediation scripts.Win32AppInventory.log: This log gathers info. It is for installed Win32 apps.
These checks give a full view. They help you fix hard Intune problems.
You must fix Intune problems in order. Do not just check things randomly. You looked at first checks. You checked the user and device. You looked at policy rules. You checked what the device was doing. You also used better logs. You need to know how Intune works. This means knowing about users. It means knowing about devices. It means knowing how policies apply. This helps fix problems well. Write down what you find. Write down how you fix it. This will help you fix problems faster later.
FAQ
Why does Intune work for one user but not another?
This often happens for different reasons. Check user licenses. Look at group memberships. See device enrollment status. Policy problems can also cause this. Device issues can also lead to this.
How do I check a user’s Intune license?
Go to the Microsoft 365 admin center. Find the user there. Check their licenses. Make sure they have an Intune license. Without it, Intune cannot manage devices. It cannot apply policies.
What is the MDM Diagnostics Report?
This report shows device settings. It includes policy settings. It shows certificates. It shows last check-in times. You use it to find policy problems. This helps find specific setup issues.
How do I fix conflicting policies?
Use the Device configuration report. It shows settings and their status. Select a setting. See “Source Profiles.” These profiles clash. Change settings in these profiles. This fixes the problem.
What is the Intune Management Extension (IME)?
The IME is very important. It sends PowerShell scripts. It sends Win32 apps. If it is not working, these fail. Check its health. Look at logs like IntuneManagementExtension.log. Also, check AgentExecutor.log for errors.
