Hi, when deploying an Intune config for a customer, whether it is a greenfield setup or revamping an existing environment I often get the question on how to do Intune Assignments User Groups vs Device Groups.

In short, this is not carved in stone, the answer depends on your goal. I decided to write a short blog regarding this.

Device Groups

If you aim to implement settings on a device, no matter who logs in, assign your policies to a group of devices. Settings designated for device groups consistently stick with the device and aren’t tied to specific users.

For instance:

Device groups serve as a valuable tool for managing devices without dedicated users. Consider devices used for tasks like printing tickets, inventory scanning, shared among shift workers, assigned to specific locations like warehouses, and more. These devices can be organized into a dedicated group, allowing you to assign policies tailored to them.

Let’s say you’ve created a Device Firmware Configuration Interface (DFCI) Intune profile aimed at adjusting settings within the BIOS. For instance, you might configure this policy to deactivate the device camera or secure boot options to prevent alternative OS booting. Such a policy is well-suited for assignment to a devices group.

Moreover, for particular Windows devices where you consistently need control over specific Microsoft Edge settings, irrespective of the user accessing the device, a devices group can be useful. Imagine needing to block downloads, restrict cookies to the current browsing session, or erase browsing history. In this case, assemble these specific Windows devices into a devices group. Then, within Intune, create an Administrative Template outlining these device settings and assign this policy specifically to the devices group.

In summary, employ device groups when user sign-ins are irrelevant or when it doesn’t matter if anyone signs in at all. The goal is to ensure that your settings persist consistently on the device regardless of user activity.

User Groups

In essence:

Policy settings designated for user groups remain tied to the user, following them across their various signed-in devices. It’s common for users to have multiple devices, such as a work Surface Pro and a personal iOS/iPadOS device, and to access organizational resources like email across these devices.

When a user possesses multiple devices within the same platform, filters on group assignments become valuable. For instance, if a user has both a personal and organization-owned iOS/iPadOS device, policy assignment can be filtered to target solely the organization-owned device when applying policies for that user.

As a general guideline: if a feature pertains to the user, like email or user certificates, it’s best assigned to user groups.

Consider these examples:

• Implementing a Help Desk icon universally across all devices for all users: Create a users group and assign the Help Desk icon policy to this group.
• Onboarding a user onto a newly acquired organization-owned device managed by Intune: Assign policies specific to this scenario to a users group.
• Managing features within apps like OneDrive or Office whenever a user signs into a device: Assign OneDrive or Office policy settings to user groups.

For instance, if the aim is to block untrusted ActiveX controls in Office apps, configure this setting via an Administrative Template in Intune and assign it to a users group.

In summary, opt for user groups when you need settings and regulations to consistently accompany the user, regardless of the device they’re using.

CSP Policy – OMA-URI

Windows device policies rely on configuration service providers (CSPs), which correspond to registry keys or files within the devices.

Key points about Windows CSPs:

• Intune provides access to these CSPs, enabling configuration of settings that can be assigned to Windows devices. These settings are adjustable using built-in templates and the settings catalog, where some apply at the user level and others at the device level. Understanding how user-scoped and device-scoped settings function on Windows devices? Visit the Settings catalog: Device scope vs. user scope settings for insights.
• When a policy is withdrawn or no longer assigned to a device, outcomes vary based on the settings within the policy. Each CSP handles policy removal uniquely. For instance, a setting might retain its current value and not revert to a default state. This behavior is governed by individual CSPs within the operating system. Explore the configuration service provider (CSP) reference for a list of Windows CSPs. To modify a setting to a different value, generate a new policy, configure the setting as “Not configured,” and assign it. Upon policy application, users should be able to adjust the setting to their preferred value.

• When setting up these configurations, it’s advisable to pilot deployment within a test group. For additional guidance on Intune rollout strategies, refer to creating a rollout plan.

Exclusions

In Intune, device configuration policies offer the option to select groups for policy assignment, allowing inclusion and exclusion.

Here’s a recommended approach:

• Craft and assign policies tailored to your user groups. Utilize filters to encompass or exclude devices belonging to these users.
• Develop distinct policies intended specifically for your device groups.

For further insights on managing groups, refer to the guidance provided in “Add groups to organize users and devices.”

When deploying your policies, consider these key guidelines:

• Group Selection: Use Included or Excluded groups as the initial criteria for determining which users and devices will receive your policies. The Microsoft Entra group acts as the limiting factor, so aim for the smallest group scope possible. Employ filters to narrow down or refine your policy assignment.
• Assigned Microsoft Entra Groups: These static groups can be included in Included or Excluded groups. Typically, devices are statically assigned to a Microsoft Entra group if they’re pre-registered in Microsoft Entra ID, like with Windows Autopilot, or for one-time, ad-hoc deployments. Static assignment might not be practical otherwise.
• Dynamic Microsoft Entra User Groups: These can be included in Included or Excluded groups. Excluded groups can consist of either user or device groups.
• Dynamic Microsoft Entra Device Groups: They can be included in Included groups, but there might be latency in populating the group membership dynamically. For scenarios sensitive to latency, use filters to target specific devices and assign policies to user groups.

For instance:

• Latency-Sensitive Assignments: If immediate device policy assignment upon enrollment is crucial, create a filter targeting specific devices and assign the policy via user groups instead of device groups.
• Userless Scenarios: When dealing with userless scenarios, create a filter to target desired devices and assign the policy to the “All devices” group.
• Avoid Excluding Dynamic Device Groups: Adding dynamic Microsoft Entra device groups to Excluded groups might result in undesirable outcomes due to latency in calculating dynamic group membership at enrollment. This could lead to unwanted app and policy deployments before the excluded group membership is finalized.

I’ve made a small matrix that you can use that gives a good overview on the assignments:

I hope this blog post will clarify things regarding assignments for you.