Static Groups vs Smart Groups Usage

Smart groups are significantly more costly in performance terms since they have to be evaluated at check-in.  Nested smart groups are the worst, according to both Jamf Professional Services and our migration consultants (Rocketman).  We only use smart groups for things that are truly dynamic, and try to stick to static groups for everything else as much as we can.

Interesting perspective as many will say smart groups should be used more especially for automation and static groups should be used only sparingly for tasks like pilot groups

They both have their place. I highly utilized smart groups for scoping. I mostly use static groups for exclusions. 

We are a very small instance, so we may not be doing things like everyone else. We assign all of our devices a name with the classroom and grade level. We create smart device groups to scope those and apply settings since those devices can change hands throughout the year based on enrollments (its weird, they have a home, but get loaned out to larger classes). When we have devices within groups that will behave slightly differently, such as receiving ELA support applications, we scope to those using static groups. We also have a teacher group that behaves differently than the rest, so we static group those.

I agree with ​@mattjerome they both have their place. We are a 1:1 iPad district using Jamf Pro. We use smart groups heavily and static groups sparingly. We key off of an extension attribute for Grade Level to scope apps and assign restrictions via config profiles for our student iPads. We have elementary, middle, and high school restrictions. In the summer when we activate the new school year, and student’s grade levels change, this automatically gets updated in Jamf when the iPad checks in. Then if a student moved from elementary to middle school, the elementary apps and restrictions are automatically removed and the middle school ones are applied/installed. 

We also have smart groups for each building, staff, Apple TVs, and iPod Touches (when we had them). Since static groups require more maintenance we only use them when needed. For example I have an Elementary SLP (speech language pathologist) static group along with one for our Secondary SLPs and one for the Spanish SLPs. Each group is assigned different apps and an SLP may be in more than one of these groups based on their assigned schools. I typically only need to update these groups once a year, but if I found a way to manage this via a smart group, I’d switch it over to one. The less maintenance the better.

From an automation and CI/CD standpoint - static groups should be used very sparingly and all workflows should tried to be tied to smart groups.  There is a tax on the server for calculations to the smart groups, but it’s well worth it.  A real performance tax on your instance would be a plethora of EAs.

Anyways, static groups are super rigid.  If you have a lot of turnover (wipe/reloads), those devices will remain in those groups indefinitely.  

Anyways, to each their own.  I’m an automation guy, so I lean heavily on smart groups.

​@Chubs brings up the point of computers remaining in static groups. He’s exactly correct. However, I’m a firm believer that a computer should be removed from Jamf when it’s erased. This does a few things

1. removes the issue he’s referring to about computers remaining in groups
2. Removes policy history so things can run when they’re supposed to
3. keeps your compliance/reporting numbers clean so it doesn’t include computers sitting on a shelf
4. a few other things...

Which works great (but is also more manual work), but for companies that have to keep audit trails of devices (ownership, install status, usage, etc.), then that workflow will not work.  Working in healthcare, we care about device history + data.  This is a necessity.