Skip to main content

Assign Microsoft Intune Settings to Devices or Users. Welcome to the blog post about the question on when to Assign Microsoft Intune Settings to Devices or Users. I often heard from users that they are unsure on when to Assign Settings to Users or Devices. Let’s get started.

Assign Microsoft Intune Settings to Devices or Users

We first will have a look at a quick summary on should we Assign Microsoft Intune Settings to Devices or User. In the second step we will have a look in detail on why we should assign Settings to Devices or Users. But keep in mind, For all Settings you can ask the following questions:

  1. Are you trying to control an experience based on who the user is, or what device they are using?
  2. What type of policy or profile are we working with?
ConfigurationAssign to Users whenAssign to Devices when
Compliance & Conditional AccessAlways target User GroupsNever target Device Group
Configuration & Endpoint SecurityControl based on who the user isControl based on the device or ownership (e.g. Kiosk, Corp, BYOD)
ApplicationsRequired or AvailableRequire only (e.g. Kiosk devices)
App Protection (MAM)Always target User groupsNever target Device Groups
AutopilotNever target User GroupsAlways target Device Groups

Compliance & Conditional Access

When dealing with compliance policies, my focus has always been on users. However, there is a possibility to assign a compliance policy to a security group composed of devices. Let’s explore this further.

Assigning to Devices: Yes, but with Caution If you choose to assign compliance policies directly to devices, you’ll encounter dual compliance results for each device. In fact, there might even be three results if you consider the built-in policy. Specifically:

  • The system account will receive a compliance status.
  • The user who signs into the device will also have a compliance status. Unfortunately, this approach can lead to discrepancies when assessing overall device compliance. I’ve witnessed cases where both the user and the system account were marked as ‘Compliant,’ yet the built-in compliance policy was labeled ‘Not Compliant.’ Odd, right? Especially since the built-in policy merely checks whether any compliance policy is applied (which it obviously is). Due to these inconsistencies and potential issues, I advise against assigning compliance policies directly to devices. Additionally, note that we lack the option to assign to “All devices”; it’s limited to “All users” (unlike configuration profiles).

My Approach to Compliance Policies I view compliance policies as the bare minimum necessary for any endpoint to connect and function within our systems. Whether the devices are corporate or personal, the same standards apply. Therefore, I typically create a single compliance policy for each supported device platform. These policies are then assigned to All users or, at the very least, a security group representing all licensed users (those authorized to use Intune).

Configuration & Endpoint Security

Returning to our initial question: Are you aiming to control the user experience based on individual identity or the specific device they’re using?

  1. Consistent Device Targeting: Consider scenarios like kiosk devices or lab computers. Regardless of who logs in, you desire a uniform experience. Even if different users interact with the same applications, the device behavior should remain consistent. To achieve this, create a device-based security group and apply relevant profiles. This ensures a predictable experience regardless of the user.
  2. Managing Corporate and Personal Devices: Organizations often handle a mix of corporate-owned and personal devices within the same platform. For instance, you might have both corporate iPhones and personal iPhones. Here, distinct requirements emerge for each group. Your corporate profile might restrict manual unenrollment, while the personal profile remains more flexible. To address this, establish two dynamic security groups:
    • One for deviceOwnership = Personal
    • Another for deviceOwnership = Company When assigning profiles, target the appropriate group based on the device context.
  3. Dynamic Security Groups: A Trade-Off: Dynamic security groups offer flexibility but come with a caveat. Membership updates can take extra time—ranging from minutes to hours. While this delay is usually inconspicuous, anticipate occasional helpdesk calls resolved by the simple remedy of “waiting it out.”

Applications

When assigning applications to devices, similar logic applies. Should a user receive the same applications regardless of the device they use? Or should they get a different set of apps based on the device they are interacting with?

The key consideration lies in distinguishing between apps deployed as Required versus those deployed as Available:

  1. Required Applications: These apps are not merely “available” in the company app store; they are automatically and forcefully installed over the air. Users have no choice in the matter. For Required apps, you can assign them to either devices or users.
  2. Available Applications: These apps are accessible in the app store, but users can choose whether to install them. When dealing with Available apps, you can only assign them to users.

As a general practice, I recommend assigning apps directly to users unless you’re dealing with specific scenarios like kiosks or lab environments, where device-level assignments make more sense.

App Protection (MAM)

Keep in mind that App Protection Policies (also known as MAM) can be applied with or without device enrollment. This implies that your focus should be on user objects rather than device objects. When a user logs into an application, these policies are enforced at the application layer, and the device itself doesn’t significantly impact the equation.

Autopilot

When assigning Autopilot profiles, the approach differs from Compliance and Conditional Access. In this case, profiles are exclusively assigned to devices, not users. It’s worth noting that we have the option to select specific device groups or simply choose “All devices” (although there is no corresponding “All users” option).

This approach aligns with the purpose of Autopilot, which revolves around pre-provisioning devices. While Autopilot encompasses more functionality, for the context of our discussion, this covers the essential points.

Conclusion

You learned when to Assign Microsoft Intune Settings to Devices or Users. We did have a look at all the main settings from Compliance & Conditional Access to Applications.
Did you enjoy this article? Dont forget to follow us and share this article. You may also like the the following articles.

Max

Leave a Reply