Microsoft Intune is capable of doing some amazing things management-wise with Windows 10 devices. We can easily turn those devices into kiosks, configure them for shared usage, keep them up-to-date with Windows quality and feature updates, protect them using endpoint protection policies, even enroll them into Defender ATP. I could go on for a while with this, and how easy it is to manage Windows with Intune, but that’s not what this post is about. This post is about what to do when things seemingly go awry while managing Windows 10 devices with Intune. I’ll start at the top, the MEM admin center and then take you down into the troubleshooting weeds.
Use the MEM admin center
Lots of places in the MEM admin center surface information that is helpful to endpoint management admins so we should probably start with what you see there. As soon as you log in, you’re presented actionable information on the default dashboard. This snippet doesn’t even include the information about enrolled devices and additional compliance and configuration profile status data shown on this screen.
Reports
Intune puts a lot of reporting information at your fingertips by using several different types of reports. These varying reports are designed to cater to different personas who might be logging into the MEM admin center. For example, an IT admin’s reporting needs will differ from an IT Manager’s or help desk person’s. These reports can help you as you follow the bread crumbs of a troubleshooting issue in your environment so it’s good to know the kinds of information available to you and where it lives.
Intune reports are broken down into these categories:
- Operational. These reports are found all over the MEM admin center, generally under the Monitor section of each of the main admin center nodes. Take Devices for example. When you select that node you see the reports you’d care about if you were working with devices. This is usually real-time information that calls out unexpected behavior and is meant to be actionable. In the Overview section you can see enrollment status, enrollment alerts, compliance status, configuration status, and software update status for enrolled devices. If you select Monitor, you get additional aggregate reporting information for more details. All related to devices, all right where you’d expect to be looking for that data. Look at the Apps node and you’ll see similar information that answers any questions about apps that an IT admin might have.
- Organizational & Historical. Now, if you’re an IT manager, it’s great to be able to drill-down to individual devices or policies, but you’re probably more interested in the bigger picture. Something like overall compliance reporting for all devices or how compliance is trending over time. All that information is available in the Reports node of the MEM admin center. Go check it out. If you need more custom data reporting you can use the Intune data warehouse and it’s oData feed with your reporting service of choice. That’s also where you can peruse endpoint analytics to easily get insights and recommendations to proactively optimize user experience in your organization.
- Specialist. These reports are for those of you who really need to get into the weeds on something. These allow you to create your own reports to get the exact data you want by querying all of the available Intune data via Azure Monitor using Log Analytics and Azure Workbooks. Make a report that digs deeper into enrollment status during a migration or a report that shows you who wiped a device when. You get the idea.
Device details
You can drill down into individual devices and review information there too. You’ll see things like hardware details, discovered apps, device compliance and configuration status, app configurations, endpoint security settings, BitLocker recovery keys, and managed apps.
Troubleshooting + support | Troubleshoot
Need more details, or maybe you’re a help desk person on the phone with an end-user having a bad day? You can use Intune‘s troubleshooting and support capabilities to quickly find a user and all their device information to do some additional sleuthing. From there, you can dig into things like:
- Assignments for apps, policies, profiles, update rings, and enrollment restrictions.
- Devices the user has registered to quickly see how the devices were enrolled, if they’re compliant, OS info, and more.
- App protection status for any apps that should have those policies applied.
- Enrollment failure information associated with the user (if any).
On the device
If it’s your device that’s having an issue, you can take action without even opening the MEM admin center. The first thing you could do would probably be to go manually sync your device to ensure it’s at least trying to get the most current policies applied. Give it a few minutes and if you’re still not seeing what you’d expect, there are a few more things we can do to start troubleshooting.
Generate the MDM Diagnostic report
The MDM Diagnostic Information report shows the applied configuration states of your device including Policy CSP settings, certificates, configuration sources, and resource information. Here you can see all kinds of information about your device: when it last checked in successfully, BitLocker settings, if any GPOs are being blocked by MDM policies, resource access profiles, policies not being managed at all. I could go on, but it’s easier for you to go generate a report and look for yourself.
To do that, go to Settings (Windows Key + i) > Accounts > Access work or school > <select your account> and then click Info. Scroll all the way to the bottom of that screen and click Create report.
The create report option is at the bottom of the settings screen, but back up at the top, you’ll see the areas being managed and the types of policies being applied to the device. If you’re troubleshooting an issue and don’t see that area being managed, the policy probably hasn’t been applied. For example, if you’re trying to set BitLocker settings on a device and don’t see BitLocker as a managed area, that’s not a good sign.
The report will be generated and saved to: C:/Users/Public/Documents/MDMDiagnostics/MDMDiagReport.html. Go check it out.
Export management log files
Someone somewhere is screaming, “but I want to see actual log files” at their computer screen right now. OK, here’s how you do that. This is also something support will most likely as you to do if you must call them so it’s good to know how to get the MDMDiagReport.cab file.
Go to Settings (Windows Key + i) > Accounts > Access work or school and then click the Export your management log files option. Pretty self-explanatory, but that’s what it does and the logs will be saved in a MDMDiagReport.cab file located the same place the MDM diagnostics report is saved to: C:/Users/Public/Documents/MDMDiagnostics. You’ll be prompted to provide feedback via the Feedback Hub. You can do that or just close that dialog and go look at the logs.
There are a ton of logs and files generated and stored in that .cab file. Support will know what to do with them. I’m not going into too much detail about them, but Peter van der Woude did a great job explaining what most of them are here: Windows 10 MDM troubleshooting.
Check the Windows Event Logs
Looked through all the available report information and still have questions? Try the Windows Event logs as a next step in troubleshooting MDM issues. The MDM management events are logged to:
Applications and Services Logs\Microsoft\Windows\DeviceManagement-Enterprise-Diagnostics-Provider\Admin
Autopilot-related events are logged to Applications and Services Logs\Microsoft\Windows\ModernDeployment-Diagnostics-Provider\Autopilot
Check the registry
Still looking for more information? OK, there’s one last place we can look to see what’s going on. The Windows registry. You can find information about policies Intune is applying to the device at: HKLM\Software\Microsoft\PolicyManager\Providers.
From there, you can find policies that are being applied using these keys:
- For device policies: HKLM\Software\Microsoft\PolicyManager\Providers\default\Device
- User policies are at: HKLM\Software\Microsoft\PolicyManager\Providers\SID
Troubleshooting examples
Here are a couple examples of how to put all this together.
My narwhale won’t go away
In my lab I have some machines set up to run Windows Insider builds along with the pre-release versions of M365 apps (formerly O365 apps), and the Microsoft Edge browser. This lets me see and play with…err learn about…new features coming to both the operating system and the productivity tools I use the most. Cool stuff, but I don’t want to confuse those devices with my regular production deployment devices, so I change the desktop picture to one from Windows Insiders.
Today, I want to change the desktop background because it’s time for Ninja Cat to jump off the bacon stabbing narwhale and onto something cool like a Windows Insider dragon instead. Yes. Yes, I have been watching Game of Thrones again.
Anyway, I create the policy and push it out…nothing changes on my pilot devices. What gives? Let’s find out. Go to the policy and look at the device status (this is one of those operational reports we talked about earlier). Do you see what I see? Conflict. Ugh. That means I have two configuration profiles trying to set the same settings with different values. We’ll have to manually de-conflict this.
Sometimes you’ll see multiple User Principal Name column entries for the same device. That’s OK. All that means is the the user was logged on when the policy was evaluated. If a user is not logged on when the scheduled policy sync happens, you’ll see local system listed for the UPN. If multiple people are logged on the device when the policy is evaluated you’ll see all their UPNs listed at the same last status update time.
OK, looking in the device status for the configuration profile, I see there’s a conflict. Now lets drill into the device information and see what’s going on. To do that, just click the device name, go to Device configuration under Monitor and we can see our troublemaking policy. Let’s click on that to see which setting is conflicting, and with whom.
As suspected, the desktop picture is the conflicting setting. Who’s it conflicting with? Let’s click Conflict with 2 profiles and find out:
There we go. Apparently, I’d forgotten there was already a configuration profile out there to set the Windows 10 desktop to the narwhale stabbing bacon. When two configuration profiles conflict, the admin must go manually de-conflict them.
And because we know that the desktop background is configured under Personalization in a device restrictions configuration profile, this can easily be resolved and Ninja Cat Mother of Dragons will finally take her place on the desktop for all my Windows Insider build devices.
My CSP is Spacey
Something that I recommend a lot is enabling Azure AD self-service password reset (SSPR). That process is actually an Azure AD task, but they’re nice enough to document the custom Intune policy needed to put the option on your managed devices here: Enable Azure Active Directory self-service password reset at the Windows sign-in screen. Of course, if you read my earlier blog post about how to figure out the OMA-URI path for custom policies you’d already know all that. Just saying.
Anyway, all that really matters is that we know to enable SSPR from the Windows 10 login screen: we need a custom Intune configuration profile setting AllowAadPasswordReset to 1. That setting’s full OMA-URI path is of course ./Vendor/MSFT/Policy/Config/Authentication/AllowAadPasswordReset. Too easy.
I know those OMA-URI paths are case-sensitive, so I’ll take my time creating the policy. After deploying the policy, I sync a few test devices and check to see if I can reset my password from the login screen. The option isn’t there. I guess that figures as this is a troubleshooting post. Let’s go see what happened in the MEM admin center.
Looking at the device status for the SSPR policy, I see one of my usual suspects is acting up again. Drilling down into the configuration profile information for the device, I can see what’s going on. Is it conflicting again? No, it’s a full-blown error this time.
Look at those error details “Remediation failed”. I’m going to need a little more to go on to fix this.
Time to do some device-level troubleshooting. Maybe the event logs will tell me something. Yep, see it? There’s an extra space at the end of the OMA-URI path. Not only are those OMA-URI paths case sensitive, but every space in the path matters—even trailing spaces.
Back in the portal, this should be an easy fix. Just delete the extra space at the end of the policy and re-sync the device.
And happy days are here again.
Since we’re on the device already, we might as well go verify in the registry what’s going on too. Here lie the policy settings in the Windows registry that make all this happen:
By default, the SSPR setting is also stored in the registry here:
And that’s how to troubleshoot Intune managed Windows 10 devices. Hope it helps.
You’ve seen my blog; want to follow me on Twitter too? @JeffGilb
