Blog Post

Intune Customer Success
6 MIN READ

Intune grouping, targeting, and filtering: recommendations for best performance

Intune_Support_Team's avatar
Intune_Support_Team
Silver Contributor
Nov 22, 2021

By: Scott Duffey - Senior Program Manager | Microsoft Intune

 

Editor's Note: We have incorporated this guidance into our documentation. As the information in this blog is no longer current, we invite you to visit our updated resource at: Performance recommendations for Grouping, Targeting and Filtering in large Microsoft Intune environments.

 

This post provides concise recommendations and considerations for Intune grouping, targeting, and filtering. My goal is to help you make key architecture and design decisions in your own Intune deployments and inform you about the limitations and trade-offs of different grouping and targeting approaches. Consider these performance recommendations as just one factor along with others that are specific to your own environment (for example, manageability and simplicity).

 

Here’s what I’ll cover:

  1. A brief overview of Intune grouping and targeting concepts.
  2. Key recommendations for best performance.

Overview of Intune grouping and targeting concepts

Before getting into the recommendations, it’s worthwhile to briefly review the grouping, targeting, and filtering units available in Intune today.

 

Azure Active Directory groups

Intune almost exclusively uses Azure Active Directory (Azure AD) groups for grouping and targeting. When you select Groups in the Microsoft Intune admin center, you are looking at the Azure AD groups page. Azure AD groups are important to Intune administrators because they are the object used for assigning apps, policies, and other workloads to users and devices. They are used for other purposes, for example as Scope groups in role-based administration (RBAC), where you can define which devices certain admins are allowed to view in the admin center.

 

Screenshot of the Microsoft Endpoint Manager admin center with the Groups blade highlighted.

 

Virtual groups

The All users and All devices assignments are known as Intune “virtual” groups. These virtual groups are convenient because they exist by default in all Intune tenants and don’t come with any management overhead (you don’t need to create or adjust any Azure AD rules to keep them populated with members). They are also highly scalable and optimized, mainly because they do not need to be synced from Azure AD in the same way that groups do.

 

Filters

You can use filters to narrow the assignment scope of apps and policies (and other workloads) to specific devices, after the app or policy is assigned to one of the other mentioned group types. With filters, you can target user or device groups and then filter devices in or out of that assignment based on device properties. Filtering is high performance, low latency applicability evaluation at device check-in without any need to pre-compute.

 

Screenshot of an Intune - Windows 10 and later Device restrictions policy with Azure AD, Virtual, and Filters highlighted.

 

Recommendations for best performance

Below are some general recommendations to improve performance when working with assignments in Microsoft Intune.

 

Note: These recommendations are general and focus on improving performance and reducing latency in workload assignment. They have the most impact when working in large Endpoint Manager environments (10k devices+). Recommendations should be considered alongside other design aspects such as manageability, ease of use, role-based administration, and simplicity.

 

Use virtual groups

DON’T

DO


X
Don’t create your own “All users” or “All devices” groups for use in Intune targeting or RBAC.

 

 


    ✔ Use virtual groups All users and All devices        where possible.

 

    ✔ Use filters to achieve granular device                  applicability.

 

 

 

If you assign Intune workloads to large Azure AD groups containing many users or devices, it may cause large synchronization backlogs in your account. This impacts policy and app deployments, which will take longer to reach managed devices.

 

All users and All devices are an Intune-only grouping construct. This means there is no ongoing sync between Azure AD and Intune. Similarly, filters are an Intune construct that allows devices to be evaluated for applicability dynamically during check-in. Using several large groups (e.g., “All windows devices” and “all iOS devices” rather than the virtual groups with filters can create sync bottlenecks, blocking the sync of smaller groups until the large groups are fully synced.

 

Every time you use a new group (one that has never been used before in an Intune assignment) there is a first-time setup process that happens in addition to the membership sync. The first (full) sync always takes longer than subsequent (incremental) syncs.

 

Re-use groups

 

DON’T

DO


 X
Don’t create duplicate copies of the same group to target different policies.

 X Don’t create dedicated “App groups” or “Policy groups”.

 

 

 ✔ Re-use the same group objects for assigning   multiple policies.

 


Behind the scenes, Intune converts Azure AD group members to assignment targeting messages for each user and device. This process is highly optimized when the group objects are the same. Said another way, Intune grouping and targeting works best when the “Engineering” user group is targeted with 10 policies, rather than the Engineering users being used as members of 10 different groups, each assigned to a different policy.

 

We’ve seen a few designs countering this guidance–for example where IT admins create a group called “Install_Edge” and then another group called “Deploy_Edge_Config_Policy” and put the same devices in each group.

 

A similar (and not recommended) pattern is creating “App groups” where each app has several Azure AD groups created for it and then adding members directly to those groups. For example, to manage the Edge application, the administrator creates three groups:

 

Edge_Required

 

Edge_Available

 

Edge_Uninstall

 

The administrator then adds individual user or device objects into those groups (typically via custom tooling or the Graph API).

 

We don’t recommend this approach because it dramatically increases the number of Azure AD groups that Intune must subscribe to and monitor for membership updates, which is less efficient. Inefficient group sync design can impact the speed at which new assignments can be created and delivered to devices.

 

Make incremental group changes

DON’T

DO

X Don’t make big group nesting changes all at once.

✔ Make incremental changes to build out nested groups.

 

A large group membership change in Azure AD can generate bursts of targeting changes in Intune and slow down targeting of other assignments in your environment.

 

In the following example, consider you have a group structure as follows:

 

Parent group (0 devices) – Not assigned


Child group 1 (30k devices) – Not assigned

 

Child group 2 (60k devices) – Not assigned


Child group 3 (90k devices) – Not assigned

 

Rather than targeting the parent group (and its child groups) in a policy deployment (impacting 180k devices all at once), we recommend instead that you start with an empty parent group that has no nested children and then gradually, over the course of days, add child groups 1-3. At a rate of 30k devices a day, this targeting will be applied to all devices over 6 days. This recommendation doesn’t mean you need to further break-up child groups 2 and 3 to enforce a 30k maximum per day, the example is just to highlight a conservative rate of processing new groups through the grouping and targeting system.

 

Note: This recommendation also applies when groups are “un-nested”

 

Use filters to include and exclude

 

DON’T

DO

X Don’t mix user groups and device groups when using Include and Exclude groups.

✔ Use filters to achieve the right user+device combination for targeting.

 

 

This recommendation is also a support statement. We do not recommend or support creating assignments to user groups and excluding a device group from that assignment (or vice-versa). This recommendation exists due to the timing/latency characteristic of dynamic groups and the fact that Excluded groups membership is not instant, which can result in cases where devices incorrectly receive app or policy assignments. To understand more, see this support matrix.

 

Instead of mixed exclusions, we recommend assigning to a user group and then using filters to dynamically include or exclude the appropriate devices.

 

Summary

Hopefully, you will be able to incorporate some of these recommendations when creating and managing assignments in Intune. Take advantage of virtual groups and filters to help refine the scope of your Azure AD groups, and keep these best practices in mind:

  • Use Intune virtual groups that don’t require Azure AD syncing.
  • Re-use groups to optimize your targeting.
  • Make incremental group changes for more efficient processing.
  • Use filters, instead of groups, to dynamically include and exclude.

 

Additional content

Microsoft Endpoint Manager: A deep dive on grouping, targeting and filtering​.

 

If you have questions or comments for the Intune team, reply to this post or reach out to @IntuneSuppTeam on Twitter.

 

Post updates

12/17/21: Updated post with a new section for additional content.

07/14/22: Updates to the virtual groups section.

04/07/23: We have incorporated this guidance into our documentation. As the information in this blog is no longer current, we invite you to visit our updated resource at: Performance recommendations for Grouping, Targeting and Filtering in large Microsoft Intune environments.

Updated Nov 09, 2023
Version 11.0

28 Comments

  • Hi Scott Duffey 

     

    Thanks for the post!

     

    How does synchronization of  collection memberships from Config Manager to an Azure Active Directory (Azure AD) group play into these recommendations. Any do's and don'ts for them?

     

    https://docs.microsoft.com/en-us/mem/configmgr/core/clients/manage/collections/create-collections#bkmk_aadcollsync

     

    Thank you,

    Alex

  • caipininja's avatar
    caipininja
    Copper Contributor

    Hi Scott Duffey,

    while I understand your points, I consider this the "Intune technical perspective".

     

    I confess:

    I create a group for every configuration, compliance policy, and three for applications.

    Just to keep the configurations and assignments easy to follow and easily customizable.

     

    I have tried your way in the past and found it too difficult to identify all configurations, policies and applications that are assigned to the "engineering" group. I am not aware of an easy way to identify all configuration items one group has been assigned to. Is there a way (apart from PowerShell and the Graph API)?

     

    Additionally, if I want to change assignments for the "engineering" group, I cannot do this from the group. I must visit all configs, policies and apps. Very time consuming and error prone.

     

    There are policy sets and they sound really good.

    But they don't support iOS VPP apps, no Win32 apps, and whatever else.

    So at the end of the day, I can't use them.

     

    If you want us to change our behavior, simply improve the manageability of Intune.

     

    :smile:

     

    Best

     

    Martin

  • Ben-Wildman's avatar
    Ben-Wildman
    Copper Contributor

    Hi,

    Firstly, great article.

    What would be great is if we could use filters against compliance policies. As compliance are user based, users often have corporate and personal devices enrolled. In some scenarios the compliance requirements will differ between device types so it would be great if we could use these.

     

     

     

  • Choopsbanter's avatar
    Choopsbanter
    Copper Contributor

    Enabling support for Filters when assigning App protection and App configuration policies would be amazing.

  • Hi nhtkid , Thanks so much for taking the time to read the post and ask questions! Its ok to create a new group to use to target a specific app, or exclude a specific set of users for an app. The point here is really about re-using groups when you can, rather than architecting a solution where every App in the environment has 1-3 groups created for it.

  • trevorjones's avatar
    trevorjones
    Brass Contributor

    Are there any plans to expand the available property options in Filters? I love the concept of Filters but I find its real-world usefulness limited with the current options.

    For more granular targeting of Windows devices, for example, I still find the best approach for us is using ConfigMgr collections with its much more powerful rule membership options, and syncing those to AAD groups. Even if this is not the most optimized approach from an infrastructure viewpoint, its the best way to attain the targeting granularity we need. I would really like to see similar capability in Intune / AAD, especially for devices.

  • nhtkid's avatar
    nhtkid
    Iron Contributor

    Thanks Scott for the high level breakdown.

    It really clarified many use case in the real world.

     

    For example, when you mentioned the Edge app group, it resonates with me instantly. I am sure many of us have done the app group in the past, and still doing it.

     

    So, for this certain scenario, if we are publishing a new app and will only be available to certain people, what's the best practice?

     

    Currently, we will create a new AAD group that has the app assignment, and start adding users or groups to it. We won't create additional groups for the same app usually.

     

    But if different users need to uninstall the app, then we have to create another AAD group to include them and add it under the Uninstall assignment. Simply move them out of the first AAD group won't uninstall the app for them, isn't it?

     

    I can't think of any other ways of archiving this.

    Please advise.

     

    Thanks.