Intune Policy Assignment Basics

The easiest step in any policy creation. Yet there is a possibility that the policy assignment to end up with errors. I want to discuss that in this article.

We have our policy created with all the settings and we are pretty happy with it. The next step is assigning it to one of the options from All Users, All Devices, or to a selected Group/s. Same as setting up exclusions if needed. Of course, we know our target device or user groups, and it’s very easy to add those groups under Assignment. So what can go wrong?

Right off the bat, as you can see above, there is an information strip coming up when you go to the assignments section. When excluding groups, you cannot mix user and device groups across include and exclude.

What does this really mean? You can’t exclude the same device or user that you already had in include? or you can’t have users and devices in the same group to include and exclude? it was a bit confusing for me at 1st.

We don’t want to worry about this up to some extent as long as we do includes only. The confusion comes when we need to exclude.

When to use Device Groups? When to use User groups?

It comes down to your policy end goal. This is similar to GPOs.

User Groups – If you need to apply the policy to users so that whenever they log in to a managed device, the policy will apply

Device Groups – Policy will be applied to any managed device regardless of the logged-on user

Note that when you try to create policies, there are some policies that are specific to either Users or Devices. At that time, the exact group should be selected.

Removing a Device or User Groups Won’t Really Undo the Changes…..Sometimes

Let’s understand why this is happening like that. The policy settings are based on the CSPs (Configuration Service Providers) and these settings will configure different parts of the Windows device depending on the policy you create.

These settings behave in different ways. Some settings will go back to the original state when the removal or added to the exclusions at a later stage.

Some settings, once they are configured, it will not go back to their original state. Or you can think it as the tattooing effect of the settings. This has been a bit of a worry sometime ago but a lot of tattooing settings are now undoing, yet there are settings that behave differently.

Sometimes the device needs a reboot to properly undo the setting.

From Microsoft Learn 👇🏽

To change a setting to a different value, create a new policy, configure the setting to Not Configured, and assign the policy. When the policy applies to the device, users should have control to change the setting to their preferred value.

Using Device Filters for User Group Assignments

This comes as a best practice when you need to assign policies to users and if you need to exclude some devices from the assignment. Device Filters can be used to exclude or include devices depending on the scenario. The principal behind this is user policy will be any managed device that the user is logging on to, but with a filter, you can specify not to get the policies to be assigned.

For more on the policies, check my previous blog below

How To Create and Usages of Microsoft Endpoint Manager (MEM) Device Filters

Policy Assignment Principals

Microsoft has some principles to follow when including and excluding groups. I have added them straight from the MS Learn pages

• Think of Included groups or Excluded groups as a starting point for the users and devices that will receive your policies. The Azure AD group is the limiting group, so use the smallest group scope possible. Use filters to limit or refine your policy assignment.

• Assigned Azure AD groups, also known as static groups, can be added to Included groups or Excluded groups. Typically, you statically assign devices into an Azure AD group if they’re pre-registered in Azure AD, like with Windows Autopilot. Or, if you want to combine devices for a one-off, ad-hoc deployment. Otherwise, it might not be practical to statically assign devices into an Azure AD group.

• Dynamic Azure AD user groups can be added to Included groups or Excluded groups.

• Excluded groups can be groups with users or groups with devices.

• Dynamic Azure AD device groups can be added to Included groups. But, there can be latency when populating the dynamic group membership. In latency-sensitive scenarios, use filters to target specific devices, and assign your policies to user groups. For example, you want policies assigned to devices as soon as they enroll. In this latency-sensitive situation, create a filter to target the devices you want, and assign the policy with this filter to user groups. Don’t assign to device groups. In a userless scenario, create a filter to target the devices you want, and assign the policy with the filter to the “All devices” group.

• Avoid adding dynamic Azure AD device groups to Excluded groups. Latency in dynamic device group calculation at enrollment can cause undesirable results. For example, unwanted apps and policies might be deployed before the excluded group membership is populated.

Support Matrix

This may come in handy when you need to assign groups. This is again from the Microsoft Learn docs as it has a good explanation of the combinations.

• ✔️: Supported
• ❌: Not supported
• ❕ : Partially supported

Scenario	Support
1	❕ Partially supported Assigning policies to a dynamic device group while excluding another dynamic device group is supported. But, it’s not recommended in scenarios that are sensitive to latency. Any delay in exclude group membership calculation can cause policies to be offered to devices. In this scenario, we recommend using filters instead of dynamic device groups for excluding devices. For example, you have a device policy that’s assigned to All devices. Later, you have a requirement that new marketing devices don’t receive this policy. So, you create a dynamic device group called Marketing devices based on the enrollmentProfilename property (device.enrollmentProfileName -eq "Marketing_devices"). In the policy, you add the Marketing devices dynamic group as an excluded group. A new marketing device enrolls in Intune for the first time, and a new Azure AD device object is created. The dynamic grouping process puts the device into the Marketing devices group with a possible delayed calculation. At the same time, the device enrolls into Intune, and starts receiving all applicable policies. The Intune policy may be deployed before the device is put in the exclusion group. This behavior results in an unwanted policy (or app) being deployed to the Marketing devices group. As a result, it’s not recommended to use dynamic device groups for exclusions in latency sensitive scenarios. Instead, use filters.
2	✔️ Supported Assigning a policy to a dynamic device group while excluding a static device group is supported.
3	❌ Not supported Assigning a policy to a dynamic device group while excluding user groups (both dynamic and static) isn’t supported. Intune doesn’t evaluate user-to-device group relationships, and devices of the included users won’t be excluded.
4	❌ Not supported Assigning a policy to a dynamic device group and excluding user groups (both dynamic and static) isn’t supported. Intune doesn’t evaluate user-to-device group relationships, and devices of the included users won’t be excluded.
5	❕ Partially supported Assigning a policy to a static device group while excluding a dynamic device group is supported. But, it’s not recommended in scenarios that are sensitive to latency. Any delay in exclude group membership calculation can cause policies to be offered to devices. In this scenario, we recommend using filters instead of dynamic device groups for excluding devices.
6	✔️ Supported Assigning a policy to a static device group and excluding a different static device group is supported.
7	❌ Not supported Assigning a policy to a static device group and excluding user groups (both dynamic and static) isn’t supported. Intune doesn’t evaluate user-to-device group relationships, and devices of the included users won’t be excluded.
8	❌ Not supported Assigning a policy to a static device group and excluding user groups (both dynamic and static) isn’t supported. Intune doesn’t evaluate user-to-device group relationships, and devices of the included users won’t be excluded.
9	❌ Not supported Assigning a policy to a dynamic user group and excluding device groups (both dynamic and static) isn’t supported.
10	❌ Not supported Assigning a policy to a dynamic user group and excluding device groups (both dynamic and static) isn’t supported.
11	✔️ Supported Assigning a policy to a dynamic user group while excluding other user groups (both dynamic and static) is supported.
12	✔️ Supported Assigning a policy to a dynamic user group while excluding other user groups (both dynamic and static) is supported.
13	❌ Not supported Assigning a policy to a static user group while excluding device groups (both dynamic and static) isn’t supported.
14	❌ Not supported Assigning a policy to a static user group while excluding device groups (both dynamic and static) isn’t supported.
15	✔️ Supported Assigning a policy to a static user group while excluding other user groups (both dynamic and static) is supported.
16	✔️ Supported Assigning a policy to a static user group while excluding other user groups (both dynamic and static) is supported.

Wrapping up

Few things worth noting before wrapping up. Though this may seem a direct step, it involves understanding the assignment principles to create an error-free policy.

• Always start with a pilot group. If anything goes wrong, it’s easy to undo the policy
• Get to know the CSP locations you applying via the policies and if you need any manual intervention, you can easily navigate to it
• Understand when to use the device filters as they will come in handy