blog.dataJAR

Understanding and managing Adobe application updates

Introduction

You have jumped through all the hoops to get your Adobe licensing sorted at your organisation, you have managed to get all the titles packaged and deployed out to your users and now you can rest…right?

What about when Adobe releases patches that fix a really annoying bug your users are experiencing? What if a critical security bug is patched and you need to make sure your devices are safe, secure and patched? What are your options?

In this post we cover the three core options you have for rolling out Adobe patches – with the pros and cons for each.

Updates versus upgrades

First, we will clarify the core differences between updates and upgrades with regards to Adobe software. This line has become rather blurred in recent years as Adobe has moved to a subscription model, meaning you are no longer tied to a specific version with a license key.

For the purposes of this post, updates are clarified as minor updates to software within the same major version/product name. For example, updating Photoshop 2021 from 22.1.0 to 22.2.0.

Upgrades, however, are considered jumps between major versions/project names. For example, upgrading from Photoshop 2020 21.x.x to Photoshop 2021 22.x.x. Upgrades are not what we are looking to cover here.

Option 1: your users

Your first option would be to configure your Adobe desktop app to allow your end users to run their own updates. This may mean changes to the options you use in the Adobe console when creating your packages, or making changes to the configuration after deployment (as detailed here).

This will allow your users to manage and install their own updates when it suits them. On the flip side, it would also be possible for users to install upgrades instead of updates resulting in a mixture of different major versions of Adobe software in your fleet, increasing the risk of breaking workflows and compatibility problems. This option also provides no method to force updates to maintain a baseline for your fleet.

There are ways to push updates to software, which you could combine with option one, such as:

Option 2: RUM

Adobe has a command line tool called RUM (Remote Update Manager) which can be used to install updates for various Adobe software titles. This handles software updates and cannot perform upgrades, so it would be ideal for this usage.

This can be used to enforce updates for your fleet, but does not require you to deploy RUM in addition to your titles. RUM can also only update applications the user has installed already – it cannot perform an initial install of titles. As a result, you will need to deploy RUM and either:

Push down an initial installation of a title, or
Enable the user option to install their own software

This is not ideal as you will need to ensure your initial deployment packages are new enough to install on the current OS. You may also have to go through a full install, followed by an immediate update. Additionally, it may allow users to install multiple major versions of titles across the fleet again, risking the same workflow and compatibility issues mentioned under option one.

Deploying RUM

The easiest way to deploy RUM is to tick a single option when creating your initial installation packages (see below). This option will add the RUM install to your packages, putting the binary in the location /usr/local/bin/RemoteUpdateManager.

You will also find another option to enable the use of an installer Adobe update server, or AUSST (see below). This can be used to host an internal source for the installers themselves, as well as to control the release of updates. More information on AUSST can be found here.

Updating RUM

RUM naturally, as a piece of software, has updates that need to be deployed. Unfortunately, RUM does not have the ability to update itself, so in order to deploy updates to RUM, you will need to recreate an updated application installer from your admin console, and deploy this to your fleet to also update RUM.

Maybe we need some sort of RUM remote update manager?

Option 3: your software deployment solution

The last option, and the one we follow for our Auto-Update for Jamf service, is to utilise your deployment solution of choice. We have notifications turned on for any new updates from Adobe and, each time they release an update, we create new packages and load these into our deployment system of choice.

This allows us to push out Adobe updates in a structured manner, controlling which versions are available to, and patched on, user devices. Due to our configuration, this also means a freshly onboarded device will get the latest minor version deployed, rather than an older initial version that needs a follow up update.

On the negative side, this is a fair bit of work for the administrator on a semi-regular basis but for us, the trade off is worth the control and ability to ensure a patch level is met.

Summary

We have covered the three core options available for patching and updating Adobe software on your macOS devices, your users, RUM and using your software tool – while hopefully providing some pros and cons for each option. Whatever you choose, please keep your devices patched and protected.