Skip to main content

Hi all,

I was wondering if anyone can shed some light on this?

After upgrading our JSS to v9.21 from v8.73 I am seeing smart groups not updating automatically. I seem to have to either open the group up for editing and save again (even if no changes are made) or have the client(s) submit inventory for the Smart Group to pick up the changes and adjust membership accordingly.

This is particularly a problem where I have Smart Groups created based on extension attributes using pop-up menu options. The pop-up menu extension attributes that were migrated from v8.73 were effectively rendered useless and I had to re-write all of them. They now work but with the problem I am mentioning above.

I saw that other people have been having problems with Smart Group updating in other threads but there is no definitive solution that I could find. I am hoping that maybe someone has come across this sort of thing before and managed to solve it??

Thanks

I've been experiencing this same problem, however, it applies to every single one of our Smart Groups, regardless of criteria. The only way to get them to update is to edit/save. I started noticing the problem after upgrading to 9.51. I have an open case with JAMF, but we haven't made much traction.

Was there ever a resolution to this?


I have just noticed this on a JSS I administer. I'm submitting a case now.


I've been in touch with JAMF about this issue and they told me yesterday that it has been filed as a high priority defect with Q&A.


man that bug would kill us. good luck


Hey all,

Just for reference, this has been filed as a defect (as @pearlin mentioned). The defect ID is D-007794.

This will be the one to watch for in release notes if you're waiting to upgrade until it's fixed or are currently experiencing the issue.

The current workaround is what was listed further up in this thread: Open up the Smart Group, click Save, and it updates.

If you're experiencing behavior that sounds like it might be this defect and would like to look into it further to either confirm D-007794 and get a case attached to the defect for tracking, or to rule it out and uncover what else might be causing the behavior, please get in touch with your Technical Account Manager by either giving them a call, sending an e-mail to support@jamfsoftware.com, or using the My Support section of JAMF Nation.

Thanks!
Amanda Wulff
JAMF Software Support


For what it's worth, this was fixed for us in 9.3. I haven't seen this problem returning since and I have been though every upgrade since then. Strange that it is affecting people now.


I'm in the process of upgrading from 8.73 to 9.52 and I think I've stumbled across this bug. For the current workaround, is the Open up the Smart Group, click Save, and it updates just post upgrade? Or is this something that you need to constantly do to keep them up to date?

Thanks
Allen


The smart groups don't update themselves, so you need to constantly edit/save any smart group that you want to reflect an accurate account. It's super annoying and has been a problem for me for about a month. I haven't received a worthwhile update from JAMF either. Needless to say, it's not fun and I've come to expect more from JAMF.


Well I guess I wont be upgrading to 9 until this is resolved.


I may be mistaken, but I believe this is not the first time this particular bug has reared its ugly head. I seem to recall it showing up some time back and was finally resolved in an update.
Its disappointing to hear its come back. Given that Smart Groups are one of the most crucial and integral aspects of Casper Suite, not having them working properly is nearly a showstopper.
I hope JAMF gets this squared away pretty quick. We're planning our upgrade to v9 soon, and will need to watch this issue closely.


I would definitely consider it a show stopper, as in the show has stopped and won't really resume until it's fixed. Virtually all of our policies are scoped to smart groups and rely on the fluid movement of clients in and out of groups, which simply isn't happening. The latest workaround suggestion I received from JAMF was to "either change our workflow for policy deployment, or temporarily disable policies" scoped to smart groups. Not cool, JAMF. Not cool.


I can't see that as being any sort of a valid workaround. I don't understand what's going on at JAMF these days. If I was in your situation I would be escalating this to the highest levels I could. The current people running JAMF day to day seem to have lost their passion for putting out a rock solid product.


Yeah, that's puzzling. Its hard to imagine how anyone there would actually say to stop using policies scoped to Smart Groups as a temp workaround. :-/ They might as well tell you to use another management product! JAMF touts Smart Groups as "the way" to do things, so if its broken, hopefully they are pulling out some stops to get this resolved as soon as possible. The timing certainly sucks so close to JNUC, but its not like they haven't been in that place before.


Hey all,

Just an update on the defect: We've done some additional testing on this issue since it was opened last week to narrow down the scope of D-007794, and they've found that it appears to be pretty specific to criteria related to the JAMF binary version when the binary updated without an inventory report being sent in to the JSS.

Smart groups in general, barring the above specific criteria for the JAMF binary version, should be working as expected.

If you're seeing issues in your environment where smart groups (either a single group or multiple groups) are not automatically updating their numbers, that's something we'll want to get a case going to look closer into the criteria of the groups and/or how they're set up to look into it a little deeper as there may be something else going on.

If you are seeing this behavior in your smart groups, and those groups aren't using the JAMF binary version as one of the criteria, please get in touch with your Technical Account Manager either by phone, by sending an e-mail to support@jamfsoftware.com, or by using My Support on JAMF Nation.

Thanks!
Amanda Wulff
JAMF Software Support


So, @amanda.wulff, can you clarify? Only SGs that use the jamf binary version as part of their criteria seem to be affected by this? Or do you mean it only occurs if the jamf binary was updated and the Mac didn't submit new inventory properly? And from there on it won't properly move into and out of SGs?
Just looking to get more clear on this. Sounds like its something that could be avoided if one is careful, which is good if so.
Thanks for the quick update by the way!


@mm2270][/url

I want to have a chat with the QA engineer that has been working on this defect before giving an answer to those questions; I’m 98% certain I know said answers, but want to make absolutely sure on it before I post them here since, after additional testing, the scope and general overall impact of D-007794 seems to have changed significantly in the past few days.

It looks like he’s out for the day already, so I’ve got a note left for myself to get in touch with him tomorrow to run these questions by him and make sure my understanding of the updates to the defect are accurate first.

Thanks!
Amanda Wulff
JAMF Software Support


And this is why Amanda should never have to buy her own drinks whenever there is a Macadmin around!


@mm2270

What we’ve found in our testing so far is that, if the management framework updated without an inventory submission, smart groups containing JAMF Binary Version as one of their criteria would not update to reflect that change and devices whose JAMF Binary Version has changed may not fall out of or enter into the appropriate smart groups without doing the “edit/save” method.

If inventory does get submitted immediately after the framework update, the Smart Group was manually updated by using the edit/save method, or the next time the device(s) check in normally and does its routine inventory update, the group will update its memberships accordingly.

Currently, we’re testing setting up other Smart Group scenarios in which the device(s) interact with the JSS in some fashion to update its inventory criteria (a new binary version, new app version, name change, department change, etc…anything that would reflect a change in the device’s inventory record) that would result in a device falling into or out of a Smart Group.

We’ve been testing the usual workflows for Smart Group creation and, so far, unless we are specifically running into the situation described above with the JAMF Binary Version being part of the criteria, they all appear to be working and updating as expected.

We are aware that Smart Groups functioning as expected is an extremely important function of the JSS as it's a commonly used method of scoping a lot of things, and this particular issue is a very high priority for us to get properly tested and taken care of.

We are also continuing testing on this as it is an issue that was fairly recently discovered, so please be aware that things may change as we get through additional testing.

If I learn of any changes, I'll be sure to update here, otherwise, please check the Release Notes that come out with our updates and see if D-007794 shows up in the list of issues that were fixed in that release's version.

If you still have additional questions about D-007794 (or just in general), please get in touch with your Technical Account Manager to discuss those.

If you are seeing Smart Groups that are not automatically updating as they should, and you are NOT using the JAMF Binary Version as the criteria for the Smart Group, please get in touch with your Technical Account Manager so that we can dig into it further, find out if it’s a simple workflow issue or if it may be something else, and pass along any findings to our Development and QA teams to assist with their testing if necessary.

Thanks!
Amanda Wulff
JAMF Software Support


Thanks @amanda.wulff][/url! That sounds like a very very specific scenario to create the issue, and if that's all you folks are finding, then this may not be as serious as first reported.
That said, it would be interesting to hear from some of the people on this thread if this matches what they're seeing. Hopefully that's all there is to it.

Thanks again for the quick replies and follow up on this!

EDIT: Just to note, I see that @pearlin mentions above-

...however, it applies to every single one of our Smart Groups, regardless of criteria.

Sounds like he's having a different experience, but maybe there's something else at play there?


I would like to think that all of my experiences are different, but I digress...

We just found out that there was a bad, or rather unrecognized, criteria in one of our smart groups that was causing all of the smart groups to not refresh. It was apparently a value that has been deprecated: "Boot Drive Percentage Full" was looking for "yes" when it now can only look for number values. Not sure if this change happened in Casper 9, but this was a smart group that was created during our initial onsite JSS setup and hasn't been modified since, until today.

So, in conclusion, we had a bit of a "needle in a haystack" situation which now looks to be (mercifully) resolved.


@amanda.wulff I just tested another migration this AM, this time going from 8.73 > 9.32 > 9.52. When we went from 8.73 to 9.32 I didn't notice any issues. But when we went from 9.32 > 9.52 Smart Groups started acting up. We do not include the binary version in any of those smart groups.

An example of what we're seeing, we have a smart group that shows any machines that have more than 0 software updates. I had a previously enrolled machine that had software updates pending. I ran the software updates via the App Store, did a recon and checked the JSS. The inventory record would show that the machine had 0 updates pending, however it was still sitting in the Smart Group "Software Updates Pending" and Run Software Updates was still showing up in Self Service. I had to go to click on Edit -> Save under that specific Smart Group for that machine to removed from the group and for the policy to disappear from Self Service.

Thanks
Allen


@mm2270

Some of the confusion may have come in due to this kind of being a resurrection of an old thread that was a slightly different issue than what’s been described in the more recent comments.

The original post mentioned an issue that we had identified as a defect almost a year ago, and was specific to upgrades from the 8 series to the 9 series at the time; what the original post describes is that old, closed defect and it was something that we only saw after upgrades between 8 and 9.

The issue described in the first post of this thread isn’t something that should be affecting anything from 9.22 on up.

And, of course, there was the fact that, initially, we did think that D-007794 was a more widespread than it has turned out to be; that’s a mistake I think we’re all happy to have made. :)

We do have a currently open issue around Smart Groups and upgrades from 8 to 9.x, but it also has pretty specific behavior and it’s not an ‘across the board’ deal either, from what we’ve seen; it appears to affect random Smart Groups during the upgrade process. It also isn’t a problem that revolves around the groups not updating; the issue with the currently open defect is that the group counts may be inaccurate (ex: Group A had 400 members prior to upgrade. Immediately after the upgrade, Group A had 397 members.), not that they don’t update automatically.

What we see in that case is that some Smart Groups, after the upgrade, do not reflect an accurate device count. This ONLY happens with OS X Smart Groups, not Mobile Device groups, and it does not happen in every upgrade or with every Smart Group.

This is also an issue that our Development team is very, very aware of and it’s one of their high priorities to get taken care of as, even if it’s not an across the board issue, it’s still a problematic one as chances are those Smart Groups all dictate scoping for something and if they’re inaccurate in their counts, we’ll obviously see some pretty undesirable behavior.

Given that that issue is also pretty specific and only seems to occur under a narrow set of circumstances, I wouldn’t be comfortable saying that that’s what’s being experienced by some of the posters in this thread, and would suggest they get in touch with (or get back in touch with) their Technical Account Manager to discuss what’s going on a bit further.

If the situation being seen falls more in line with Smart Groups having inaccurate counts after upgrading from 8 to 9, please get in touch with your Technical Account Manager to get a case going if that hasn’t been done already, and have a closer look taken at what’s going on so we can verify that we’re seeing that behavior or not.

If you’ve got screenshots of the criteria of the Smart Groups that aren’t updating as they should, that would be helpful to include when creating a new case or updating an existing one with your Technical Account Manager.

Many times, it boils down to either a workflow issue or a group that somehow got a little scrambled on the backend and, while it might appear okay in the webapp, it's not passing good data on the backend and that's something your Technical Account Manager can help uncover, usually through getting some debug logs generated.

@pearlin

That is excellent news to hear! Sometimes it really does get a bit intense trying to figure out which one thing is causing the whole works to go haywire.
If it helps, earlier today, after two days and about 12 total hours on webexes and in debug logs, we figured out that it was a bad ICON (yes, as in pretty picture that sits next to the text in Self Service) that was causing the MDM queue to eat up all of the server's memory and crash the entire machine.

Still have no idea what got so messed up with that icon, but whatever it was, it was enough to bring the entire VM to its knees. Icon removed and re-uploaded, problem solved!

I guess that's the sort of stuff that makes IT admin and support work---interesting.

Amanda Wulff
JAMF Software Support


@golbiga

I see you had a case already created for this; I went ahead and let your TAM know these additional details.

I shifted the case you had opened over to the correct defect ID for tracking as, based on your updated post here it sounds as though you’re running into the behavior we see with D-007079: Smart Groups not reflecting accurate counts after an upgrade from 8 to 9.4/9.5x.

Unfortunately, I don’t have a time table on a fix release for you on that one, so the best I can really offer is to say jot that ID down and be sure to check the release notes next time we have an update and see if it lists that one as having been taken care of.

Thanks!
Amanda Wulff
JAMF Software Support


Upgrading from Casper 9.32 to 9.52 went smoothly for me this morning. I've seeing machines check in and smart groups updating.

To test the jamf binary smart group update issue, I have "Not Running Current Casper Agent" and "Running Current Casper Agent" smart groups, which have the criteria of JAMF Binary Agent and checking for current or not current. I am seeing an issue there in 9.52, where I'm having to edit the smart groups to get the smart group membership to update.

To verify the issue was confined to the jamf binary, I manually triggered a policy on one of my 9.52-managed machines that affected two other smart groups and had a recon at the end. The smart groups’ criteria in this case was that both were checking for what was returned by one of my extension attributes.

Once the policy finished and recon ran, both smart groups updated like they were supposed to.


We are also experiencing this issue. We noticed it started happening after the 9.52 upgrade. Like other users, the smart groups do not update automatically, but will update if we open, edit, and save the Smart Group. Pretty much a show stopper for a lot of our processes around here. Hoping this gets resolved soon.