Are smart groups sine qua non?

[milesleacy]

Just an odd product architecture thought I figured I'd throw to the community...

Why are computer/device/user groups necessary?
Edit: to be clear, I'm not suggesting that they're not. I'm just seeking to understand whether they are, and if so, why?

What if we built our scope criteria within each management object?

Would this be simpler or more complex?

I'm curious to know your thoughts.

[milesleacy]

An example...

A common smart computer group that I'd wager most of us have some variation of is "macOS 10.12 or Later" with critera of 'OS Version greater than or equal to 10.12.0'.

Would it be fewer clicks to specify that criteria in multiple policies and profiles than to select the smart group?

Would it take less web application and database processing/overhead to work this way?

[sswartz]

As to Q1--- It might not take more clicks to add the criteria in the policy/profile when initially setting up the policy/profile, however when it is time to change the criteria (e.g. 10.13.0) then change it once in the smart group vs change individually in each policy/profile. (plus being certain of finding all of the policies affected--FR1874)

[milesleacy]

@sswartz Do you find that you often change a policy's scope like this? I can't think of a use case off hand but I'm curious about your experience.

What I'm thinking is...
For example, Microsoft Office for Mac 2016 requires macOS v10.10 or later. I don't foresee changing that scope.

When Microsoft releases a (theoretical and invented for illustrative purposes) Office for Mac 2018, it may require macOS v10.13 or later. This would affect the Office 2018 policy but would have no effect on the Office 2016 policy.

[psliequ]

I feel like this would be less efficient from the database's perspective.
What would have to happen (I think) is that Tomcat would have to calculate the scope of every policy on every Mac check-in in order to decide what to run (I am assuming here that smart groups act as a kind of stored procedure in mySQL that allow both us and Tomcat to view a scope whenever it's asked for with some caching happening for good measure.) So with the way things are now, groups are only calculated when they are applied to active management objects or viewed in the UI. With your proposal, a Mac checking in would cause Tomcat to have to re-run every scope calculation for every active policy. Then again, maybe it does this now :) Whether you create many groups and few policies or vice versa would also drastically change the load.

Another idea would be to have the Mac itself host the inventory database for itself and allow it to perform the calculations for what policies should apply to it (kind of the OSQuery model.)

[Look]

Personally I would prefer changing things in as few places as possible as infrequently as possible.
I can't see how having the scope defined as queries for every object would achieve this.

The other aspect is that I use smart groups frequently to answer reporting type questions from management, these are generally just the same smart groups I use for scoping to policies so they often serve more than one purpose. I also use these same smart groups to generate lists of machines that require work from Service Delivery.

[milesleacy]

Great logic, @psliequ !

Unless I'm mistaken, smart groups are evaluated when a computer submits inventory (or at 1AM, for date criteria), which should be significantly less often that check ins.

Each managed computer containing a plist of its own inventory, hmm. That's an idea, but the managed client would still need to evaluate every policy from the JSS against this.

The crux of my thought experiment was seeing if an entire object type (groups) and the calculations around them could be eliminated.

It seems like the alternative would shift, rather than eliminate the load.

[thoule]

I've been advocating this design for years. I'd love to see a policy have its scope definable in the policy- either to a static group, or a spot for EA type code. Writing an EA, creating a smart group, then a policy to target that group makes a mess. Then I have EA's and Groups that I don't know if they're used or not so I can't edit them!

IBM's BigFix does things this way. You have a policy with it's 'relevance' in the policy. If a computer changes and it's somehow relevant now, the action takes place.

[Look]

@thoule But doesn't mean if you want to use the same relevancy in say 5 different places you have to keep recreating it 5 times?

[thoule]

@Look Yes. The win there is that if the relevancy changes for any one of those 5, you don't have a mess on 4 of them...

[milesleacy]

@thoule

I have EA's and Groups that I don't know if they're used or not so I can't edit them!

if the relevancy changes for any one of those 5, you don't have a mess on 4 of them

Those two points are precisely what got me thinking down this path.

[sswartz]

One of the primary reasons I use groups is to manage software installs to teachers vs associates vs all students vs specific classes. I use them often. If I needed to recreate the criteria for each of dozen's of policies, there would be many more clicks, especially with static groups.

[gachowski]

I kinda like the current set up with smart groups.. however as thoule said

I have EA's and Groups that I don't know if they're used or not so I can't edit them!

I would guess that we will see this resolved with the FR being one of the most popular.

C