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

This post has been republished via RSS; it originally appeared at: Microsoft Tech Community - Latest Blogs - .

By: Scott Duffey -- Senior Program Manager | Microsoft Endpoint Manager – Microsoft Intune

 

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 Endpoint Manager 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.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.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.

 

✔ large groups for faster deployment when you need them.

 

 

 

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.

 

For groups that are larger than 30k members or expected to grow beyond 30k members (including transitive members due to nesting), consider “pre-staging” the groups. To “pre-stage” a group you just need to use it somewhere in the console; for example, you could include it in an RBAC scope assignment or a benign policy or app assignment.

 

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.

 

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

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.