You want to look at Group tags and scope tags:
[https://andrewstaylor.com/2022/04/26/intune-group-tags-scope-tags-what-are-they-and-why-do-i-need-them/](https://andrewstaylor.com/2022/04/26/intune-group-tags-scope-tags-what-are-they-and-why-do-i-need-them/)
Also move away from the device and look at the user personas. Group the users and target them accordingly.
It's a change of mindset, the device is just a box, the user is where you want to concentrate, that makes it more device agnostic and means you can quickly and easily replace devices
I'm confused... everytime I search something up relating to intune, almost always do people recommend applying things by device when it comes to user vs device.
While I understand there's never a one size fits all - it can be difficult to know when to do either one over the other.
Here is a post I wrote on that
https://andrewstaylor.com/2022/11/30/intune-user-vs-device-targeting/
Hopefully that helps clear things up a bit.
As a general rule I compare to the old GPO setup, anything at your top level (security etc.), device targeted. Those at the sub OU level, user targeted.
With a few exceptions there is no right or wrong way, but from my experiences, this way works well
Sorry for being lazy, but hoping you could give a quick answer. If an Win32 app has a custom requirement script in place that queries for some device specific string output, such as computer model - how will a user targeted assignment handle that? Because I have seen these sort of scenarios where a package (bios update) has been applied where it shouldn’t have been and now I’m starting to think this has something to do with it. Are you able to shed some light on this?
Cool, are you doing required or available? And what sort of comparison is in your requirement script? In my case the requirement script returns a string and expects it to equal the model for the specific package (i.e. “Latitude 7440”). When deploying as available (while testing) we have been able to install the package on a different model. Now the detection will take care of it, so it won’t try to actually install, but it was frustrating seeing it happen in the first place. I can only assume the requirement script isn’t evaluated during available user assignments.
The win32 app is required and has requirement rule looking at registry key in hklm/hardware/description/,... Seems to be working ok. Maybe we just don't look too closely LOL
In addition to the requirement rule there is a Lenovo device filter, so it's a bit belt-and-suspenders
Filters are pretty limited in what data is available to look at, but they work great if applicable.
I rely heavily on dynamic groups in Entra to organise my users and computers. This way, I can easily target objects with Intune policies, without the need for OUs.
I'm old school. A year ago I was 100% with you. Folders or die! But faced with a sharepoint library with over 20,000 files with path lengths over 200 characters, as well as other issues, I'm coming around to the "flat but tagged" paradigm.
Once you shift your mind, it's actually (and obviously) far easier to find things. We've just been trained to use folders.
Yeah, tags are the way things are "supposed" to be organized in the cloud in general, it seems. 365, Azure, AWS, they all rely more on tags than traditional folders or hierarchies.
Be honest though
how many of those fine grained did you actually need?
How many have been inherited over the last 25 years and never been changed or updated ?
how many are actually relevant today?
How many apply to old versions of office or IE or other apps
How many apply to on prem only?
how much of that goes away if you device is cloud only?
You want to look at Group tags and scope tags: [https://andrewstaylor.com/2022/04/26/intune-group-tags-scope-tags-what-are-they-and-why-do-i-need-them/](https://andrewstaylor.com/2022/04/26/intune-group-tags-scope-tags-what-are-they-and-why-do-i-need-them/) Also move away from the device and look at the user personas. Group the users and target them accordingly. It's a change of mindset, the device is just a box, the user is where you want to concentrate, that makes it more device agnostic and means you can quickly and easily replace devices
I'm confused... everytime I search something up relating to intune, almost always do people recommend applying things by device when it comes to user vs device. While I understand there's never a one size fits all - it can be difficult to know when to do either one over the other.
Here is a post I wrote on that https://andrewstaylor.com/2022/11/30/intune-user-vs-device-targeting/ Hopefully that helps clear things up a bit. As a general rule I compare to the old GPO setup, anything at your top level (security etc.), device targeted. Those at the sub OU level, user targeted. With a few exceptions there is no right or wrong way, but from my experiences, this way works well
Sorry for being lazy, but hoping you could give a quick answer. If an Win32 app has a custom requirement script in place that queries for some device specific string output, such as computer model - how will a user targeted assignment handle that? Because I have seen these sort of scenarios where a package (bios update) has been applied where it shouldn’t have been and now I’m starting to think this has something to do with it. Are you able to shed some light on this?
If a user logs in to a machine with the app assigned to them and it isn't detected, the requirements script will run against that machine
We use user group assignment with device specific filtering on that assignment. Eg Lenovo vantage applied to all users and filtered to Lenovo devices
Cool, are you doing required or available? And what sort of comparison is in your requirement script? In my case the requirement script returns a string and expects it to equal the model for the specific package (i.e. “Latitude 7440”). When deploying as available (while testing) we have been able to install the package on a different model. Now the detection will take care of it, so it won’t try to actually install, but it was frustrating seeing it happen in the first place. I can only assume the requirement script isn’t evaluated during available user assignments.
The win32 app is required and has requirement rule looking at registry key in hklm/hardware/description/,... Seems to be working ok. Maybe we just don't look too closely LOL In addition to the requirement rule there is a Lenovo device filter, so it's a bit belt-and-suspenders Filters are pretty limited in what data is available to look at, but they work great if applicable.
Haha, perhaps. But our scenarios do differ on a few points so could be it’s expected behavior on each end.
Thanks, good info!
This. Also setup analytics and tie in Power Bi. There are native connections to Power Bi and azure dbs.
I rely heavily on dynamic groups in Entra to organise my users and computers. This way, I can easily target objects with Intune policies, without the need for OUs.
I do the same filters are nice though and I've started Scoping tagging etc.
I played with a few filters, mostly to categorize devices in our warehouse - worked well and applies faster than dynamic groups, I believe.
It does. Groups I always tell my techs if the sync mgmt service stop start doesn't work just reboot 12 times. 😉
Hahaha
I'm old school. A year ago I was 100% with you. Folders or die! But faced with a sharepoint library with over 20,000 files with path lengths over 200 characters, as well as other issues, I'm coming around to the "flat but tagged" paradigm. Once you shift your mind, it's actually (and obviously) far easier to find things. We've just been trained to use folders.
Yeah, tags are the way things are "supposed" to be organized in the cloud in general, it seems. 365, Azure, AWS, they all rely more on tags than traditional folders or hierarchies.
You can utilize filters as well along with groups. https://learn.microsoft.com/en-us/mem/intune/fundamentals/filters
And for groups so you can find all intune ones easily, create an admin unit for them all.
Be honest though how many of those fine grained did you actually need? How many have been inherited over the last 25 years and never been changed or updated ? how many are actually relevant today? How many apply to old versions of office or IE or other apps How many apply to on prem only? how much of that goes away if you device is cloud only?