endpoint manager assignment failures

Introduction To The Series

You have enrolled your endpoints into Microsoft Intune, you’ve configured policies, and you are managing your devices. What’s next? How do you validate your endpoints’ management states, and how do you track the health of your endpoints over time?

In previous posts we here at Model Technology Solutions have talked at length about the capabilities Intune provides for managing endpoints & operating system updates, endpoint configuration, application deployment, and more.

This series of posts will focus on another important element of endpoint management – reporting, or, the ability to understand current and historic data about your endpoints’ actual state and the results of your management configuration.

This series will cover:

• Intune’s reporting approach
• Capabilities provided out of the box
• Methods of using Intune’s data to perform advanced reporting

This knowledge will enable you, as an Intune administrator, to better utilize the wealth of data contained within the Intune service for the benefit of your organization.

This series is for Intune administrators who want to better utilize the wealth of data contained within the Intune service to benefit their organization through increased visibility into and understanding of their endpoint devices’ state, as well as aiding with improving configuration and addressing potential security holes.

One important caveat – all information in this post is based on the current state of Intune as of January 2022. While the core Intune reporting structure is likely to persist well into the future, specific details of report names and locations may shift over time.

Intune Reporting Overview

Microsoft Intune – a core component of Microsoft Endpoint Manager – is Microsoft’s modern, cloud-based platform for managing endpoint devices and applications. Intune contains a wealth of data on the endpoints it manages, all of which is available in various ways for administrators to use in managing Intune and the endpoint configuration. Microsoft has established and defined a framework for how that data is exposed within Intune to ensure the data administrators need is close at hand alongside their management activities.

This framework not only defines several types of reports by their intended usage, but allows the reporting data to be made available throughout the Intune environment in places intended to be easily accessible and relevant to the specific report types.

An important takeaway from this is that the “Reports” node in the Intune navigation menu is not a holistic collection of all of Intune’s reporting data.

This is unfortunately a common point of confusion for Intune users, and an understandable one at that. It would make sense that all of the reporting data would be found in a node called “Reports”…but in reality that is only a subset of the available data.

The following sections will discuss the various types of reports that comprise Intune’s reporting framework, the intent for each type, and where that data can be found in addition to the “Reports” module.

Types of Reports

The Intune reporting framework defines four types – or focus areas – of reports:

• Provides timely, targeted data that helps you focus and take action.
• Admins, subject matter experts, and help desk technicians will find these reports most helpful.
• Provides a broader summary of an overall view, such as device management state.
• Managers and admins will find these reports most helpful.
• Provides patterns and trends over a period of time.
• Allows you to use raw data to create your own custom reports.
• Admins will find these reports most helpful.

In part one of this series, we will cover only the Operational Reports category. The remainder of the categories of data will be featured in future posts.

Where to Find Reports

As noted above, reports are found in different places in the Intune portal depending on their type and intended usage.

Operational reports comprise the majority of the reports available in Intune today. These can be found in numerous places throughout the Intune portal and can be grouped into three categories:

• Overview reports
• Monitor reports

When navigating through the Intune web portal, almost every section initially loads an “Overview” or “Summary” page which displays a set of reports as tabs in the workspace – these are the “Overview” reports.

Furthermore, each section has either a link labeled “Monitor”, which loads a list of reports, or a category of views labeled “Monitor”, under which additional reports are listed. Essentially, everywhere in the Intune portal that lists “Monitor” is a collection of the “Monitor” reports.

Finally, the main Intune node titled “Dashboard” is where Dashboard reports can be found, including the pre-configured Intune overview dashboard and any custom dashboards created by administrators.

Organizational and Historical reports can be found in the “Reports” node in the Intune navigation menu. These reports are grouped into several categories and provide broader views of the organization’s managed endpoints and management state.

“Specialist reports” refer to the abilities exposed by Intune for creating custom reports. This data can be accessed via the “Reports” node in the Intune navigation menu in the categories labeled “Intune Data Warehouse” and “Azure Monitor”.

The following sections will go into further detail on the different types of reports and, most importantly, how to go about configuring custom reports.

Operational Reports

As noted above, Operational reports are located throughout the Intune web portal and are intended to provide timely, targeted data within the context of the administrator’s current actions.

For example, Operational reports about Device state can be found in the Devices node alongside the tools for configuring device policy.

Overview Reports

Overview reports can be found at the top level of the Devices and Apps nodes in the Intune portal. These depict a collection of actionable and summary information about the state of managed devices and apps, providing administrators with immediate access to key information they need. These reports also alert the administrators to specific issues they may want to address.

In the Devices node, the Overview report contains four separate tabs, each displaying one or more reporting tiles with summary information, including:

• The “Enrollment Status” tab displays the counts of Intune enrolled devices by operating system, the enrollment failures by operating system, and the top enrollment failures in the past week.
• The “Enrollment Alerts” tab displays a list of any active alerts generated from enrollment issues.
• Counts of managed devices by their compliance state.
• Counts of managed devices broken into Compliant and Non-Compliant for each assigned Compliance Policy.
• Number of devices without Compliance Policies assigned to them.
• Compliance settings with the highest number of non-compliant devices.
• The “Configuration Status” tab displays the counts of users and devices by configuration profile application status and the profiles with the highest count of deployment errors.

In the Apps node, the Overview report contains two separate tabs with reporting tiles, including:

• The “Installation Status” tab displays the applications with the highest counts of installation failures by device type and the total count of applications with installation failures.
• The “App Protection Policy Status” tab displays the total count of users who have been assigned application protection policies which are grouped by whether they are licensed or not, along with the count of users that have been flagged from application protection policies.

In both of these Overview reports, clicking on any of the reporting tiles drills down to specific Monitor reports with further information on the topic at hand.

Additional Overview reports can be found in the Endpoint Security node when selecting several of the options in the “Manage” category. These are functionally similar to the Devices and Apps Overview reports in that they may have multiple tabs of data with reporting tiles displaying high-level state information for administrators, though they also share the workspace with the interface for configuring the relevant endpoint security policies.

The specific reports at the time of writing include:

• The “Summary” tab displays the counts of unhealthy endpoints by category, along with the count of active malware in the environment.
• The “Unhealthy Endpoints” tab displays a list of all endpoints suffering from malware infection.
• The “Active Malware” tab displays the identities of all active malware detected on managed devices.
• The “Summary” tab lists the count of devices with the firewall turned off.
• The “MDM Devices Running Windows 10 or Later with Firewall Off” displays the list of specific devices with the firewall turned off.

Monitor Reports

Monitor reports can be found at various locations within the Devices, Apps, and Endpoint Security nodes, providing more detailed information beyond that which is listed in the Overview reports.

Each of these reports provide the ability to search across the displayed columns, modify which columns are displayed, sort by any column displayed*, and export the data to CSV format for further exploration in Excel or other data analysis tools. Furthermore, items in each report can be clicked through to review the specific item’s details, providing access to further information that may be relevant for the report.

*Note: At the time of writing this, most Monitor reports allow sorting by every column available, however some reports do not. Microsoft has stated that their intent is to allow sorting of all columns and they are slowly rolling that out across the range of Monitor reports found in Intune.

In the Devices node, there is a dedicated Monitor link that loads a collection of reports, organized into categories named “Configuration”, “Compliance”, “Enrollment”, “Software Updates”, and “Other”. The following reports can be found there:

• The “Assignment Status” report lists the counts of devices with errors, conflicts, or pending statuses for each Configuration Profile.
• The “Assignment Failures” report lists the count of devices with errors for each configuration profile with assignment errors. Clicking through a profile provides more information on the specific devices that have failed.
• The “Devices with Restricted Apps” report displays a list of devices upon which applications configured as restricted are currently installed. This report helps administrators quickly identify the users to contact and devices to align with organizational policy on restricted apps.
• The “Encryption Report” lists each managed device along with their readiness for encryption, TPM chip version, and OS version. Individual devices can be clicked through to display the name of the profile applied to the device to enforce encryption and the status of the profile deployment.
• The “Certificates” report lists the status of all certificates that have been deployed to devices from Intune.
• The “Noncompliant Devices” report lists information for all devices that are in a “Not Compliant” state. Clicking through on a device pulls up the device’s full information in Intune for further analysis.
• The “Devices without Compliance Policy” report lists devices of any operating system for which no compliance policy has been assigned.
• The “Setting Compliance” report lists, for each setting enforced by any compliance policies, the counts of compliant and noncompliant devices. Each setting can be clicked through to list the specific devices that are not compliant for the setting.
• The “Policy Compliance” report lists, for each compliance policy, the counts of devices that are compliant, noncompliant, or have errors with the policy’s contents. Clicking through a policy lists the specific devices that are not compliant or have errors.
• The “Noncompliant Policies” report lists, for each compliance policy that has noncompliant devices, the counts of devices that are noncompliant or have errors with the policy’s contents. Clicking through a policy lists the specific devices that are not compliant or have errors.
• The “Windows Health Attestation Report” report provides a collection of key Windows health metrics for each managed device.
• The “Autopilot Deployments” report lists all Windows Autopilot-driven device enrollments within the past 30 days.
• The “Enrollment Failures” report prompts for the selection of one or more users, then lists enrollment failures logged for the selected users.
• The “Incomplete User Enrollments” report provides further details for enrollments that were initiated but failed to be completed, listing at which phase of the enrollment process the enrollment was ceased, among other related data.
• The “Per-Update Ring Deployment State” displays, for each configured update deployment ring, the count of devices with errors, which devices failed to be updated, and which were updated successfully. Clicking through an update ring loads the relevant configuration page for the update ring along with an Overview report listing further status information for the update deployment.
• The “Installation Failures for iOS Devices” report lists iOS devices for which update installation failed and provides additional details on the failures.
• The “Feature Update Failures” report lists, for each configured Windows feature update deployment, the devices with errors from the update process. Clicking through a feature update deployment provides a list of the specific devices which generated errors.
• The “Windows Expedited Update Failures” report lists, for each configured expedited Windows update deployment, the count of devices which failed to install the update. Clicking through an update displays a list of the specific devices which failed.
• The “Device Actions” report lists a log of the device actions triggered within Intune for managed devices, along with the user initiating the action and the action’s result.

In the Apps node, there is a dedicated Monitor link that loads a collection of reports, described as follows:

• The “App Licenses” report is used to track consumed and available licenses for applications for which license tracking is managed in Intune.
• The “Discovered Apps” report provides a holistic list of all applications discovered on all managed devices. Clicking through an application lists the specific devices upon which that application has been found to be installed.
• The “App Install Status” report lists, for each application, the install failure percentage, along with the counts of install failures for deployments targeting devices and users.
• The “App Protection Status” report lists the count of all users that have been assigned application protection policies, broken down by whether they are licensed or not. Additionally, it lists the counts of flagged users and users with potentially harmful apps. Furthermore, it provides links to download more detailed app protection reports for iOS & Android, for Windows Information Protection without Enrollment, for Windows Information Protection via MDM, and for Application Configuration.

In the Endpoint Security node, a single Monitor report can be found at this time:

• The “Assignment Failures” report lists the count of devices with errors for each configuration profile with assignment errors. Clicking through a profile lists more information on the specific devices that have failed. This is the same report that is listed in the Devices -> Monitor section and described above.

Many of the reports listed are currently in “Preview” mode and may see changes and expansions of capability before they are fully released.

Intune’s Dashboard reports are accessed via the Dashboard node in the navigation menu. This view is a pre-configured version of the standard Azure Dashboard functionality with a number of tiles listing key information about the Intune environment.

This dashboard can be rearranged and can have tiles removed, though very few tiles exist to be added which aren’t already present on the pre-configured dashboard.

Custom dashboards can also be created, though they are limited to the existing tiles, again, most of which are already present on the pre-configured dashboard. Still, this can be used to create more targeted views for specific subsets of Intune administrators.

Additionally, the reporting tiles link to relevant Monitor and Overview reports throughout the Intune interface, providing easy access to configuration options.

The data listed by default on the pre-configured dashboard includes:

• Device enrollment status and count of enrollment failures in the past 7 days
• Device compliance status and count of noncompliant devices
• Device configuration status and count of policies with errors or conflicts
• Client apps status and count of apps with installation failures
• App protection policy user status per operating system
• Count of Intune-enrolled devices per operating system
• Count of devices per device compliance status
• Device configuration profile status and count of users and devices by status, along with a weekly trend

More Coming Soon!

This is just the first of multiple posts in our Intune reporting series that are going to be coming out in the next month or so. These posts are going to continue to explore the different places that data can be retrieved from Intune and how to utilize it to gain valuable insights into the state of your endpoints and improve security.

The level of granular data that Intune provides with which to make improvements, decisions, and policies is by-far some of the best in the industry. Gartner agrees. We’re committed to supporting IT pros to fully utilize these tools for which they’ve already paid and gained access. We write posts like this as part of that support, to enable administrators like you with the knowledge and power you need to ensure your infrastructure is as secure and efficient as possible.

If you haven’t already done so, sign up for our email list to get the other posts in this series in the next month. If you’re already on it, just stick around. We’re committed to taking you as deep as possible into this software so that you know exactly what’s possible and how you can use Intune’s data for the betterment of your company and the improvement of your endpoint management.

Related Posts

The essential role of intune management and patching strategies in healthcare it.

Apr 17, 2024

In healthcare IT, the management of devices and applications is paramount, more so today as IT...

Manage Multi-Cloud & Hybrid-Platform Server Resources With Azure Arc + Automanage

Oct 16, 2023

Azure Arc and Automanage are two services Microsoft has developed to address common challenges...

[Case Study] Helping a Leading Healthcare Data and Analytics Firm Boost Their Cybersecurity and Get More Business

Aug 7, 2023

When it comes to patient health information, more security isn't just better, it's must. As...

Save Hours Of Work With Our Full Intune Reporting Guide

Like this post? Download our entire Intune Reporting Guide to access difficult to find reports and save hours getting the data that you need.

• Best Practices
• Licensing FAQ

Devices or Users: When to target which policy type in Microsoft Endpoint Manager (Intune)

A new reader question came across my desk the other day. In truth, it is not the first time I have answered this question, but I realized that I could probably repeat myself less if I simply write an article and publish it. The question is:

When working in Microsoft Endpoint Manager (Intune), how do I determine whether to assign policies to devices or users?

Before we describe the best practices here I think it is important to review a little bit of information about security groups. Groups in Azure AD come in five flavors:

• Microsoft 365 Groups (Users only)
• Static Security groups comprised of Users
• Static Security groups comprised of Devices
• Dynamic Security groups comprised of Users
• Dynamic Security groups comprised of Devices

First, just know that you should use Security groups to assign policies and profiles within Intune (I would not use Microsoft 365 Groups). Eliminating that option right off the bat, let’s narrow it down further by determining when it would be best to recommend targeting Users vs. Devices.

Unfortunately, there is no one size fits all here; so we have to give the classic consultant answer: “It depends.” On what does it depend? A couple of factors:

• Are you trying to control an experience based on who the user is, or what device they are using?
• What type of policy or profile are we working with?

Let’s start with the second question first. The type of policy or profile you are working with may answer the question for you.

Compliance policies

When it comes to Compliance policies, I always target users. Is it possible to assign a compliance policy to a security group comprised of devices? Yes. But I do not recommend it. If you assign these policies to devices, you will find that there are two compliance results for every device (well, actually three if you include the built-in policy).

• The “system account” will receive a compliance status
• The user who signs into the device will also receive a compliance status

Unfortunately, this can lead to errors when it reports on the overall compliance of the device. I have even seen strange occurrences where both the user and the system account showed up as ‘Compliant,’ but the built-in compliance policy showed as ‘Not Compliant.’ This is even more confusing because literally the only thing that policy is measuring is whether there is a compliance policy being applied (and obviously there is ). Because of these inconsistencies and issues, I do not recommend assigning Compliance policies to devices. Also notice that we are not given the option to assign to “ All devices ” but only “ All users ” (unlike Configuration profiles).

In general, I like to think of Compliance policies as the bare minimum that you would require for ANY endpoint to connect and start working with your systems. And so I do not have different compliance requirements for different types of devices. Whether they are corporate, personal, etc.–it doesn’t matter. Therefore I would normally just create one compliance policy for each device platform that I support, and then assign these to All users , or at least a security group that represents all of my licensed users (the members who are licensed to use Intune).

Device Configuration and Endpoint Security profiles

Next up: Device Configuration profiles (including Update rings ) and Endpoint Security profiles. Here we return to our first question: Are you trying to control an experience based on who the user is, or which device they are using?

So the obvious use case for targeting devices is something like kiosk devices, or lab computers. No matter who sits down and logs into that machine, you want the experience to be identical. And it may be a different experience than what is expected when the user is picking up their own device (even to work with the same applications). In that case, you would want to create a device-based security group and apply the profiles accordingly.

Another use case for device targeting (using a Dynamic group) is where you have an organization that is managing a mix of corporate-owned and personal devices within the same device platform. For example, you might have corporate owned iPhones and some personal iPhones. In that case, there are likely different requirements for the one group versus the other. For example, your corporate profile might block manual unenrollment, whereas the personal profile would not.

Therefore, it makes sense to create two dynamic security groups: one that applies to deviceOwnership = Personal and the other to deviceOwnership = Company . When you assign your BYOD profiles, you would target the former group, and when you assign company profiles, you would target the latter.

One of the downsides to using dynamic security groups is that I have noticed it can sometimes take extra time (minutes to hours) for the membership to update. This normally isn’t too big of a deal and often will go unnoticed. But there are likely to be some helpdesk calls in your future that are resolved by nothing more than “waiting it out.”

Applications

Pretty much the same logic can be applied when you are assigning applications to devices. Should this user get the same applications regardless of which device they use? Or do they get a different set of apps depending on which device they are interfacing with?

The only thing to be mindful of is the difference between apps that you deploy as Required versus apps that you deploy as merely Available .

If it is a Required application, it means that the app is not just ‘available’ in the company app store, but it will be automatically and forcefully installed over the air (the user has no choice in the matter). You will notice that in the case of Required , you can assign the application to devices or users, but for Available applications you may only assign those to users .

Generally speaking, I would only assign to the device in the instance of a kiosk or lab situation. Otherwise I target the users.

App protection (MAM)

Remember that App protections policies (a.k.a. MAM) can be used either with or without enrollment of the actual device. This already implies that you should be targeting user objects rather than device objects. When a user signs into an application, these policies are applied at the application layer, and the device does not really play into the equation.

Conditional Access

Similar to Compliance and App protection policies, I always target users here, and not devices. The first thing to note is that when you use the device-based controls such as Compliant device and Hybrid Azure AD Joined device , this will already cover the distinction between managed and unmanaged endpoints. I am usually only interested in restricting access if I have less control over an endpoint (or its applications in the case of MAM).

The second point is that when Conditional Access is being asked to evaluate device compliance, I like to have this tied to the same group of users for whom compliance is actually being measured. The devices are not being targeted by my Compliance policies, and therefore I will not be targeting the devices with my Conditional Access policies. I will target the appropriate users in both cases (e.g. those who are licensed to use the features).

Autopilot profiles

When you assign Autopilot profiles, the advice is the opposite from Compliance and Conditional Access. Here, the profiles are only assigned to devices , not users. Notice again that we can select specific device groups, or just choose All devices (but there is no All users option).

And that makes sense. Autopilot is all about pre-provisioning devices . While there is a lot more to autopilot, for the purposes of this discussion, this is all we have to say about it.

So there you have it, clear as mud, right? This graphic is a summary:

And in case you are curious about my “standard approach,” I normally target users for the majority of my policies and profiles (except Autopilot of course). I find that this keeps it very simple for SMB’s. For example, it is almost always the case that Windows devices are company-owned, while mobile devices are personal/BYOD. Therefore I just have BYOD-friendly policies assigned to all of the users to support their mobile devices (and macOS where the need exists), and then I have a ‘corporate’ baseline for Windows computers that I likewise apply to all the users . I normally only allow web access on personal Windows devices (if at all).

Nevertheless in some cases it becomes important to distinguish between personal and corporate devices. In those cases I would recommend using the dynamic device groups to tailor the policies to the BYOD vs. company-owned groups, as appropriate.

Comments (33)

This was much appreciated and overdue, thank you!

Nice overview thanks. I got caught the first time i looked at App Protection Policies and had them assigned to my dynamic device group until i realized they only work with users. MS could do better here by restricting or having more tool tips when selecting groups i feel.

Thanks for sharing this. I am curious What you target (compliance but also device config) policies to when it involves shared win10 devices where multiple Users log in and in “theory” receive the same policies.

Whether you apply to devices or users won’t matter if they should receive the same policies anyway. Just note that we have seen issues with compliance assigned to devices instead of users.

For testing my BYOD Conditional Access and App Protection polices I applied them to a user group. I now want to apply to everyone in my organization. I created a dynamic security group that contains all users with an email address. I switched my Conditional Access and App Protection policies to use this group, but the policies don’t seem to be getting applied. Do Dynamic groups not work with these policies?

The only dynamic user groups I have used so far have been based on other attributes such as Department field, and I haven’t had any issues there. But, if targeting all your users, just assign to “All users” and exclude the stuff you don’t want such as guests and emergency access accounts. That’s what I do for my baselines (policies that are applied broadly to everyone).

Alex, every time I read one of your posts it happens to be a question where I am struggling to determine the best approach.

What about MDM Security Baselines? Would you target them at users or devices… if device groups then you end up with the system account and user account both appearing in much the same way as for compliance policies… but if applied to “All users” or a user group how do you avoid it applying to BYOD?

Couple of things: The MDM baselines are a bit messy in my opinion, because they don’t actually save me time or headache in management down the road, in fact they add to the headaches typically, because I almost always have to create custom policies anyway, I generally use these as a guide for creating those policies myself. Now, even so, it is still okay to have the system and user account both showing up, it is just that with Compliance policies I have found this to be more impactful to users when it can’t decide whether a device is compliant or not. Therefore I always have to target users for compliance. The same effect is not a concern with baselines (which are basically applied the same way as config profiles or endpoint security profiles).

Great post on a subject that is critical but rarely discussed. The MS documentation is completely lacking. Question: How would you recommend controlling aspects of the user experience prior to logon (ie; guest access. wifi) in an environment where devices are shared. Is this a use-case for a policy tied to a device group?

Device config profiles can be assigned to device groups, yes. There is config template specifically for shared computers also.

Hey Alex, Awesome write-up. The best I’ve found yet on this topic.

We’re struggling with compliance in Intune. Our employees have both BYOD and company devices, and we have different security requirements for each scenario. For example, we don’t want to enforce BitLocker on BYOD machines.

We want to take your advice to deploy compliance policies to user groups. We have seen more accurate results this way. But given that our users have both company and BYOD devices, it seems that our only option is to deploy separate compliance policies to a “BYOD” device group and to a “Company Device” device group.

Do you know of a good way to tackle this scenario?

Yes. Right now the solution is to ask your compliance policies to do less, and your config profiles to do more. E.g. do not enforce BitLocker via Compliance but rather config profile assigned to corporate devices.

Great article, Alex. I was wondering one thing, if our W10 devices are AAD hybrid joined and we apply InTune policies based on users and these users are signing in with on-prem AD accounts, the policy seems to still apply to other users who sign into the PC after them (e.g. device control policies). From what I can see, even policies targeted at users get added to the HKLM registry hive instead of just the current user. Am I right?

When you have shared computers there are additional considerations. There is a policy template that you can deploy specifically for shared computers for example. By default Intune expects 1-1 user to device assignment unless you explicitly tell it that the machine is shared or kiosk.

Thanks for the reply, Alex. I was wondering how other organizations might manage this scenario on dedicated-user W10 devices when an admin needs to connect to perform some tasks that might need to bypass an InTune device control or config setting that’s been applied to the primary user. Historically, we’d manage this with GPOs that would not apply to certain admin accounts.

Great read, thank you for your time.

We are trying to achieve… “If device isn’t within a trusted zone or isn’t setup with bitlocker then block access” basically we would like it so any “static devices” (PC’s) Will be blocked access if they leave the “trusted zone” but we have a handful of laptops which we are happy to access office 365 resources IF they are configured with bitlocker.

Now I wasn’t sure how to handle the compliance policy/configure conditional access. Multiple users have both PC’s within the office and laptops they’ll use remotely. Making me unsure what to target at device or user level. Can anyone suggest the best way around this?

Compliance policy for Windows 10 and later (and these are always targeted to Users): the compliance policy should require BitLocker and other settings you would like enforced, I would also suggest you include a grace period of at least 1 day (under Actions for noncompliance). Your CA policy would be for Windows device access, and the parameters would target the same users as your compliance policy, and for cloud apps I assume you would be selecting just Office 365 in this case. Then you can optionally use the conditions to include any location, excluding your trusted locations. You must include just the Windows devices from Device platforms. As well, you can choose whether you want this applied only to client apps or also to browsers. Then your access control would be configured to require device compliance. That would give you the result described.

Awesome article…

For Windows 365 Cloud PC’s I assume some security polices like Bitlocker and Windows Hello account protection are not needed . Would you just set the assignment to all devices but then exclude a dynamic group of CloudPC’s? Since you can’t use filtering in Endpoint Security you would have to target Devices.

Similarly for Compliance policies, you would want a separate one for CloudPC’s so would you create a kind of cross cross assignment…

Physical device compliance policy –> All users –> Filter out CloudPC’s (device.model -contains “CloudPC”)

CloudPC’s device compliance policy –> All users –> Filter out non-cloudPC’s (device.model -notContains “CloudPC”)

It seems like you can mix and match users / devices if using filtering so this would allow user assigned compliance policies to makes things less prone to errors but still apply different compliance policies to different user devices.

Thank you for the article Alex. I am quite new to InTune and am struggling with having a different setup for a different satellite location where the rules, apps and mandatory URLs will be different. I enrolled about 100 iOS devices under a Dynamic Device group and it seems that i might need to change it to an “Assigned User” so when user A enrolls all the devices it will know which profile to pull. Changing membership type from Dynamic Device to Assigned User, would it un-enroll the existing devices? In AirWatch that i previously used, I was able to create organizations and enrollment users assigned to those organizations, so it will know automatically which profile to load based on that user, but haven’t figured this out yet in InTune and appreciate any insight you might offer.

Thanks for the article, Alex.

For Attack Surface Reduction rules – Go with User or Device Groups?

Device seems like it makes more sense but it comes up with numerous errors regarding System accounts, so User is the way to go?

This article is a tad outdated as there are some additional options/considerations now with device filters and so on. But in general, I will always prefer to target users unless there is a specific requirement not to (i.e. controlling experiences because of what the device itself is as opposed to who the user is–as in kiosk devices or “lab” or “classroom” devices).

Hi, is there any danger of using user assigned groups to other devices? I have configured profiles, policies etc for Android enterprise fully managed devices, however when I use dynamic groups the pin is not enforced during enrollment and it only shows as an update in the intune app on the phone afterwards which means the user can just bypass setting up a pin. I can’t get around this and even microsoft states this is the case. When I use user assigned gourps eveything works perfectly during enrollment, however I am worried that these configurations and policies will follow the users onto other devices for example personal devices with the company portal on them. This has happened n the past on apple devices and a s a result a personal device was wiped. I have tested this for Android and there doesn’t appear to be any effect but I don’t want 1000 devices going out with this as a risk.

You should assign to user groups whenever possible. Nowadays you can use device filters to target or exclude devices by ownership. For example you can have a device filter to exclude personally owned devices so that you can say “This policy applies to all users except on personally owned devices.”

Interesting. One thing this doesn’t address is multi-user devices. There is still no apparent way to have/register a device as compliant, then have conditional access (MS docs specifically say Conditional Access isn’t possible as a feature for some unknown reason) to limit Compliant devices to be able to use MS Cloud apps. Then it seems a mystery how to just register a multi-user device, think conference room shared computer where all ADS users need to login and do work but the device needs to be compliant and multiple users that somehow doesn’t catch all users/devices in the trap. Found no way to workaround and have Conditional Access based on compliance for a shared computer without hosing up all users and blocking access. Any ideas on this appreciated. Objective is to limit not just users using MFA to O365 cloud app, but also, a CA policy that requires a device to be marked as compliant…AND it is a shared device. The rest works. But as soon as you try to setup a shared device, you are just blocked and not way to have Devices or Groups of devices as part of CA, it isn’t an option. Thx

Great article, this is exactly what I needed. but I’m a bit curious about why you don’t recommend office 365 group? I just stepped into a cloud admin position and I’m doing some cleaning up on intune, updating some policies and configs. They’re 100s of dynamic groups in there for all departments in over 40 locations and they are all Microsoft 365 groups. and 1 device group per location which most of the policies are applied to. Should I create new dynamic security user groups and reassign those policies since you don’t recommend 365 groups?

Microsoft 365 groups are not meant to be used for security policies, but rather to give access to specific types of Microsoft resources (groups). It is a special type of group that provisions a site, and other resources (e.g., optionally you can “Teamify” the group to create a team in MS Teams). To assign policies to users or devices you would normally create security groups for that purpose. The only time I ever assign to device groups rather than user groups is if I am trying to target something about those devices specifically like if they are kiosks or lab computers that should be treated differently from other devices. Otherwise, security policies, apps, etc. I will always make “user-centric,” and the groups then usually contain users not devices.

What is the recommendation for ASR rules for today? I feel like everything points to device assignment rather than user for this one.

i disagree with never targeting devices with compliancy policies. what if your compliancy policy is make sure bitlocker is enabled and secure boot is enabled too. if you target a user that a laptop and a desktop and perhaps one is older and cant do secure boot. now the user is not compliant correct?

Couple of notes on this: in the early days, it was not even possible to assign Compliance policies to devices, you HAD to target users only. Then eventually they made it so you can target devices, but I ran into all kinds of problems with it. So that is why, at the time (this article was written back in 2021), I advised against it. These days, it may be working better for folks, and it is of course supported, if you have the need. Last comment: hopefully nobody still has devices that old, which cannot use BitLocker or Secure Boot :)

Microsoft Cloud PCs and many Virtual machines are a good example of devices that do not support Bitlocker. The only method I can think of is to create a filter for those devices, target devices and filter exclude those. If you were to target users, then they would be included.

Hi Alex, What do you recommend if deploying a wifi policy to user or device groups?

What would happen if i were to deploy baselines on both user and device groups?

Leave a Reply Cancel reply

Related posts, a simpler conditional access baseline, reader question: can i sync my network drives to teams.

Understanding Cross-Tenant Access Settings: Inbound & Outbound Settings Vs. Tenant Restrictions

Migration paths to microsoft 365: devices before data, updated licensing graphics, managed services opportunities within microsoft 365, understanding file server migrations to microsoft 365, how do you deal with the unreasonable storage limits in sharepoint online, u.k. cyber essentials simple assessment tool, is “best practices” a myth, helping it consultants succeed in the microsoft cloud, have a question contact me today..

Intune error codes and solutions

Mattias Melkersen Kalvåg

• September 29, 2022
• Return to our Tech Blog

Blog » Intune error codes and solutions

Are you managing Intune? Maybe you just started, or maybe you have been working with the product for a long time. Nevertheless, we all see stuff where we need to be able to find out what to do with it. In this blog post I will help you out with your error codes, what they mean and how to resolve them.

During the post there will be links to many external contributors, so please give them a huge kudos, for their extensive work.

Updated February 2nd 2024

MEM Sync related errors

The sync could not be initiated (0x80190190).

Symptoms: When attempting to sync policies with Intune from settings it says:

Eventlog says:  MDM Session: OMA-DM message failed to be sent. Result: (Bad request (400).).

What happened? Trust to the Intune backend has been lost and cannot be remediated automatically. Re-enroll your device to solve this issue.

Solve it: You can run this script to  clean up and re-enroll  ( Be aware that this is not supported and will be on your own risk ) It could also be that your device has 2 certificates where you need to clean out the wrong one. See more at Rudy’s blog post  here

Failed to get AAD Token for sync session User Token: (Unknown Win32 Error code: 0xcaa2000c)

Symptoms: We’ve (I guess) all seen this?

When attempting to sync policies with Intune from settings it says: Sync wasn’t fully successful because we weren’t able to verify your credentials. Select Sync to sign in and try again.

Event log says:

If we look into the Azure sign-in logs we would see this message:

What happened? The user you logged on to the device with has MFA enabled (You should always have that). The security control in EntraID were not satisfied and needed the account to authenticate and prove it is you. Only the device portion was synced with Intune.

Solve it: Click on the sync button and authenticate when prompted to do so and this message will disappear. Microsoft has a good reference on the issue here and also a solution model to go around without messing around with security. A side note, this could also be that you have tightened Conditional access too much. Go through your sign-in logs in Entra.

OMA-DM message failed to be sent. Result: (Unknown Win32 Error code: 0x801901ad).

Symptoms: While trying to sync the device it says: The sync could not be initiated (0x801901ad)

What happened? The device was unable to sync because of network connection issues. This can happen if you have no internet, proxy software prohibiting access to internet or a driver issue.

Solve it: Resolve it by authenticate to your proxy software, or update network driver. This solution was provided by Robert Rice .

Windows Autopilot related errors

Preparing your device for mobile management (0x800705b4).

Symptoms: During autopilot the 1st of 3 phases, Device preparation, fails to finish:

Press SHIFT+F10 to look up the error. Navigate to the eventlog and this case it says (Unknown Win32 Error code: 0x82aa0002) which indicated that it is related to co-management. Someone setup a configuration for the device to install the Configuration Manager agent during autopilot.

What happened? This error means “Time-out” and it was not able to get further in the process. Something stopped the device from proceeding to the next phase.

Solve it: We also see an error (Unknown Win32 Error code: 0x86000022) which is related to configuration manager “The specified node doesn’t exist.” Check your CMG works and try again or remove the co-management profile assignment and try again, you will see it go through its stages like it should. There could be many other problems when you see this issue. See more here And also here

This device is already enrolled. You can contact your system administrator with the error code 8018000a.

Symptoms: During autopilot the device fail right after providing credentials:

What happened? This error means the device already enrolled to Intune. This could be due to error while provisioning the device, but it actually went through some of the process. In such scenario a device would typically be stuck.

Solve it: 1. Go to intune.microsoft.com and delete the serial number of the device 2. Go to portal.azure.com and remove the EntraID object corresponding to the Autopilot registration. 3. re-register the device to the autopilot service. Your user can start over and enter their credentials into the device and Autopilot will proceed as expected.

This feature is not supported. Contact your system administrator with the error code 80180014.

Symptoms: You are at the OOBE page and want to logon to your device. You think it should go through autopilot, but it fails.

If we take a closer look at the autopilot object we see that it seems to be a personal device.

1. To find out what happens in Intune go to Endpoint -> Devices -> Monitor -> Autopilot deployments (preview)

2. Go to the event log on the failing device. Shift + F10 -> eventvwr.msc -> Applications and Services Logs -> Microsoft -> Windows -> DeviceManagement-Enterprise-Diagnostics-Provider -> Admin

What happened? This error means the device cannot enroll as the platform or version is not supported. This is typically because there are configured enrollment restrictions in your tenant.

Solve it: To solve it, register your device to Autopilot as in this case, the device is considered as a “Personal” device, and device restrictions in this environment does not allow “Personal” devices to be enrolled.

Apps (0x81036502).

Symptoms: You are running through Autopilot and your installation fails during Device Setup.

If you navigate to the IME log you will be able to find the installation and why it failed.

What happened? This error means the IME waited for a process to finalize but the process did not return with expected error code. 1603 is fatal error and can be many things.

Solve it: Test your application thorough before you use it with Autopilot and make sure it is robust.

Account setup failed

Symptoms: While autopilot is running, you will see the account setup fail

Tip to quickly see if your user are licensed:

What happened? This error could be many things but normally it comes down to the user that enrolling the Autopilot not having a Intune eligible license assigned.

Solve it: Assign license to the user account and rerun the autopilot provisioning. This solution was provided by Matias Magnus

Configuration Profiles related errors

(./device/vendor/msft/policy/configoperations/admxinstall/receiver/properties/policy/fakepolicy/version), result: (the system cannot find the file specified.)..

Symptoms: When looking at the eventlog DeviceManagement-Enterprise-Diagnostics-Provider it says:

What happened? The “FakePolicy” is created to detect if a certain patch is present on Windows, and will be removed automatically once machines are ready to consume the new ADMX versioning feature. Reddit has an article on it here

Solve it: Nothing to do. It is normal behavior of any Intune managed devices.

Application related errors

Logonuser failed with error code : 1008.

Symptoms: You look into the IntuneManagementExtention.log and a code: AAD User check using device check in app is failed, now fallback to the Graph audience. ex = System.ComponentModel.Win32Exception (0x80004005): An attempt was made to reference a token that does not exist .

What happened? This error occur on perfectly fine enrolled devices, and you should not put any effort in to fix this as there are no fix disposal. If I find a reason or get more information from Microsoft, I will propose a solution here.

Windows Update related errors

Expedite client missing.

Symptoms: You expedited a patch using Microsoft Intune but nothing ever happens to the device(s) you assigned it to. You have waited the hours that should be sufficient for this patch to be expedited but still no results. When you go to the report “ Windows 10 and later Expedited updates ” you see an error in: Update State = Needs attention Update Substate = Needs attention Alert Type = Expedite client missing

If we grab the AAD Device ID and look it up in Azure AD we will be able to find the device.

What happened and how to solve it? This error occur when a device has not been online for a long time. You see the “Device” column is empty which means you will not be able to find it under the “Device” tab in Microsoft Intune. It could happen if a device has not been used for many months and the device cleanup rule removed it from Intune. As the device still exist in EntraID with the Device ID, Intune simply sync that ID to the Windows Update for Business Deployment Service (WUfB DS) in the backend and add it to a WUfB DS audience that will make sure the device is eligible for the patch specified. Once the device become online, it either receives the patch via push (WNS channel) or ask for it via the standard 22 hours sync schedule to Windows update, depending on your configuration. The device does not need to be online for this sync between Intune and WUfB DS to be initiated.

Solve it: Since your device never asked for updates you get this alert and the simple solution is to turn on your device and make sure it sync to Windows Update, and it will start do its magic and your device will be patched (given all prerequisites for expedite has been fulfilled) Also you can re-enroll the device again. You probably should. See more on this troubleshooting guide and deep dive debug with Rudy

Table of Contents

• Categories: Intune , MEM

View profile

Sune Thomsen

Lars Lohmann Blem

Infrastructure architect with focus on Modern Workplace and Microsoft 365 security.

Michael Nielsen

Cloud & security specialist with focus on Microsoft backend products and cloud technologies.

Michael Morten Sonne

Cloud & security specialist with focus on Microsoft 365.

Daniel Britze

Cloud & Security Specialist, with a passion for all things Cybersecurity

Frank van Zandwijk

Cloud and infrastructure security specialist with background in networking.

Henning Hofflund

Infrastructure architect with focus on design, implementation, migration and consolidation.

Martin Vittrup Henriksen

Infrastructure consultant with focus on cloud solutions in Office365 and Azure.

• Add our RSS Feed
• Active Directory (35)
• Analytics (1)
• Applications (1)
• Autopilot (1)
• Azure ad (50)
• Azure ARC (4)
• Azure Automation (1)
• Cloud PC (19)
• Conditional Access (7)
• Cost Optimization (2)
• Deployment (9)
• DirectAccess (3)
• Endpoint Analytics (4)
• Exchange Online (1)
• Governance (5)
• Group Policy Analytics (3)
• Identity (2)
• Intune (51)
• Log Analytics (7)
• Microsoft 365 (26)
• Microsoft 365 Apps (23)
• Microsoft Defender for Endpoint (9)
• Microsoft Endpoint Configuration Manager (14)
• Microsoft Endpoint Manager (16)
• Microsoft Endpoint Manager Admin Center (13)
• Microsoft Entra ID (2)
• Microsoft365 Copilot (1)
• Mindcore Tech (3)
• MS Edge (5)
• OneDrive for Business (5)
• Password Reset (5)
• Password-less (3)
• PowerShell (21)
• Privileged Identity Management (3)
• Remote Desktop (6)
• Reporting (3)
• Retention Labels (1)
• Security (20)
• Sentinel (4)
• SharePoint (5)
• Tenant Attach (3)
• Uncategorized (42)
• Update Compliance (1)
• Update Management (2)
• Virtual Machine (2)
• Windows (56)
• Windows 10 (77)
• Windows 11 (27)
• Windows 365 (18)
• Windows Autopatch (1)
• Windows Defender Application Guard (4)
• Windows Hello for Business (2)
• Windows Server (22)
• Windows Virtual Desktop (5)
• XenApp (31)

Follow on SoMe

• [email protected]
• +45 51 91 44 10
• Lottenborgvej 26A, 2. tv.
• DK-2800 Kongens Lyngby
• CVR. nr. 39 86 20 85

• Privacy Policy

This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

2016281112 (Remediation Failed) error in a custom VPN profile in the Intune admin portal

• 3 contributors

This article discusses a 2016281112 (Remediation Failed) error message in Intune.

After you create and assign a device configuration profile that defines a custom VPN connection by using OMA-URI settings, Windows 10 clients receive the profile and can connect to the VPN endpoint successfully. However, the profile reports a 2016281112 (Remediation Failed) error message in the Microsoft Intune admin center.

This issue occurs because, in certain scenarios, the response that is sent by the Windows 10 client includes XML that is formatted differently than the XML that is sent through the Intune policy.

If the policy is applied successfully, the XML in the response should exactly match the XML in the policy. This is how Intune verifies that the policy has been applied correctly. If the XML differs between the policy and the client response, Intune interprets the mismatch as a remediation failure.

You can safely ignore this error because the connection works as expected.

Alternatively, you can create a standard VPN device configuration profile instead of using a custom profile that uses OMA-URI settings. If you create a standard profile , Intune does not generate the error message that is described in the Symptoms section.

This is a known issue in all versions of Windows 10 up to and including Windows 10, version 1809. This issue is scheduled to be addressed in a future Windows 10 release.

Was this page helpful?

Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback .

Submit and view feedback for

Additional resources

• SI SWIMSUIT
• SI SPORTSBOOK

Angels' Ron Washington Excoriates Veteran for Missed Play: 'It Wasn't Anything I Did Wrong'

J.p. hoornstra | may 15, 2024.

• Los Angeles Angels

The Los Angeles Angels didn't do themselves any favors in the bottom of the eighth inning Tuesday. With the bases loaded, Luis Guillorme squared up to bunt against St. Louis Cardinals pitcher JoJo Romero. Zach Neto broke from third base — a rare, exciting suicide squeeze, setting up a do-or-die moment for Guillorme.

Guillorme did not get down the bunt. He missed the pitch entirely, Neto was tagged out, and the Angels did not get a run in the inning. That made the difference in a 7-6 loss.

The Angels haven't been doing themselves favors all season long. They're 15-28, eight games out of first place and fifth in the five-team American League West. Until Tuesday, however, they had not resorted to playing the blame game. Then, in a candid postgame press conference, "we" became "he" for manager Ron Washington.

"He didn't do the job," Washington told reporters in reference to a question about Guillorme. "It wasn't anything I did wrong. He didn't do the job."

to say Ron Washington threw Luis Guillorme under the bus is an understatement… pic.twitter.com/7Hgi8ZCWlb — BTH (@BeyondTheHalo) May 15, 2024

Kudos to Washington for being transparent about his feelings. In an age when managers routinely tone down their raw thoughts and feelings, Washington kept the varnish in his garage. However, it's fair to question whether bunting against Romero — who had gone to a full count to each of the first four batters in the inning, walking two and allowing a double to load the bases — was the correct call.

Guillorme, 29, was no stranger to bunting during his six seasons with the New York Mets (2018-23). Even though the pitch was literally in the opposite batter's box, making contact with the ball and bunting or tipping it foul would have been better than missing it altogether. It's also true that Romero's wildness could have predicted Guillorme might not have gotten a good pitch to bunt in that situation.

This seems like a both-and situation rather than an either-or. It's possible (if not likely) that both Guillorme and Washington shoulder some percentage of the blame for not getting at least one run in the eighth inning of a game the Angels trailed 7-6 with one out and the bases loaded. It was a good time for the Angels to identify "we" as the at-fault party, rather than "he."

For his part, Guillorme accepted the blame.

Luis Guillorme did what Ron Washington did not: Take responsibility. And to be clear, he did not have to. “I haven’t seen (what Washington said). He made a good a pitch. I didn’t get it down. I’ve got to try to put a bat on it. That’s it.” — Sam Blum (@SamBlum3) May 15, 2024

Romero eventually struck out Guillorme for the third out of the inning. Ryan Helsley pitched a scoreless ninth to close out the win. The Cardinals (18-24), who have struggled out of the gate this season themselves, have to feel fortunate to have escaped with a win.

All the Angels can do is reflect on another costly mistake — hopefully, with an open mind to whose mistake it might have been.

J.P. HOORNSTRA

J.P. Hoornstra writes and edits Major League Baseball content for Halos Today, and is the author of 'The 50 Greatest Dodger Games Of All Time.' He once recorded a keyboard solo on the same album as two of the original Doors.

Follow jphoornstra