How We Use Installomator to Automatically Manage Application Updates

Photo by Markus Spiske on Unsplash

Welcome to my first post on Substack. You may recognise some previous posts from my old self-hosted blog. In an effort to separate out my work posts, I’ve moved over here.

If you’ve read some of my previous posts, you’ll know that I make use of Installomator to install the latest version of software during the zero touch setup of our lab devices. But, that’s not all it’s good for. It’s also used for keeping our applications up-to-date when a new version is released.

In this post, I’ll take you through our workflow for automatically updating an application when the developer releases an update.

There are a few parts to this, so grab a tea and enjoy.

Installomator

The most important part of the whole workflow is Installomator. Without it, this wouldn’t be possible. Head on over to https://github.com/Installomator/Installomator for more information, and to download it.

There are multiple options available when it comes to user notification, and blocking process behaviours.

# notify behavior

NOTIFY=success

# options:

# - success notify the user on success

# - silent no notifications

# - all all notifications (great for Self Service installation)

# behavior when blocking processes are found

BLOCKING_PROCESS_ACTION=tell_user

# options:

# - ignore continue even when blocking processes are found

# - quit app will be told to quit nicely if running

# - quit_kill told to quit twice, then it will be killed

# Could be great for service apps if they do not respawn

# - silent_fail exit script without prompt or installation

# - prompt_user show a user dialog for each blocking process found,

# user can choose "Quit and Update" or "Not Now".

# When "Quit and Update" is chosen, blocking process

# will be told to quit. Installomator will wait 30 seconds

# before checking again in case Save dialogs etc are being responded to.

# Installomator will abort if quitting after three tries does not succeed.

# "Not Now" will exit Installomator.

# - prompt_user_then_kill

# show a user dialog for each blocking process found,

# user can choose "Quit and Update" or "Not Now".

# When "Quit and Update" is chosen, blocking process

# will be terminated. Installomator will abort if terminating

# after two tries does not succeed. "Not Now" will exit Installomator.

# - prompt_user_loop

# Like prompt-user, but clicking "Not Now", will just wait an hour,

# and then it will ask again.

# WARNING! It might block the MDM agent on the machine, as

# the script will not exit, it will pause until the hour has passed,

# possibly blocking for other management actions in this time.

# - tell_user User will be showed a notification about the important update,

# but user is only allowed to Quit and Continue, and then we

# ask the app to quit. This is default.

# - tell_user_then_kill

# User will be showed a notification about the important update,

# but user is only allowed to Quit and Continue. If the quitting fails,

# the blocking processes will be terminated.

# - kill kill process without prompting or giving the user a chance to save

Because of this, I actually have multiple copies in the Jamf Scripts section under Computer Management.

List of script titles - repeated in article

• Automatic Install Script - Auto Patching (Used for automatically patching applications)

• Automatic Install Script - Daily (Used for Self Service applications)

• Automatic Install Script - Onboarding (Used for Staff device onboarding)

• Automatic Install Script - Testing (Latest version of Installomator for testing)

• Automatic Install Script - Zero Touch (Used for lab zero touch deployments)

It adds a little overhead. However, it allows for a slightly better experience for the end user in some cases.

Jamf Pro - Patch Management Software Titles

To cut down on superfluous traffic, we’re going to make use of Jamf’s Patch Management Software Titles feature, rather than letting Installomator run on a random cycle.

Jamf Pro includes many third-party macOS software titles that can be used for patch reporting, patch notifications, and patch policies. These third-party software titles represent software that is not available in the App Store. In addition, Jamf Pro includes the macOS title.

For an up-to-date list of their available software titles, head over to their Software Titles Catalogue. We can’t do this for all applications, but the list is growing.

For this post, let’s use Bitwarden (I have a handful of users using this, makes it easier to see) as the example. In Jamf’s Patch Management, we’ll add a new software title, and select Bitwarden from the list of available applications. Once selected, we’re taken to the Patch Report page.

Jamf Patch Report screen showing the version distribution breakdown

Because this is managing credentials, I also like to select “Show in Jamf Pro Dashboard” so I can keep a close eye on version distribution. This is up to you. Remember, just because it’s automated, it doesn’t mean you shouldn’t be watching it.

For Installomator, we’re not going to use any more functionality within Patch Management.

Smart Groups

With our Bitwarden Software Title in place within Patch Management. We’re going to move on to creating the Smart Groups required for this workflow. Because Jamf doesn’t currently let you target a Computer Policy at a group based on “Latest Version” criteria, we need two (thanks for that Jamf, really helpful).

Our first group will be to check the latest available version of Bitwarden against the software inventory of the machines.

In my overly obvious way of naming things (you never know who may need to take over), I call this Software - Bitwarden - Updates Available. When looking in a long list, it’s really obvious what this is used for.

For the criteria, we’ll select Patch Reporting: Software Title, and then Bitwarden from the next list. The operator will be less than, and the value Latest Version.

Jamf Smart Group screen showing the criteria, operator, and value

Any machines that aren’t running the latest version of Bitwarden, and that have reported their inventory back to Jamf, will now be made a member of this group automatically.

Now we need to make another group that we can target with a policy.

My naming policy for these groups is Patch Policy - Bitwarden. We’ll have criteria of Computer Group, the operator member of, and the value of Software - Bitwarden - Updates Available (our first group).

Jamf Smart Group screen showing the criteria, operator, and value

Members of the first Smart Group will now be made a member of this Smart Group.

Computer Policy

With our groups in place, we will create the Computer Policy to actually do the work.

Our policy will have the name AI - Auto Update - Bitwarden. This immediately tells me, or other techs, that this is using the Automated Installer for automatic updates to Bitwarden. My obvious naming schemes continue!

We’ll assign it to the Automated Updates category, set the triggers as Recurring Check-in, and add a custom of ai-patchpolicy-bitwarden in case we need to call it manually, or with a script. The execution frequency will be Ongoing.

Jamf Computer Policy screen showing the settings for the General tab

Next, we’ll add a script option, and use the Automatic Install Script - Auto Patching version. If you haven’t added labels for your Parameter Values, then use Parameter 4. We’ll add the bitwarden label for Installomator here.

Jamf Computer Policy screen showing the settings for the Script tab

And finally, for scoping, add your second Smart Group that was created: Patch Policy - Bitwarden.

Jamf Computer Policy screen showing the settings for the Scope tab

That’s it, we’re done! Please ensure you run this on a test machine first. I take no responsibility for your lack of testing.

Workflow Summary

When Bitwarden releases a new version, the updated information will be sent to the Jamf Patch Management Software Titles. The first Smart Group will check to see if the software inventory for a machine is less than the latest version. If it is, it will add it to the group. If they’re ahead of the game, nothing will happen.

Once the machine is a member of the first group, the second Smart Group criteria will be hit (being a member of the first). They will now be added to the second group.

Our policy to run the script has a trigger of ongoing, and check-in. As soon as a device checks in with Jamf, it’s going to be told to run our script through the policy.

You now have an automated loop for updating Bitwarden without any intervention (hopefully).

---

I hope you’ve found this post helpful. If you’d like to receive these kinds of posts directly to your inbox, feel free to subscribe!