Target policy to users or devices?

[peterlewis]

Until now it's felt like scoping policy/software deployments to 'Users' as opposed to 'Devices' has been preferable. It has the benefit of ensuring that any new device used by a user will instantly receive the relevant policy and software, maintaining the granularity and helping to ensure that the correct scope of users receive specific policy and software deployments.

However, if an organisation has the presence of shared devices (i.e. loan laptops), I'm wondering if scoping policy to 'Users' is the right fit, given the presence of such shared devices.

From reading the Microsoft documentation it would seem that you cannot target to a User group (i.e. 'All Users) and then exclude a device group (i.e. 'Shared Devices'). I can't help but think that such an exclusion would make it a lot simpler to target policy at users for 'Generic' devices whilst being able to have a different set of policy for shared devices.

Would appreciate the thoughts of the community on this. How would you target your policies in this scenario?

Thanks!

Peter

[#2]

My answer is based on Intune - MDM.  In case of  shared devices (more like Kiosk devices) these are targeted via specific Dynamic AAD groups or profiles. These are 'userless' devices and do not have any association with a user account. It will never the traditional policies that are targeted towards 'All users'. 

[#3]

Hey Shuchi!

Thank you for the quick response, it's much appreciated! :)

I've found that even when there is no user/device affinity (for example, a device that is enroled with a Device Enrollment Manager account or with Self Deploying Autopilot), when a user logs into that device, policy and software that has been targeted to the specific user gets deployed to the shared device. Is this behaviour different to what you've seen? Thanks again! :)

[#4]

I have not specifically used DEM /self deploying autopilot for various reasons (limitations of DEM) so cannot confirm. However, from your description I can expect policies to flow down in that scenario.  Is there a way to create another Dynamic group perhaps for DEM/ Self Deploying Autopilot that be excluded while targeting all users in other policies?

[#5]

It doesn't appear to be possible to combine user targeting with device exclusions and vice-versa. The only solution that I can envisage right now is to create groups of devices based on users as per https://blogs.technet.microsoft.com/smeems/2018/05/11/user-based-device-groups/.

[#6 · Accepted solution]

Hey Peter,

yes you are right, user policies will travel with the user. So if a user has an user policy to configure his background for example and the logs on to a different device it will get the policy there as well. There is no exception to this in case of shared devices because of the perspective of the user it's just another device and his user policies are flowing down. There is not a concept of primary devices and user should only get configs on primary devices or so. So if you want to clearly separate you need to use device targeting only. Back in the GPO days we could use loopback policies in replace mode but this is not available for Intune MDM managed devices. Again, clear separation without traveling user policies can be achieved with device targeting only. Normally user policies are not a big problem, as even on a shared device a user should get his experience in terms of user configurations. If the device is really special (dedicated special use case) then mostly dedicated accounts are used and they can be excluded from user config. For digital signage there is often a local account or again a dedicated special purpose account used. I see the problem only if you have the need for shared devices were people need to logon with their own account but need to have a different settings as normally in their user policy. Most of the shared device scenarios I can think of are not like this and a user can still have his user policies applied to the shared device and the device itself has some more device policies for example. This is in most of the cases a viable solution.

best,

Oliver

[#7]

Thank you so much for taking the time to provide such an insightful response. It really is appreciated and reading your confirmation of behaviour as well as the reasoning for this has been invaluable!

Will certainly bear your words and thoughts on the behaviours in mind! :)

Thanks again! :)

Peter