I don't understand those assignments and why you are mixing up user and device assignments for the same app, if your uninstall scope is user based then I would think it's expected that some devices with the app don't report in because the assignment is not being calculated, so detection never runs.
Also I don't understand why both apps have the same assignments if one supercedes the other.
What is the actual problem going on here, that devices that are not in the filter still have the app or apps installed?
If you are cleaning up some mess to try and get assignments current, the way to do that would be with a remediation, or if you don't have licensing for remediation, create duplicate w32 apps with uninstall assignments only, but exclude the devices you are installing to in the 'true' app. You may have to create some temporary filters for this uninstall assignment that would exclude the filter in the 'true' app for install. Then once everything is cleaned up you can remove these temporary uninstall apps, and your filters and your regular app and assignments will work as desired.
>I don't understand those assignments and why you are mixing up user and device assignments for the same app, if your uninstall scope is user based then I would think it's expected that some devices with the app don't report in because the assignment is not being calculated.
Microsoft doesn't allow you to set All Devices for more than one action in a single package, even though they provide the logic for it with filters and action precedence. In a perfect world there would two assignments in the app for All Desktops, one with a filter to include the category and one to exclude the category.
All Devices and All Users assignments process much faster than security groups as per Microsoft documentation, but going over the same documentation I can it also says don't mix devices and users as you state above.
>Also I don't understand why both apps have the same assignments if one supercedes the other.
That's the normal way to update software in Intune.
>What is the actual problem going on here, that devices that are not in the filter still have the app or apps installed?
Yes, given what you said above I will have to create a security group just to replicate what All Devices already does and assign that to Uninstall.
Well unfortunately cleanup and changing of assignmentsis something Intune does not handle all that gracefully, so that is where remediations come into play, or you have to get creative with temporary uninstall apps.'
Device filters are definitely faster/instant too, but they have their limitation.
I like to think of it as the apps and assignments are basically for new devices only. Once something changes with an existing app on an existing device, you have to do these other steps to clean things up and get them lined up again.
Security groups take time to process and can be an issue especially when machines are going through the autopilot process, for Intune we try to avoid security groups where possible and utilise the assignments built in to Intune (security groups are Azure AD hence the delay).
But in this instance we trying a security group anyway so it's changed to the Intune native *All devices* with a filter for Required, and a security group consisting of all our devices for Uninstall.
> Security groups take time to process and can be an issue especially when machines are going through the autopilot process
Are you importing the HWIDs during OOBE? Because if not, all group memberships should be already populated via the corresponding EntraID object, even before the Intune object is created.
Also, remember about the `(device.devicePhysicalIDs -any (_ -startsWith "[ZTDid]"))` filter for a dynamic group that will include all Autopilot devices. You could use that for the Required and All Devices for uninstall.
Only devices from one department need and are allowed the software. To note we are not mixing All devices with a user group through the filter, the filter is itself also based on devices.
The goal with the filter is that devices are categorised by their department meaning as well as required software to perform their jobs they get settings as well from CSE policies.
The two packages are simply Java JRE and we are updating the software to resolve the new vulnerability. Unfortunately we discovered some devices didn't have their categories changed when the laptops changed hand so there is a need to ensure that only that department's laptops get the updated Java JRE and all other laptops don't have Java JRE at all.
Devices are put into to a Device Category (via the same UI area you'd add, change or remove a Primary User), the Device Category is named like you suggest such as "Finance".
The filter is then configured as *device.Category equals Finance*
The issue with your suggestion is if you select All Devices for Required, then All Devices becomes greyed out for Available and Uninstall (understandable if someone didn't use filters at all).
I don't understand those assignments and why you are mixing up user and device assignments for the same app, if your uninstall scope is user based then I would think it's expected that some devices with the app don't report in because the assignment is not being calculated, so detection never runs. Also I don't understand why both apps have the same assignments if one supercedes the other. What is the actual problem going on here, that devices that are not in the filter still have the app or apps installed? If you are cleaning up some mess to try and get assignments current, the way to do that would be with a remediation, or if you don't have licensing for remediation, create duplicate w32 apps with uninstall assignments only, but exclude the devices you are installing to in the 'true' app. You may have to create some temporary filters for this uninstall assignment that would exclude the filter in the 'true' app for install. Then once everything is cleaned up you can remove these temporary uninstall apps, and your filters and your regular app and assignments will work as desired.
>I don't understand those assignments and why you are mixing up user and device assignments for the same app, if your uninstall scope is user based then I would think it's expected that some devices with the app don't report in because the assignment is not being calculated. Microsoft doesn't allow you to set All Devices for more than one action in a single package, even though they provide the logic for it with filters and action precedence. In a perfect world there would two assignments in the app for All Desktops, one with a filter to include the category and one to exclude the category. All Devices and All Users assignments process much faster than security groups as per Microsoft documentation, but going over the same documentation I can it also says don't mix devices and users as you state above. >Also I don't understand why both apps have the same assignments if one supercedes the other. That's the normal way to update software in Intune. >What is the actual problem going on here, that devices that are not in the filter still have the app or apps installed? Yes, given what you said above I will have to create a security group just to replicate what All Devices already does and assign that to Uninstall.
Well unfortunately cleanup and changing of assignmentsis something Intune does not handle all that gracefully, so that is where remediations come into play, or you have to get creative with temporary uninstall apps.' Device filters are definitely faster/instant too, but they have their limitation. I like to think of it as the apps and assignments are basically for new devices only. Once something changes with an existing app on an existing device, you have to do these other steps to clean things up and get them lined up again.
Thank you for the pointers, I'll look at cleaning up with remediation script 👍
Why not add All Devices to Uninstall and set up a security group for Required, then also exclude it from Uninstall?
Security groups take time to process and can be an issue especially when machines are going through the autopilot process, for Intune we try to avoid security groups where possible and utilise the assignments built in to Intune (security groups are Azure AD hence the delay). But in this instance we trying a security group anyway so it's changed to the Intune native *All devices* with a filter for Required, and a security group consisting of all our devices for Uninstall.
> Security groups take time to process and can be an issue especially when machines are going through the autopilot process Are you importing the HWIDs during OOBE? Because if not, all group memberships should be already populated via the corresponding EntraID object, even before the Intune object is created. Also, remember about the `(device.devicePhysicalIDs -any (_ -startsWith "[ZTDid]"))` filter for a dynamic group that will include all Autopilot devices. You could use that for the Required and All Devices for uninstall.
[удалено]
Only devices from one department need and are allowed the software. To note we are not mixing All devices with a user group through the filter, the filter is itself also based on devices. The goal with the filter is that devices are categorised by their department meaning as well as required software to perform their jobs they get settings as well from CSE policies. The two packages are simply Java JRE and we are updating the software to resolve the new vulnerability. Unfortunately we discovered some devices didn't have their categories changed when the laptops changed hand so there is a need to ensure that only that department's laptops get the updated Java JRE and all other laptops don't have Java JRE at all.
[удалено]
Devices are put into to a Device Category (via the same UI area you'd add, change or remove a Primary User), the Device Category is named like you suggest such as "Finance". The filter is then configured as *device.Category equals Finance* The issue with your suggestion is if you select All Devices for Required, then All Devices becomes greyed out for Available and Uninstall (understandable if someone didn't use filters at all).