Application Version Smart Group

mkunesh
New Contributor III

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?

13 REPLIES 13

Chris_Hafner
Valued Contributor II

Could 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.

aamjohns
Contributor II

Agreed. 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.

hkim
Contributor II
Oh 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.

Chris_Hafner
Valued Contributor II

YES!

... 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.

mm2270
Legendary Contributor III

The 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!

aamjohns
Contributor II

Agreed. That's why I find using licensed software so handy in smart group criteria.

JPDyson
Valued Contributor

Agreed; 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

Chris_Hafner
Valued Contributor II

It'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.

aamjohns
Contributor II

I 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.

Chris_Hafner
Valued Contributor II

That's just the thing. version numbers aren't actually numbers. I wish it would work that way but the logic is pretty problematic.

aamjohns
Contributor II

I 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.

mm2270
Legendary Contributor III

Yep, 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.

nevens
New Contributor

Hey 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)