Prevent Auto Update policies from attempting to install over newer versions

[homebysix]

During the period between the release of a new update and when the -autoupdate recipe runs, the existing -autoupdate smart group criteria starts to include computers which have manually updated to the new version of the app. Subsequently, the existing Auto Update policy tries to "upgrade" the software to the last stable version of the app.

Ideally, I'd like the -autoupdate smart group to change from its current criteria:

Application Title is Foo.app and Application Version is not [last stable version]

To this:

Application Title is Foo.app and Application Version is less than [last stable version]

However, Casper represents Application Version as a string, which makes numeric comparison impossible. I'll have to think about the best workaround for this.

[homebysix]

One solution:

• Configure the Auto Update policies to run once per computer.
• When promoting a successfully-tested app to production, manually flush the associated Auto Update policy log.

This isn't ideal because it adds a step to the Auto Update policy promotion process (which is currently only one step, and I'd love to keep it that way).

Another solution:

• Create a SmartGroupTemplate-testing.xml template that serves to add the newest testing version to the existing Foo-autoupdate smart group, like so:

Application Title is Foo.app and Application Version is not [last stable version] and Application Version is not [current testing version]

I'm not certain that this is technically possible using JSSImporter templates, and even if it is, it won't be effective unless it continues adding subsequent versions to the smart group as they appear. I can imagine that if the IT department is 3 releases behind on testing, the smart group criteria would need to account for that:

Application Title is Foo.app and Application Version is not 1.0 (most recent approved and tested version) and Application Version is not 1.1 (newer but untested) and Application Version is not 1.2 (newer but untested) and Application Version is not 1.3 (current latest version in testing)

Tricky problem to solve...

[homebysix]

@opragel suggested another alternative: keeping an extension attribute for each auto-updated app, and the value of the EA would determine whether the Auto Update policy is scoped.

• Advantages: It solves the problem of the latest approved version overwriting newer manually-installed versions.
• Disadvantages: It requires a computer to check in before we know whether it's in the -autoupdate smart group scope. Processing would happen for every app, on every recon, for every client, which is not performant.

[opragel]

Here's an example of what I was thinking for the update check extension attribute mentioned in the comment above:

https://gist.github.com/opragel/9a76eace7650438a990b

Smart group setup could be something like:

Name: Microsoft Office 2016 - Current or New

• Extension Attribute: 'Microsoft Office 2016 Version Check' is 'T' OR 'N'

Name: Microsoft Office 2016 - Not Current

• Extension Attribute: 'Microsoft Office 2016 Version Check' is 'F'

Name: Microsoft Office 2016 - Not Installed

• Extension Attribute: 'Microsoft Office 2016 Version Check' is 'N/A'

Don't believe it's a preferable way to implement it, but does help mitigate this issue. It does have the disadvantage of requiring an extra check-in for scoping, but believe that's a separate issue.

Also, it's not the best for performance, but I wouldn't say it's not performant - does the job and requires very minimal CPU time.

[opragel]

Here's a python-ier version. Can't say it's great but it can work.. https://gist.github.com/opragel/db367b9616e48a8cebce#file-ea_microsoft_outlook2016_versioncheck-py

[pauldalewilliams]

I've found you can work around this for some apps using Jamf's patch reporting as filtering criteria. However, you have to make sure the version numbers match the definitions Jamf provides. I decided to go with running policies once per computer. Helps to prevent the possibility of loopers as well. I personally don't mind the extra step of flushing logs on the autoupdate policies.

[mpanighetti]

Newer versions of Jamf Pro support regex comparisons for version strings. Might make it easier to write a check that accounts for older versions (e.g. if latest version is 1.3, then look for regex matches ^1.[0-2]$). Though that would be difficult to generalize programmatically, considering how often version string formats change for some products...

[homebysix]

Closing due to repo deprecation and archival.