This post has been republished via RSS; it originally appeared at: Intune Customer Success articles.
Today we released an exciting new feature in Microsoft Endpoint Manager that we call “Filters”. The feature adds greater flexibility for assigning apps and policies to groups of users or devices. Using filters, you can now combine a group assignment with characteristics of a device to achieve the right targeting outcome. For example, you can use filters to ensure that an assignment to a user group only targets corporate devices and doesn’t touch the personal ones. Read more about the announcement here and review the feature documentation here.
The feature is enabled with the service-side update of the 2105 service release, so you can expect to see it in the Microsoft Endpoint Manager admin center starting May 7 and continuing as the service-side updates.
Here is an overview of the feature: Use Microsoft Endpoint Manager filters to target apps and policies to specific users | YouTube.
The feature is released for Public preview and is supported by Microsoft to use in production environments. The following known issues apply. We will remove items off this list as issues are resolved.
- Compliance policy for “Risk score” and “Threat Level”: If your tenant is connected to a partner Mobile Threat Detection (MTD) partner service or Microsoft Defender for Endpoint (MDE), Compliance policies for Windows 10, iOS or Android can include the optional setting “Require the device to be at or under the machine risk score” or “Require the device to be at or under the Device Threat Level”. Using this setting configures the Microsoft Endpoint Manager compliance calculation engine to include signals from external services in the overall compliance state for the device. Using Filters on assignments for compliance policies with these settings is not currently supported.
- Available Apps on Android DA enrolled devices: Filter evaluation for available apps requires Company Portal app version 5.0.4868.0 (released to Android Play store August 2020) or higher for filter evaluation. If a device does not have this version (or higher) installed, apps will incorrectly show as available in the Company portal but be blocked from installing on the device.
- OSversion property for macOS devices: MacOS version numbers are reflected in Intune as a string that combines version number and build version in Intune, for example: “11.2.3 (20D91)” includes version number 11.2.3 along with build version 20D91. When creating a filter based on OS version for macOS device you can specify the full string including both components. There is a known issue where the device check-in gateway does not gather the full build version for evaluation, resulting in an incorrect evaluation result. For example, if you specified a filter (Device.OSversion -eq “11.2.3 (20D91)”) and a device of this version was evaluated, the result would be “Not match” because only the first half of the version number is evaluated.
Known issues for reporting:
- Filter evaluation reports for Available Apps: Evaluation results are currently not collected for apps assigned to groups with the “Available” intent. The “Managed Apps” (Device > [Devicename] > Managed Apps) “Resolved intent” column incorrectly shows a status of “Available for install” even if the device should be excluded by a Filter.
- Delay in filter evaluation report data: There is a case where filter evaluation reports (Devices > All Devices > [Devicename]> Filter evaluation) are not updated with the most recent evaluation results. This case only occurs in a special case where a filter is used in an assignment, some evaluation results are produced and then the filter is later removed from that assignment. In this scenario the report may take up to 48 hours to reflect. Note, this occurs only if the filter is removed from the assignment and not if the assignment is recreated by removing the group and then re-adding it without a filter.
- Win32 apps reporting: There is a known issue where Win32 apps reports (Apps > All apps > [App Name] > Device install status] for a device may be incomplete when a filter was used for any of the targeted apps for a device. Apps that were filtered out during a check-in may fail to report evaluation status events back to the MEM admin center. This impacts the app that used the filter, along with other Win32 apps in the same check-in session.
- Unexpected policies for other platform types show up in filter evaluation report: The Filter evaluation report for a single device (Devices > All Devices > [DeviceName]> Filter evaluation (preview)) shows all policies and apps that were targeted at the device or primary user of the device for which there was a filter evaluation performed, even if the policy type is not applicable for the platform of the device you are interested in. For example, if you assign a Windows 10 configuration policy to a user (a group that contains the user) along with a filter, you will notice that the filter evaluation report lists of policies for that user’s iOS, Android and macOS devices will also show Windows 10 policies and evaluation results. Note: The evaluation results will always be “Not Match” due to platform.
- No way to see which policies and apps are using a filter: When editing or deleting an existing filter, there is no way in the UX to see where that filter is currently being used. We’re working on adding this (see “Features in development” below). As a workaround, you can use this PowerShell script that will walk through all assignments in your tenant and return the policies and apps where the filter has been used. See Get-AssociatedFilter.ps1 script here.
- “Pending” deployment status result and “Not evaluated” compliance status result in Android Enterprise policy reports: Configuration policy reports show a result of “Pending” for each targeted device soon after an assignment is created, Compliance Policies show “Not evaluated” – this means that the device has not attempted to apply the policy or compute compliance for the device yet. The status gets updated to “Succeeded”, “Failed” or “Not applicable” after the device attempts to apply the policy and a result is logged. There is a known issue where the status stay’s as “Pending” (for Configuration policies) or “Not evaluated” (for Compliance policies) and does not get updated to “Not applicable” in the case where the policy was filtered out by an assignment filter. This issue only impacts Android Enterprise policies and you can see the filter evaluation results on the device object: Devices > All Devices > [DeviceName]> Filter evaluation (preview).
Features in development:
- Pre-deployment reporting – We’re working on adding reporting experiences that make it possible to know the impact of a Filter before using it in a workload assignment.
- Associated assignments – We’re working on an improvement to select a filter and be able to identify all the associated policies and apps where that filter is being used.
- More workloads – We’re adding filters to the assignment pages of more MEM workloads including Endpoint Security, Proactive remediation scripts, Windows update policies and more.
Frequently Asked Questions
Do filters replace group assignments?
No. Filters are used on top of groups when you assign apps and policies and give you more granular targeting options. Assignments still require you to target a group and then refine that scope using a filter. In some scenarios, you may wish to target “All users” or “All devices” virtual groups and further refine using filters in include or exclude mode.
What about “Excluded groups”? Can I use a filter on these assignments?
While filters cannot be added on top of an “Excluded group” assignment the desired outcome can be achieved by combining Included groups with filters. Filters provide greater flexibility than Excluded groups because the “excluded groups” feature does not support mixing group types. See: supportability matrix to learn more.
Excluded groups are still a great option for user exception management – For example, you deploy to “All Users” and exclude “VIP Users”.
Now with filters you can build on top of existing capability by mixing user and device targeting. You can, for example define a filter to – Deploy to “All Users”, exclude “VIP Users” and only install on the “Corporate-owned” devices.
Here is summary guidance on how to use Groups, Exclude groups and Filters:
- Filters complement Azure AD groups for scenarios where you want to target a user group but filter ‘in’/’out’ devices from that group. For example: assign a policy to “All Finance Users” but then only apply it on corporate devices.
- Filters provide the ability to target assignments to ‘All Users’ and ‘All Devices’ virtual groups while filtering in/out specific devices. The “All users” groups are not Azure AD groups, but rather Intune “virtual” groups that have improved performance and latency characteristics. For latency-sensitive scenarios admins can use these groups and then further refine targeted devices using filters.
- "Excluded groups" option for Azure AD groups is supported, but you should use it mainly for excluding user groups. When it comes to excluding devices, we recommend using filters because they offer faster evaluation over dynamic device groups.
General recommendations on groups and assignment:
- Think of Include/Exclude groups as an initial starting point for deploying. The AAD group is the limiting group so use the smallest group scope possible.
- Assigned (also known as static) Azure AD groups can be used for Included or Excluded groups, however it usually is not practical to statically assign devices into an AAD group unless they are pre-registered in AAD (eg: via autopilot) or if you want to collect them for a one-off, ad-hoc deployment.
- Dynamic Azure AD user groups can be used for Include/Exclude groups.
- Dynamic AAD device groups can be used for Include groups but there may be latency in populating group membership. In latency-sensitive scenarios where it is critical for targeting to occur instantly upon enrollment, consider using an assignment to User groups and then combine with filters to target the intended set of devices. If the scenario is userless, consider using the “All devices” group assignment in combination with filters.
- Avoid using Dynamic Azure AD device groups for Excluded groups. Latency in dynamic device group calculation at enrollment time can cause undesirable results such as unwanted apps and policy being delivered before the excluded group membership can be populated.
Are Intune Roles (RBAC) and scope tags supported?
Yes. During the filter creation wizard, you can add scope tags to the filter. (Note: The “Scope Tags” wizard screen only shows if your tenant has configured scope tags). There are four new privileges available for filters (Read, Create, Update, Delete). These permissions exist for built-in roles (Policy admin, Intune admin, School admin, App admin). To use a filter when assigning a workload, you must have the right permissions: You must have permission to the filter, permission to the workload and permission to assign to the group you chose.
Is the Audit Logs feature supported?
Yes. Any action performed by an admin on assignment filter objects is recorded in audit logs (Tenant administration -> Audit logs). This also includes the action of enabling the Filters feature in your account.
Can I use filters with user group assignments?
Yes. This is a good scenario for using filters. For example, you can assign a policy to “All finance users” and then apply an assignment filter to only include “Surface Laptop” devices.
Can I create a filter based on any device property I can see in MEM?
No, not yet but we plan to add more filter properties over time. The list of supported properties is here. Please let us know about the properties that would help in your scenarios to: aka.ms/MEMfiltersfeedback.
Can I use filters in any assignment in MEM?
While in preview, filters are available to use in a core set of workload types (Apps, Compliance and Configuration profiles). The list of supported properties is here. Please let us know about the properties that would help in your scenarios at aka.ms/MEMFiltersfeedback.
How does assignment filtering get reflected in device status and device install status reports in the MEM admin center?
Filter reporting information exists for each device under a new stand-alone report area called “Filter evaluation” and we’re working to further integrate reporting information into existing reports such as the “Device status” and “Device install” reports. As an example of where this is going, the apps report has a new column called “Filter (preview)” under Device install status. Over time you will see further integration of the filter information into other workload type reports.
If you deploy a policy (Compliance or Configuration) to a group and navigate to the “Device status” report, there is a row in the report for each targeted device. When each targeted device checks-in the device will be evaluated against the associated filter and this status will be updated (For example, the status will show “Not Applicable” if the assignment filter filtered the policy out). For apps, the experience (in the Device install status report) is similar, except that you can view details on the filter evaluation by clicking on the “Filters evaluated” link.
How many filters can I create?
There is a limit of 50 filters per customer tenant.
How many expressions can I have in a filter?
There is a limit of 3072 characters per filter.
Can I use more than one filter in an assignment?
No. An assignment includes the combination of Group + Filter + Other deployment settings. While you can’t use more that one filter per assignment you can certainly use more than one assignment per policy or app. For example, you can deploy an iOS device restriction policy to “Finance users” and “HR users” groups and have a different assignment filter linked to each of those assignments. However, be careful not to create overlaps or conflicts. We don’t recommend it but have documented the behavior here.
How do Filters work with the Windows 10 “Applicability Rules” feature?
Filters are a super-set of functionality from “Applicability rules” and as such we recommend that you use filters instead. We do not recommend combining the two together or know of a reason to, but if you do have a policy assigned with both, the expected result is that both will apply. The filter will be processed first, then a second iteration of applicability will be undertaken by the applicability rules feature.
- Use Microsoft Endpoint Manager filters to target apps and policies to specific devices
- Use Microsoft Endpoint Manager filters to target apps and policies to specific users | YouTube
- Create filters in Microsoft Intune
- Supported filter device properties and operators in Microsoft Intune
- Platforms and policy types supported by filters in Microsoft Intune
- Filter reports and troubleshooting in Microsoft Endpoint Manager
- Public preview overview in Microsoft Intune
Let us know if you have any questions by replying to this post or reaching out to @IntuneSuppTeam on Twitter.
6/14/21: Updated with a known issue for reporting. “Pending” deployment status result and “Not evaluated” compliance status result in Android Enterprise policy reports.