Intune: Choosing whether to assign to User or Device Groups

One of the disadvantages of being an experienced consultant in IT is the fact that once in a while you need to re-learn. With re-learn I mean that for some concepts it’s easier to understand how it works if you come from no-experience. I’ve experienced this with quite some Microsoft products as well. If you know the old version, switching to concepts in a new version might not be that easy compared to when you get to know the new version without any prior knowledge.

I also experienced this “challenge” lately when trying to figure out when to assign applications or configuration to either User Groups or Device Groups.

Update December 2020: I’ve written another article on this subject which might be interesting as well: Designing and building your Microsoft Endpoint Manager/Intune environment for Operations

The Past

In “the past” I worked mainly in environments where Desktops were used and the concept of roaming was introduced on all of these devices. This meant that any user could log on to a machine and by using a so called Roaming Profile the user settings were applied to the machine and the user could work as normal. Even though later more and more machines were becoming laptops, the concept of roaming was almost never abandoned and desktops and laptops were treatened equally from a management point of view

Applications

I have been working with ConfigMgr since 1998, at that time and for many years to come we only used collections containing devices to target our appliciations using “Advertisements” which we now know as “Deployments”. Later we started implementing mechanisms to target our applications towards users member of a group within Active Directory, so that we could provide users with applications based on AD group membership. Even though this targeting to users is technically possible most of the deployments today at my customers are still targeted at device collections. (base applications, updates to existing applications etc..).  Microsoft later introduced the concept of “Primary Device” where applications targeted to users were only installed if the user was working on his primary device.

Configuration

Configuration in the old way is being accomplished by targeting, Login scripts,  Group Policy Objects (GPO) or Group Policy Preferences (GPP) to either Devices or Users. There it was actually quite simple, if you wanted to target machine based settings, you use a Computer Login Script, GPO or GPP targeting a OU containing computer accounts. Most of the times the settings would provision a setting in the registry residing somewhere under HKEY_LOCAL_MACHINE. When applying some of these settings performing a reboot was necessary in order to make the setting effective. When you want to set a setting related to the user, where the setting would result in a registry setting under HKEY_CURRENT_USER you would either user a Login Script, GPO or GPP targeting an OU containing User accounts. Later a hybrid scenario was introduced where user settings were applied only when the user was logging in on a certain computer, this was called Loopback processing and it’s main use case was for Terminal Servers, where some users settings were supposed to be different once the user logged on to the Terminal Server.

Today

So with this knowlegde from the past, I brought this experience with me to the new world, which in my case is reflected in the Microsoft Intune product today. Intune provides similar functionality compared to what we used to do with SMS/ConfigMgr (or Microsoft Configuration Endpoint Manager as we should call it today), Login Scripts, GPOs en GPPs. The only difference here is that whatever you want to target within Intune can either be done to Azure Active Directory User Groups, or Azure Active Directory Device Groups. 

To make things even more “complex” or “confusing”, settings which can be set in the form of Configuration Profiles, or to be precise “Device Configuration Profiles” as they are called in the Intune portal can actually contain both Device based settings (f.e. enable Bitlocker), but also user based settings (provide a customized start page in the browser).

One other change in concept I experience nowadays that devices are more tight to the user, meaning that in most of the cases there is a direct relationship between the user and the device the user is working on. There are of course some exceptions depending on the use case.

With the introduction of the Security Baseline and now the concept of Policy sets, it became even more confusing to determine whether to apply settings to either the user using a Azure AD User Group or device using a Azure AD Device Group.

Github to the rescue

While struggling with these questions I decided to comment on the Microsoft provided documentation. You can follow the interaction between me and Microsoft here: https://github.com/MicrosoftDocs/IntuneDocs/issues/2992#issuecomment-557300939

My initial question:

Can we have some general “best practise” guidance on when to “assign” to a Azure AD User Group versus “assigning” to a Azure AD device group? Or should assignment behave the same.

I got a reply sometime later from Mandy Ohlinger, who is a senior content developer at Microsoft and active on github updating Microsoft documentation.

The most important take-away is that it depends on what the goal is. Device profiles always go with the device, and don’t care if there many users or 0 users. User profiles always go with users and the devices they sign in to. I included some examples for both scenarios.

And as you can see the documentation for “Assign user and device profiles in Microsoft Intune” now contains a section on “User groups vs. Device groups”

Some highlights from the documentation:

For devices:

If you want to apply settings on a device, regardless of who’s signed in, then assign your profiles to a devices group. Settings applied to device groups always go with the device, not the user.

Use device groups when you don’t care who’s signed in on the device, or if anyone is signed in. You want your settings to always be on the device.

For users:

Profile settings applied to user groups always go with the user, and go with the user when signed in to their many devices. It’s normal for users to have many devices, such as a Surface Pro for work, and a personal iOS device. And, it’s normal for a person to access email and other organization resources from these devices.

To summarize, use user groups when you want your settings and rules to always go with the user, whatever device they use.

That still left some questions though, so I reacted with the following follow up question:

Thank you for this addition to the documentation. The only remark I have is related to applying device settings to a user group. In the old days, with GPO you had User GPO’s and Device GPO’s. In some scenario’s, a device GPO required a reboot before it becomes effective. How about adding device specific settings to a user group (like the security baseline for example, something which under water makes a modification into HKLM), will a reboot be needed than to make the setting effective? Or due to the behavior of CSP, this is not needed anymore and the settings will be effective directly.

Which was replied with the following answer:

Reboots happen at the setting level, regardless if the policy is assigned to a user. Some CSPs may force a reboot, and some may apply after the next reboot. But, the answer is: It depends. As an admin, use your judgment on rebooting the device. For example, if it’s security-related, such as enabling BitLocker or anti-virus, then rebooting the device may be in your best interest. If it’s hiding the sleep button, then maybe it can wait.

Targeting applications

For applications, I personally have a preference to deploy (using “assignments”) applications to users when using Intune. While I can see some use cases to target devices espacially within Hybrid configuraitons with ConfigMgr where we can now fill Device Groups with members of a collection. Example use case, deploy laptop specific device application to device group containing that specific model of the laptops.

Conclusion:

We have come a long way, from getting documentation from CD’s (the TechNet CD’s suplied containing static documentation) towards documentation maintained via Github which adopts to user comments. Isn’t that great!

Concerning choosing between targeting device or user groups, it depends… 🙂