It’s becoming quite difficult to replicate the assignments in Intune when migrating deployments to ImmyBot, purely as we are lacking exclusion functionality for Azure Group / Office 365 Groups.
As we’ve already had conversations with our customers about the [security group] assignment logic for the intune applications, i’m having to leave some older version applications in Intune and then target an Update if Found deployment at tenant level in ImmyBot to sort.
A tickbox to the right of “Azure Group” saying “Add exclusions”, then it pops out with another search box to add the exclusion would be great.
Also being able to target multiple Azure Groups in one deployment would be good too as currently we have to create multiple deployments of the same application at tenant level to deploy to multiple Azure Groups.
Cheers!
So can you provide an example of what you’re trying to accomplish? I understand that it would be easier in certain cases to be able to leverage exclusions, but so far in 3.5 years I have yet to have an issue creating deployments that weren’t able to precisely target the proper machines without the use of exclusions.
Heya, yep so our customer wants Adobe Acrobat to go out to the majority of users (via AAD security group) except the ones that are members of another group which deploys Adobe Creative Cloud. Exclusions would sort this one pretty quickly, and I’m trying to stay away from tagging machines with specific software tags and just using security groups. Cheers!
I realize this is an old topic, but I am fairly new to Immy and in the process of deploying across our entire client base. My long-term goal (for a few reasons) is to replace Intune deployments with Immy deployments.
A good example of a use case for Exclusions in my case is this: We have a client (approximately 75 users) that has a piece of software (MicroDicom) that gets installed for all users except the accounting dept (3 users). I would prefer to target “Everyone except accounting” instead of creating a group that manually needs everyone but the accounting users added. I would rather that when onboarding a new user, the onboarding technician doesn’t need to “do anything” to get the software installed as that applies to roughly 95% of users.
Creating an exclusion group like “APP - No MicroDicom Install” also allows for some scaleability/flexibility so that if the client decides to create a new department or position that doesn’t need that software, we can just add them to the exclusion group instead of needing to make the process mor complex.
I know that I could create a dymanic group to apply to the task/deployment, but that requires significantly more knowledge and experience in most cases (unless the dynamic rules are very basic). Any of my techs can add a user to a group. Not all will be able to create or modify a dynamic membership list successfully (nor do I want them “fiddling” with them and potentially causing unexpected issues.
My case for being able to apply a task to multiple groups is similar: If I have dynamic groups created based on department, location, job title, etc, it would be nice to be able to apply tasks to multiple groups as opposed to the need to create a new “combined” group. This would allow me to keep our dynamic membership rules much simpler and allow for much quicker and more accurate changes to our deployment tasks.