Hi, new casper user here. I have a smart group for machines that have Evernote installed but the version is not 5.1.4 (latest version). In the JSS I have a policy set to show the Self Service item for the 5.1.4 version of Evernote assigned to the Smart Group of clients needing the update. So on my test client with 5.1.3 installed, I opened self-service and the update shows, so I run it (inventory collection is part of this policy). After I run it, the policy for the 5.1.4 update is still available in Self Service, and my test client is still a member of the Smart Group for clients needing the update. However when I look in inventory at this test client, it shows Evernote as being on version 5.1.4. Any idea why the Smart Group still thinks it should have this client when in the inventory section the client is clearly showing that it has the 5.1.4 version?
Application Version Smart Group
+6
+27Could you post the "Criteria" that you're using to build the smart list. There is always a reason. Generally it has to do with the logic used by the smart group you've built. I tend to build my smart groups very very carefully based on "licensed software" templates I create.
+10Agreed. Seeing the specifics of your setup will help. And like Chris said, creating licensed software items can help with what you are trying to do.
Create a licensed software Evernote 5.1.4. You will define it by application name and version number.
Then I make a smart group like Evernote 5.1.4 Installable (SS). The criteria for the smart group is 'does not have licensed software Evernote 5.1.4'. Then the policy only applies to members of the smart group. Once the system gets Evernote 5.1.4 it falls out of the smart group, and the SS install option disappears. That's how I am doing it.
Oh and employ the update inventory in your policy so that the JSS knows the new version has been installed.
+10Oh and employ the update inventory in your policy so that the JSS knows the new version has been installed.
Can't stress that enough when using Smart Groups where you run a policy and the computer gets removed from the Smart Group. You have to make sure to Update Inventory in your policy for this process to work.
+27YES!
... one other thing that i do personally, is to create a software license record for ALL previously installed versions. That way I can create a smart group to only install form those previously known versions. This prevents users that have newer versions from being placed into the smart group until you catch up with them.
+24The OP stated right in his post that inventory collection was part of the policy. I had the same thought as you guys initially until i read that part.
I suspect its an issue with the Smart Group logic. Smart Groups are a great feature, but they can at times be tricky to set up right. Sometimes just reordering your criteria can give you different results!
+13Agreed; also, if you're looking for multiple versions of a product, I've seen far more reliable results by specifying the app name before each version. That is,
"Logical" way that doesn't work reliably:
App Name like Awesome.app
and App Version like 1.0
or App Version like 2.0
"Sort of Silly" way that works reliably:
App Name like Awesome.app
and App Version like 1.0
or App Name like Awesome.app
and App Version like 2.0
+27It's the whole "like" thing that works awkwardly with certain version strings. Not being integers and all.
Since I'm setting available updates and/or other installes I just can't stomach NOT having a very clearly defined set of parameters. However, if this works well for others than high five to you. Admittedly I enter about 20+ specific versions for each smart group to very clearly define how I want these things distributed. It's not that much extra time and the wrong users are NEVER offered the wrong upgrade. Inversely the software is ALWAYS offered to users that need it.
+10I have a post on here already about this but this bring it up again...I'd love to have the ability to utilize operators in the criteria. >=, <=, <, >, stuff like that.
+27That's just the thing. version numbers aren't actually numbers. I wish it would work that way but the logic is pretty problematic.
+10I know what you mean. Hard to compare 6.1.200.0021 to 6.1.220.2100.41 type thing. It's not like comparing to integers.
+24Yep, that's the issue. Its an issue of developers that refuse to use any kind of standard with application version numbering and possibly MySQL. (though I'm not sure if other SQL's wouldn't have the same issue with it)
Take a look at Adobe's FlashPlayer for example (11.7.700.225) That's not really a number that conforms to greater than/less than logic. It just doesn't work. There are other worse examples; application versions that have letters in them even. Try applying a > = < less than logic to that!
I also wish it could work that way as it would make tracking versions way way easier.
+1Hey folks, just to clarify the difference between "and" & "or". AND only links two lines of conditions (and no more), i.e. x and y or z is interpreted as (x+y) OR z not x+(y OR z)
In a longer list, a AND b or c or d or e means:
(A+B) or c or d or e
More complicated:
a AND b or c AND d or e or f or g AND h means:
(a+b) or (c+d) or e or f or (g+h)
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.