Grouping, targeting and filtering in MEM
In cases where new smartphones and tablets need to be onboarded into the Microsoft Endpoint Manager and deployed automatically, time is a critical factor. Policies and applications must be known to the device the moment it boots up and is deployed for the first time. This is where dynamic device groups are often relied upon to assign policies. As is well known, these can be created in Azure AD and provided with a dynamic membership rule. Various properties can be selected as rules, each of which makes sense for the corresponding use case. There is no general recommendation here. The problem: The synchronization of group memberships between Microsoft Endpoint Manager and Azure AD is too slow. Result: The android device, iPhone or iPad does not receive the policies, configurations and applications in time which were previously assigned during initial setup. The assignment does not take effect in time, because the device ends up in the Dynamic Group only after an almost complete enrollment and from there the policies are synchronized towards the endpoint via the assignment. After many difficulties and troubleshooting, a new solution was needed.
After much research and testing, the following solution looks very promising: Device targeting with the help of filters.
This feature is currently in preview and you can find further information in this blog post from Microsoft: https://techcommunity.microsoft.com/t5/intune-customer-success/filters-public-preview-overview-and-known-issues/ba-p/2346835
What is the problem?
Essentially, the problem is with the synchronization of Group Data from Endpoint Manager to Azure Active Directory and back again, which is basically an extra step in the enrollment of devices. This extra step causes a delay in assigning configuration profiles that are necessary for initial setup. This issue is especially prevalent on non-Windows devices, as there is no autopilot for other platforms where policy and group assignments can be accelerated using group tags. If you want to manage the Android devices with the Managed Home Screen, it would have to be installed in the enrollment process. Assigning this app is essential for a Zero Touch deployment and must absolutely be installed during the initial device setup. This is where the problem with dynamic device groups comes from.
Schematic representation of the synchronization and the intermediate steps:
What ist the solution?
To avoid this additional step, since May 2021 it has been possible to assign profiles not only to dynamic groups, but also directly to all devices, including filter rules. For this purpose, filters must be defined in advance. Devices can be filtered by different properties. Additionally there is a possibility to include or exclude these devices from All Devices. Special care must be taken here. When assigning to All Devices, it is essential to add the filter rule.
This way, the smartphone gets the needed informations regarding which apps should be installed, in time. This means that Microsoft’s Managed Home Screen is also installed during the initial setup.
Schematic representation of this process:
Known issues of device filtering
- Delay in filter evaluation report data
- No way to see which policies and apps are using a filter
- “Pending” deployment status result and “Not evaluated” compliance status result in Android Enterprise policy reports
More informations: https://techcommunity.microsoft.com/t5/intune-customer-success/filters-public-preview-overview-and-known-issues/ba-p/2346835
Configure device filters
The setting can be found here: Devices -> Other -> Filters (preview) -> + Create
The first time this function has to be activated below Create.
Warning: This is currently a preview.
For example, to capture all devices that are categorized as personal, one could define the following:
Check the status
You can check the status of the profiles in the profile itself under Device status. All devices that correspond to the same platform are currently listed here. The Deployment Status column then shows whether the assignment was a Success, Pending or Not applicable. Not applicable simply means that the policy was not assigned to the device based on the filter rule. In the future, it would be desirable to be able to hide these devices from the overview and have a clean reporting.
You can currently find much more details when you go to the respective device and look at the “filter evaluation”.
