Smart Groups not updating automatically after upgrade to v9

[yan1212]

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

[pearlin]

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?

[elliotjordan]

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

[pearlin]

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.

[CasperSally]

man that bug would kill us. good luck

[were_wulff]

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

[yan1212]

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.

[golbiga]

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

[pearlin]

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.

[golbiga]

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

[mm2270]

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.

[pearlin]

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.

[tomt]

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.

[mm2270]

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.

[were_wulff]

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

[mm2270]

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!

[were_wulff]

@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

[tomt]

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

[were_wulff]

@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

[mm2270]

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?

[pearlin]

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.

[golbiga]

@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

[were_wulff]

@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

[were_wulff]

@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

[rtrouton]

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.

[andrew]

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.

[golbiga]

This is still broken for us in 9.6. I just did an upgrade from 9.32 to 9.6 and I still have to manually run smart groups to get them to update.

[were_wulff]

@andrew & @golbiga

Are you finding that, after doing the edit/save, the smart groups start calculating automatically again, or are you finding that, to get them to recalculate at all, you have to go back in and edit/save every time?

Amanda Wulff
JAMF Software Support

[andrew]

@amanda.wulff][/url][/url,

I am currently in the process of analyzing this. Heres my test.

1. Create policy, scoped to all machine that lays down a dummy receipt.

   touch /Library/Application Support/JAMF/Receipts/AndrewTest1; jamf recon

2. Create Two SmartGroups. One that looks for the existence of the Dummy Receipt, and one that looks for machines that do not have the dummy receipt.

In theory, if the Smartgroups are working properly, the sum of both memberships should equal all of my managed clients. As far as I can tell, these numbers are jiving correctly, which leads me to believe that my SmartGroups are working after I went through the "edit/done/done" on each of my 181 Smartgroups.

Furthermore, there is a MYSQL query that can be ran to check what SmartGroups clients are a part of. Might be useful to some folk. Thanks to Ian from JAMF for hooking this up.

select computers.computer_name, computer_groups.computer_group_name, computer_group_memberships.computer_group_id from computers, computer_group_memberships, computer_groups where computers.computer_id=computer_group_memberships.computer_id and computer_groups.computer_group_id=computer_group_memberships.computer_group_id order by computers.computer_name;

Hope that information helps. I have an active ticket open for this issue.

[golbiga]

@amanda.wulff I still need to go back in and edit/save every time.

[andrew]

On further inspection, something is still not working correctly. Heres why I think this.

I created a second "AndrewTest" dummy receipt policy, scoped to all machines, and created 2 new sets of SmartGroups.

In theory, the sums of: "Andrew Test 1" & "Andrew Test 1 (Does not have)"
and "Andrew Test 2" & "Andrew Test 2 (Does not have)" should be the same. As you can see from this screenshot. They are not.

https://www.dropbox.com/s/xombvo0g3acp97h/Screenshot%202014-10-16%2013.43.05.png?dl=0

[andrew]

Further example of things sucking.

I have a Smart Group called "All Managed Machines" with 707 clients. I cloned the group, made no modifications, and the "All Managed Machines Clone" group has 711 clients.

More like dumb groups at this point.

Here is a screenshot to show that I am not crazy.

https://www.dropbox.com/s/tj5el2rp1a4y5o1/Screenshot%202014-10-16%2014.06.25.png?dl=0

[were_wulff]

@golbiga

Just to clarify, did your JSS start on 9.32, or was it, at one point an 8.x JSS that was then upgraded to 9?
I ask because we do have a reopened issue in which, after upgrading to 9.4+ from an 8.x database, Smart Groups fail show the correct counts.

Apologies for all the questions, we’re trying to piece out and narrow factors down to make it faster and hopefully easier to figure out what’s happening on the backend.

I see you’ve got a case open with your TAM as well and he stopped by to chat about this for a bit. He should be contacting you soon to ask about getting some before & after screenshots of the criteria in the groups as well as a debug log from the JSS.

If this is in your development environment, what might be most useful would be to roll it back to 9.32, put the JSS into full debug mode, and go through the upgrade, including checking smart groups (and manually updating one or two with the edit/save), with debug on.

That would give us every little MySQL query going back and forth between the database and the JSS, as well as all of the Tomcat commands/errors/info statements and will hopefully let us see what it’s doing vs. what we know it’s supposed to be doing.

@andrew

Thanks for that additional information! I see you also have an open case with your TAM, and I left notes for him linking to this thread there; I also attached your screenshot to the case.

In your case as well, we may also want to go through rolling back, putting it in full debug mode, and going through the update again, if this is in your development environment, then sending the logs in on the case you’ve got open.

Also, just so I can note it, did your environment start out on the 9 series, or was it an upgrade from 8 at some point?

I’m still doing some testing here in my environment, and I have touched base with the people in QA & development that I’d spoken with previously on this matter to see if there is anything specific they would like to see or have done testing-wise.

If either of you (or anyone else who is having this issue) need the instructions for putting everything into full debug mode, please get in contact with your Technical Account Manager and they can get those sent over.

Thanks!
Amanda Wulff
JAMF Software Support

[andrew]

Ahoi Amanda,

Thank you for your response.

I will send the logs my TAC right now. Yes. At one point this JSS Server was running version 8.

[golbiga]

@amanda.wulff I think we just figured out what was going wrong on our end. I'm going to do another test shortly. We went from 8.73 > 9.32, where everything worked. I updated to 9.6 from 9.32 and we were still seeing issues with the Smart Groups. However, I think we just discovered what was causing all of this.

We had an extension attribute that was grabbing the installed version of Adobe Flash. And for some reason the data type for that EA was set to integer and not string. So when we went through our smart groups again under 9.6, the Flash one would fail. When we changed the EA to a string, the smart group would work and the rest of the smart groups updated as well. So I'm guessing JSS versions earlier than 9.4-9.6 had a bug where it would not care if those version numbers were integers or strings. I want to do a few more tests, but I think we've resolved this issue on our end.

Thanks
Allen

[were_wulff]

@golbiga

Interesting...please let us know what your testing finds.

I see further up, there was some bad criteria causing it for someone else, and I'm wondering if it's less "smart group" related and possibly more, "Something might be wrong with an EA or the criteria of a single group." It would be nice to have an easier way to find which ones were causing the problem (though a debug log might show that) than to have to pick through them all until we find one that looks a bit off.

Thanks!
Amanda Wulff
JAMF Software Support

[andrew]

For what its worth, this issue is occurring on all of my SmartGroups. This issue is also occurring with criteria that is linked to a wide variety of non EA based information. An example of this would be a Smart Group that looks for Machines running an OS "like" 10.9.

[pearlin]

@amanda.wulff is referring to my post. The issue was affecting all of our smart groups until we found the one offender. We were able to find out which one was causing the issue by going through the JSS Server logs. It still wasn't easy.

[were_wulff]

@andrew

It still may be worth taking a look at; if I’m understanding @golbiga and @pearlin ’s posts correctly it sounds like one bad criteria (or criteria referencing a bad EA) in one group is exhibiting the behavior of ALL groups not updating properly until the offending criteria is either corrected or removed.

So, sort of a ‘one bad apple…’ situation.

If I somehow totally misunderstood what they were seeing with the criteria & EA issues, let me know and I’ll edit this post accordingly. :)

Thanks!
Amanda Wulff
JAMF Software Support

[andrew]

Right on. Thanks folks.

I have deleted the one EA that I created between the end of my Smart Groups and the start of my Dumb Groups. I will keep my eyes on things and see if the issue is resolved. Thanks to everyone who chimed in.