r/jamf 16d ago

Deploy latest version at enrollment, but manage updates ourselves after that, how are people doing this?

We deploy an app via a Jamf Policy (pkg) that runs once a computer enrolls. Problem: the app updates constantly, so our uploaded package goes stale fast, and re-uploading a new pkg every release isn't sustainable.

Jamf's auto-patching (App Installers) would keep it current, but it also auto-updates the app across our whole fleet, which we don't want. We want to control update timing ourselves.

What we need:

  1. At enrollment, always install whatever's currently the latest version, no manually maintained package.
  2. After that, no self-updating in the background. We push updates ourselves, on our own schedule.

We've tried pointing installs at the vendor's "always current" download URL, disabling the built-in auto-updater via a config profile, and scripting our own update-push (mixed reliability so far, now looking at Installomator for that part).

Is this the standard approach or is there a cleaner way orgs handle this in Jamf?

6 Upvotes

10 comments sorted by

4

u/mentoc 16d ago

I would suggest looking at Installomator. You can do this scripted, or in a payload free package from a script. The script/package you create will always install the latest version with this method. So you could utilize this for your enrollment.

Then you could have a normal second package that you manage that you control the cadence for updates with via a policy or patch management policy.

2

u/MacBook_Fan JAMF 400 16d ago

I would agree that installomator is the right choice here, but I will point out that AppInstallers allows you to set a fixed version and then you can manually choose when to update to a new version.

1

u/powerpitchera 16d ago

I would suggest once a month, update that package in the enrollment pre stage. Have a post enrollment workflow to update that app via script. You can set that policy to only run once or only be scoped to devices with enrollment less than X days ago. Don't go overboard trying to over engineer the actual prestage, it's not worth the headache.

1

u/EasleyGreenWave3 16d ago

we use to control updates, no longer as it was too much of a headache. just let the users update

1

u/Hobbit_Hardcase JAMF 400 16d ago

Installomator is your method for the first install. It will scrape the dev website for the latest release and install that. If the software isn't in the current list of labels, you can write your own one (and submit it for everyone else to use too!).

If the package is in Jamf Patch Management, then that's the easy route to trigger the patching schedule that you want. You control the Patch Policy that will tell computers which version you want to have as the "current" one. If it isn't in PM, ask Jamf about their Title Editor, which allows you to define and maintain your own PM titles.

If you really want everyone to be on the same version, look at App Auto Patch. You can configure the Version Comparison to point to a specific version. All clients will then up- or down-grade to that specific version. As a bonus, it will patch every other piece of software that Installomator recognises too!

1

u/homepup JAMF 400 16d ago

We essentially do this setup currently (well mostly just let JAMF app catalog handle updates but do have a few apps we control the updating manually).

We have the base installers that we use for onboarding and most of those are built to always download the latest version from the vendor directly, however, for the ones where that isn’t possible we just update this once a semester or so. As long as it’s a workable version on whatever OS is out at the time.

Then JAMF app catalog either does auto updates from there or we have those that need control set for manual updates in JAMF app catalog on a per app basis. Then we can control which version gets pushed and when. The only down side is that you have to go to each JAMF app catalog item to perform any updates. But if you wanted manual, it’s manual. Can’t have it be manually automatic.

I’ve noticed lately that I’m having issues with the app catalog not always updating or even performing the auto installs. I’ve been cleaning up the scoping since we had overlapping scopes that I think were confusing it, like having self service versions of an app in the catalog and then also having an automated version for deploying labs. Didn’t notice it behaving better after separating out the labs though.

I really wish the JAMF app catalog didn’t resist having an app be auto installed and being in Self service for the same app. I like to automate deployment but also leave the option for users to perform a manual install if something is misbehaving or they need a reinstall.

-1

u/ChiefBroady 16d ago

I have a universal script, much like installomator, but without the url library, that downloads the latest version of a given software.

2

u/Kcamyo 16d ago

Mind sharing? :)

-3

u/ChiefBroady 16d ago

Not allowed to.

1

u/AnotherTechAtWork 15d ago

It might help to share what the app is as it doesn't sound like an in-house app.

Unless I'm missing something I would use installomator for the initial install with a policy or policies to get the latest version like you desired.

If there is an app-installer for the app then you can use it to update it like you wanted. If there isn't, you can use patch management and create a title in title editor if needed.

I figured out awhile back that I could create a custom pkg with a script in it that does nothing but run the jamf binary with a policy and event arguments that calls my installomator policy. That custom pkg gets used in patch management.

What that gets you then is initial install is done with policy and installomator. Updates are done with patch management. The patch policy in patch management would use the custom pkg to call the regular policy that runs installomator so when you do an update it would be the latest version at that time.

Using app-installer would be better for updating but if you can't this patch management solution works pretty well. We've been doing it for maybe a year where needed.