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.
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).
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!