+8I'm auditing a Jamf Pro server to see why there are so many problems. I have found over 20 Smart Groups that include other Smart Groups that are dependent on the first.
For example: SG1 was dependent on six other SGs. When I looked into those six, membership of SG1 was required for each one.
This seems like a bad idea to me. Is there anyone that is doing this? If so why? What are the benefits?
I don't know if I am missing something.
+15yep bad idea.
While perfectly possible, at the very least it will be causing you performance issues.
All smart groups are recalculated every time any computer submits inventory so if you have large amount of devices you'll be being constantly calculating results in the database.
Having a recursive loops will just compound this.
+20I agree on this being a bad idea.
Does anyone know if there is a tool to determine if a smart group is assigned to another smart group? There are tools to determine where groups and being used such as policies and profiles. Just curious if there is an easy way to determine the "nested" smart group piece. I figure I would go through some JSS cleanup this winter.
+15+1 on bad idea.
While it logically makes sense to have this layered mechanism, I got nipped in the bud hard once when I updated the membership of a smart group (this was early on with my time with Jamf) and somehow it miscalculated the new group to include ALL of our machines, rather than just desktops ...
As a result, all my desktop-specific profiles and policies got triggered on our laptops and a whole bunch of laptops had their wifi network device forcibly disabled as a result ...
... Needless to say, it was not a great time. No more nested smart groups for us.
The only situation where I have nested smart groups is for our DEP machines. I have individual smart groups for machines configured with a particular DEP PreStage Enrollment (PreStage Enrollment IS yadayada) and then another smart group which references this membership for config profiles. This to me seems like a low-risk situation since the only way a PreStage Enrollment membership will change is a machine gets moved to a new PreStage and then goes through the DEP enrollment process again.
+9We nested groups with iPads, but not recursive like OP described. For example:
iPad is a member of a static group (by room).
Grade1 smart group is all members of rooms 1-4
All_students smart group is all members of grade1, grade2, etc... so this is a smart group based on membership in other smart groups.
The "Why?" is because it's less work than adding a device to multiple static groups for profiles and apps.
Our on-prem seems to be able to handle it, but I suppose it could be faster. Managing 1000 iMacs and 3500 mobile devices
+8I like the answer to why so here is a follow up: What is the highest number of nested groups that you are successfully able to work with?
+9@tomhastings We have 68 Smart Groups for mobile devices currently, no idea what the limit might be. Not all of these use "Member of" as criteria.
In response to mconners,
I wrote a tool a while back to generate a scoping report for all groups with information on configuration profiles, policies, and other groups. Doesn't break things down by smart groups, but might help a bit.
https://github.com/chuckthegoat/JAMFReport
It also downloads all your configuration profiles and writes them as plists, but you can just comment out that line since you probably don't need it.
+7@chuckthegoat Took me a bit of updating Python components but I got your script to work. It'll be a big help. I noticed that there isn't information for when a group is used as an exclusion in scope. Do you plan on updating the script?
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
