Policy scope cannot be based on a smart computer group that uses the "latest version" criteria.

[pmcgurn]

Found this nice little limitation a little while ago. So basically, "patch reporting" can't be used to do anything actionable, like, say, patch something.

The use case was checking for machines not on the latest version of Chrome, and if found, running a script like this:

#!/bin/bash

#Command will trigger Google's native updater process in the background
cd /Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/Resources/
./CheckForUpdatesNow.command

exit 0

And then update inventory to have it drop out of the computer group.

[mpermann]

I noticed the same thing. It seems odd that you can't scope based on latest criteria. Maybe someone from JAMF will comment on why this is.

[erin_miska]

@pmcgurn (and @mpermann), check out my response to the same question on this KB: https://jamfnation.jamfsoftware.com/article.html?id=443

I think your use case (and @chad.jannusch's) is a little less dangerous than the one we were originally worried about, but you could still end up in a sticky situation if you used a smart group for "is not latest version". For example, if a new version of Chrome is released and one of your end users happens to install the new version on their own before JAMF has updated our definition of "latest version", the JSS will consider them to be on an "unknown" version. "is not latest version" will pull in computers with unknown versions, and your script will try to run on that computer that's already up-to-date but reporting as unknown. If your policy is set to ongoing, the script could run repeatedly until JAMF updates our definition of "latest version".

"less than latest version" would probably be OK...

We'll think about potentially removing this block and providing more of a disclaimer instead, but ultimately our focus is on building a more purpose-built solution so that you don't have to use complicated smart groups and policies to patch your machines. (We are also working on minimizing the amount of time it takes us to update our definition after a vendor releases an update.)

[RobertBasil]

For example, if a new version of Chrome is released and one of your end users happens to install the new version on their own before JAMF has updated our definition of "latest version", the JSS will consider them to be on an "unknown" version.

And that's the problem. Patch Reporting should report the installed version number of the software, even if it's not listed in the JAMF patch tables.

[blindcola]

Part of my workflow is to use an EA that my autopkg recipe updates every time it packages Chrome. We use separate test and production recipes. Often our production version is a couple days behind the current autoupdate version of software. That's fine with Lab environments, but there's really no reason why staff cant just run with the auto update from chrome. Also developers get crabby when you overwrite a beta install with last weeks production version. We use autopkg output equally for patching and continuous availability. One global policy scoped to this EA, for self service or a custom trigger call.
Have a look if you haven't come up with a workaround yet.
https://github.com/dlhughes/JAMFPro_Extension_Attributes/blob/master/GoogleChromeStatus
This is how we handle complex scoping in a way that "hopefully" will transition smoothly into what jamf is putting together.

[barnesaw]

Simple way around this: One smart group that uses the latest version criteria. Second smart group based on membership in the first group.

It's an unnecessarily difficult way to accomplish the stated goal, but c'est la jamf.

[jamf_tx]

Surprisingly, this is still an issue in 2018 with JAMF Pro 10.2.2. I want to run an auto-update script when patch management detects the version is out of date, and I can't simply create a smart group like Patch Reporting: Google Chrome less than latest

[remyb]

Yep, ran into the same problem last week.. 😞

[rstasel]

zombie thread. This is still a thing! Honestly, the fix is remove the blanket restriction and only have it apply to "is not latest version". That way, we can all do "less than latest version".

[devoted_lkrygsm]

This is infuriating that this is still a thing.

Way to make "Patch Management" absolutely useless for actually doing anything.

[k_spatula]

Read about this recently.. as a workaround: https://scriptingosx.com/2020/06/using-installomator-with-jamf-pro/
It is not a solution but a workaround to be able to use the smart group with latest version value to be used on policies.