Intune – User vs Device Targeting

by

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!

28 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

  5. Is it possible to target all devices with Attack surface policies, and also exclude a group of dev-users from that ?
    And create a seocnd dev-users policy that applies different ASR policies?

    Reply

    • Not easily, you can’t mix user and device targeting.
      Your best option would probably be to add a group tag to the dev machines, create a dynamic AAD group on the tag and then exclude that group from the ASR policies.

      Unless your devs all use a particular model machine in which case you could use a device filter

      Reply

  6. I have a branding Win32 app (pretty much just a .ps1 file wrapped up as Win32). I’ve applied it to the All Devices and have noticed in Intune that it gets applied to both the actual user who logs in and to the “No User” UPN. What’s the “No User” UPN?

    I have this app set as mandatory to install before the user gets to their desktop via the corresponding ESP Profile. Since this is a baseline, I figured All Devices made the most sense, but it seems to be that assigning to All Users would ultimately accomplish the same thing, no? I guess maybe if a new user signed in it would again have to pull down this Win32 app and apply it whereas when using All Devices it only has to run once? Is this the true benefit to the All Devices virtual group in this situation?

    Reply

    • Hi,
      The No User UPN is basically the SYSTEM context on the machine.
      If you want it as a required app during ESP, targeting the device is absolutely fine and means it runs earlier in the process.
      Targeting users won’t install every time someone logs in unless it is installing at the user level. If you are installing to the device (Program Files for example), it will detect the app is already there and just ignore it.
      I hope this helps

      Reply

      • Hi Andrew! Thanks for the helpful article.

        If I *don’t* want the No User UPN to show up for an app (eg. Microsoft 365 Apps), do I need to target that app to users, rather than to devices? Is that what you’re saying?

        Reply

  7. Hello and thank you for such a detailed post.

    Regarding the No User, I use the System context to run most of my Win32 apps as System user, as it wouldn’t install if run as user. Is there any way of avoiding this No User installation as it creates a lot of wrong info on the installation statistics of the app?

    Best regards

    Reply

  8. Excellent advice Andrew. Thank you for posting.
    Just adding what I do with our estate (to make administration a little easier)
    I base group membership on device naming where possible, because we have 4 type of devices and 2 organisations.
    Therefore, I use smart naming for the devices.
    Example: Laptop for company 1 that is deployed through Autopilot might be named: LT-C1-AP-003
    This means I can dynamically assign group membership based on name ‘contains’.

    Reply

  9. If you are targeting a user group with a configuration profile, which applies device level settings and the user logs out of the device, will those settings be removed in subsequent syncs? For example, user logs out of device, device sits idle and powered on over a weekend, intune’s scheduled sync tasks run, what would be the expected result?

    Reply

    • The setting will remain until someone else logs in with a different setting. Whilst you are targeting a user group, the profile is still applying to the HKLM hive so remains on the machine until it receives a different setting

      Reply

  10. really excellent post and series of posts. We are new to intune/autopilot and have a couple of scripts wrapped in win32 which should only run in OOBE/ESP system context.
    the apps are assigned to devices only, no users, however when we look at the app overview it seems to be installed in both the system context and the logged on user.

    the script has a requirement that it should only run in OOBE/ESP via HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\defaultuser=defaultuser0

    any ideas why both device and user are getting the app/script?

    many thanks

    Reply

Leave a Comment