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:
- Microsoft Endpoint Manager: A deep dive on grouping, targeting and filtering
- Use Microsoft Endpoint Manager filters to target apps and policies to specific devices
- How Application Context, Assignment and Exclusions Work in Intune
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!
Thanks for this nice article Andrew, do you know what I should use if I want to deploy an app to a workstation that is shared by multiple users?
I would just assign that to a device based group
Would there be issues if there is already the same policy applied to the users who will log into the machine? Will there be any conflicts?
Same policy as in contradictory settings
Yes, you will get a conflict on the policies
Hello created 1 application configuration policy from intuen to my organisation and some of the permission are automatically grant form uses corporate onwed device.in app configuration policy I have assigned 1 group which is device based . Can you guide me should I go with user based or device based group in assignment.
Becouse this permission are not auto granted on user device. So can you help me on this I have deployed Microsoft defender for mobile apps on iOS and Android
There are a lot of varaibles, it depends on your use case and how the apps are being deployed (and to what device type)
Hi Andrew,
Good technical explanation, thanks for this. There is a question, if we use setting catalogue profile with User settings of Hello, and assign to Users, User doesn’t get prompt for the create profile when enrolling the device, however there is a default policy(not coming in from Intune, may be some default Windows Hello), kicks in to configure it with different PIN requirement and when Configuration profile targeting user kicks in, it ask again for new PIN requirement.
Is it possible to control this behavior that either device doesn’t ask for this default setting or ask correct one, device targeting is fine though?
thanks
Mohammad
Hi,
Can you check it is disabled/Not Configured in Devices – Enrollment
not configured in Enrollment
So is the rule of thumb for assigning compliance policies to a user group still applicable? Microsoft seemed to have changed the documentation and doesnt have the advice/note , to assign to user group for a ‘user’ device anymore.
Yes, the note has gone, but it’s still much better to assign to users
Hi Andrew,
Thanks for writing an excellent article.
I have created an Intune policy specific to Windows Hello, when create User policy and target Users, it does work for 1st user, but for second user, it gives default settings and not the policy created settings.
Any idea?
Hi,
Which policy did you create for that one? There are a few ways to configure WHfB
Hi Andrew,
What do you recommend when deploying a Wi-Fi policy to user or device groups?
Hi,
How is your Wi-Fi configured? Normally I would suggest user groups, but something like pki may work better at the device level
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
Hi,
Do you have a requirements rule to make sure it doesn’t run outside OOBE?
Something like this:
https://oofhours.com/2023/09/15/detecting-when-you-are-in-oobe/
Is there content in the script which would be visible at the user-level, it could just be Intune reporting showing it as installed for the user
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?
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
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’.
That sounds like a good option, thank you!
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
Hi,
Is the No User showing as well as the active user, or are you just seeing no user on the app install status?
Is the status Failed, or Successful?
Old post but I was interrested in the answer. I do have the problem on some devices where I see duplicate in Intune reports with app install status showing “no user” failed but current user of the device is marked as installed.
Are they device targeted apps/policies?
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?
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
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?
Hi, yes, exactly that. If you target devices, it also hits the system account which doesn’t have a UPN
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?
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
Group tag like manually? We don´t use autopilot, that seems to be related to group tag´s?
If you are hybrid, you could use a dynamic AD group based off the machine OU and drop the dev machines into their own one, that might be easier to manage
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.
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)
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!
Thank you! I’m so glad you find it useful. If there are any particular subjects you would like covered, I’m always open to suggestions.
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.
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
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?
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.