Intune – User vs Device Targeting

Following on from my previous post looking at User vs System deployments in this one I will look at another confusing part, Intune targeting.

An important note – with very few exceptions, there is no right or wrong way to target, this is my opinion and your scenario may differ

Before starting, I would recommend having a look at these posts from Scott Duffey, the expert in everything targeting and filtering:

The first thing to remember is NEVER mix device and user based targeting due to the way Intune sychronises and queries groups. You could have an application targeting users but with certain devices excluded, but by the time the exclusion has queried, the app could have already installed.

If you have a situation like this where you want users to have an app/policy/script but only on certain devices (laptops for example, or non-BYOD), use a user group with a device based filter on top.

The beauty of filtering is that you can target at users to give a better device-agnostic experience, but still be able to control which devices it targets.

Dynamic and Static Groups

I’m a big fan of dynamic groups, they make on-going estate management easier whether a user or device group. For example, if user A replaces their machine and you have device based targeting on a statically assigned group, you will need to remember to add the new machine and remove the old one from the group. For a small number of users and devices, this is fine, but when you start to look at the multi-thousands, both device replacements and staff churn will be high so it quickly becomes a full time task (plus you’re at the mercy of the HR starters and leavers process).

If you watch the video from Scott above you will see the process for group membership within Intune

Once you add in the time for a dynamic group membership rule to process, you can get a delay when using dynamic groups. I personally think it’s worth the wait, but that depends on your user base.

All Users and All Devices

These are virtual groups available only within Intune.

The All Devices group includes any device enrolled into Intune (including BYOD and all operating systems). It is recommended not to create your own group to simply contain all devices and use this one with filters applied (Corporate owned, Windows OS for example). It’s a quick and easy way of hitting all machines without waiting for processing to complete, but management is entirely within Intune and I prefer to make use of Azure AD so I can use groups for other parts such as Conditional Access and PIM.

It is worth keeping in mind, if you’re using Autopilot, I imagine you’ll already have an Autopilot devices group used during enrollment which is basically all corporate owned Windows devices.

The All Users group is every user in the estate with an Intune license. Again, it works well with filters (to exclude BYOD as an example), but often a dynamic or static group will be easier to manage.

User Targeting

The one situation which ONLY works with user targeting is applications marked as Available to install in the Company Portal. Company Portal runs in the User Context so even applications which run as System need to be targeted to users (when “Available”) to display.

It is also recommended to user User Targeting for any single owner devices with Compliance Policies. Otherwise compliance will run against both the user and SYSTEM account and could cause issues (see here)

Obviously any policies, apps and scripts which run at the user level are best targeted to users, otherwise a user could login to a different machine and have a different experience.

My personal preference is for any non-baseline applications to be user targeted. I would class baseline as the must-have apps on any machine, your security suite, firewalls, VPNs, that type of application. You could include Office in this as well, but that depends on your estate, if you have a mix of F3 and E3 licenses, you may be better off using dynamic user groups to check on the licenses and target appropriately.

It is also worth considering the policies set in your baseline settings. For example, if you have an Android/iOS policy which blocks tethering, but you have a particular subset of users who are going to need it, you are best off removing that setting from your baseline and adding it to a new policy with user-level targeting.

You also need to look at the user personas involved. If you have 1:1 user-device relationship, it doesn’t make a huge difference, but if you have users who roam between devices, especially shared devices, user-based targeting is going to give them the best experience.

So, what happens if you have device-level policies (targeting HKLM for example) with a user group assigned to it and multiple users login to the same device with different policy settings for each user. In this situation, the policy will apply to the logged in user so as each user logs in, the setting assigned to them will apply.

This is worth considering, especially with multi-user shared devices as some HKLM keys may not apply until the next reboot so you could find yourself with the policy technically applying to the subsequent user rather than the current one (and your machines may not appreciate feeling like they are in a kris-kross song).

Device Targeting

Whilst not set in stone, I would include your Pilot/Preview update rings in something that should be Device only targeted. Generally these are aimed at your IT staff initially, who may login to other devices for testing or troubleshooting and the last thing you want is them installing a preview build onto the machine!

Microsoft Defender for Endpoint (MDE) works in the device context so any MDE policies will need to be device targeted.

There are also some security related policies from Config Manager which again won’t work in the user context for those of you working in a co-managed environment.

As mentioned earlier, device targeting works best for your baseline settings which you want to apply to all devices as quickly as possible, so we are looking at the likes of Bitlocker, Windows Defender, anything which you would see as critical and unlikely to ever be drastically changed for different user groups.

When using Autopilot, also consider your PowerShell scripts. When device targeted (and obviously system context), these run early on during the Preparing your Device phase, prior to any user login or any app installations. This is where I would suggest running any bloat removal scripts as you can be sure that you aren’t removing anything you have deployed and also you won’t be competing with any other application installations when running an uninstall.

If you are from a traditional GPO background, think of these as the policies you would set at a high-level within the AD structure and the user targeted as those at lower OU level.

Also worth keeping in mind, device targeting works as long as the machine is switched on, the policy/script/app will apply as soon as the device checks in, even at the login screen. With user targeting, the user needs to be logged on for it to apply.


There is no fixed approach for targeting and often a mixed approach will give the best experience. In modern management, it’s worth remembering that it should be reasonably device agnostic so if you can give the users the same experience across multiple devices and platforms, that will give everyone involved an easier life. With Windows 365 and AVD thrown into the mix, this becomes all the more important.

My preferences tend to lean towards more at the user side with a select few key policies looking at the device, but your requirements may lean more towards device targeting.

As always, comments are most welcome!

8 thoughts on “Intune – User vs Device Targeting”

  1. Hi Andrew,
    Thanks for the summary and the insights!
    I have a special use case for Windows Update rings: in my case there are different Insider and Pilot rings which are assigned to dynamic user groups. But in the last Production ring I want to cover all devices essentially, not all users. Because the self-deploying devices or Kiosks may never have a user affinity or assignment.
    What are your thoughts on that?

    Reply
    • Hi Niklas,
      That’s an interesting one!
      I would probably use the All Devices group with filtering applied to ignore any devices where the primary user is one of your Insider or Pilot users.

      Reply
  2. For a managed IT services managing multiple environments that are predominantly azure ad joined, we find targeting user groups with the exception of autopilot profiles (also have as fewer groups as possible) is far easier to manage, train IT staff, troubleshoot and document. The focus is on the user (which makes sense for SaaS solutions) and not the device or both.

    Reply
    • Yes, I can fully appreciate that (and have done the same myself). You could of course use your Autopilot devices group for some security policies if you wanted to target devices which cuts out any management tasks on group membership.
      Policy sets work nicely with user assigned groups, but until they support Win32 apps, I don’t tend to use them much

      Reply
  3. Not really a thought proving comment here, but I wanted to say that I love this newsletter/website. The information is so well put together and easy to read. I appreciate the logic being used when trying to convey the overall message.

    Thank you!

    Reply
  4. Hi Andrew, fantastic article mate! In the comments here, you mention using ‘filtering applied to ignore any devices where the primary user is one of your Insider or Pilot users’. Where/how are you configuring that filter? It’s not one of the currently available selections.

    Reply
    • Hi David, glad you’ve found it useful. At the moment, the only way would be to exclude them via Device Name. Ideally your insider and pilot rings are device targeted anyway, but it’s still a manual task to add the device names into the filter (I’d probably do filters for each group)
      If you have lots of devices, I’m sure it could be automated using Graph to grab members of the AAD group and add them into a filter (happy to help if needed)

      Reply

Leave a Comment