Are you able to find the Adobe logs on the machine to determine why they failed? You should be able to find them in console somewhere.

Yep, this is the relevant log to the install above.

Yes I do, but Jamf isn't letting me post the log here. When looking through the logs, however I do see "No new applicable Updates. Seems like all products are up-to-date" which I know isn't true because I can see all the available updates in the Creative Cloud.

This may or may not be related but on my main driver remoteupdatemanager does not see any new updates available even though the CC application does. I've had this issue for a couple weeks at least. I opened a ticket with Adobe about it but they don't seem to eager to work with me on it. It took awhile for them to respond and then the lady seemed to get me off the phone as quick as she could. That was last Tuesday. Her advice was to reinstall the Creative Cloud application and if it does not work, respond to their email with the results. I did, it didn't solve a thing, and have not heard back from them.

Thanks for the reply. Adobe's support is as finicky as their apps so I'm not surprised they weren't much help. I did end up getting this to work, and I did so by making my RUM scripts very granular, only targeting a single Adobe application for each script run using the following command.

 That's just for updating Adobe Bridge, but I had success with that without having to uninstall anything. Full script below is a stripped down version of the one I linked earlier, but it's been working for me.

 In Jamf Pro, I created smart groups for each Adobe application and then a matching script/policy to target each application individually for updates. It was a pain to setup as it's pretty tedious, but that seems to be the norm with deploying/updating Adobe products.

@GreatestJagras cool script! Are you still utilizing this method to manage your Adobe software updates? I'm looking into options for our organization and was curious if you've made any new modifications since this post.

Yep, still using this method as it's mostly hands off and doesn't require much in the way of changing so long as you're on top of updates. Each year I just go in and create a new script for whatever year the Adobe software is (2022, 2023, 2024, etc) and then put together a smart group and update policy that runs once a week.

Great approach!  I've been using a similar method of scripting this or running it (RUM) via Files and Processes as a single line because I don't do any differentiation and simply want to update Adobe across entire labs. So, often I don't need to script it, but I can see where it has benefits. I'll script when I want to plan a reboot after the updates.

But... I was curious as to why you:

caffeinate

 and why you kill JamfHelper:

 # Kill jamfhelper
    killall jamfHelper > /dev/null 2>&1

    # No more caffeine please. I've a headache.
    kill "$caffeinatepid"
  
  exit 0
else
  echo "Adobe RemoteUpdateManager not found."
  
  exit 1
fi

for this task? What benefits does this provide? Have you noticed a difference?

caffeinate

 # Kill jamfhelper
    killall jamfHelper > /dev/null 2>&1

    # No more caffeine please. I've a headache.
    kill "$caffeinatepid"
  
  exit 0
else
  echo "Adobe RemoteUpdateManager not found."
  
  exit 1
fi

The script in the solution is the most up to date script that I've been using. The kill JamfHelper script I initially posted was I believe a leftover from an older script someone else had written to update Adobe apps, and as such I don't use that part anymore.

The caffeinate command I do use because I've seen issues (on both Mac and Windows) of clients going to sleep during Adobe updates since they can take so long. I try to only run large updates on those applications outside of class/work hours to prevent any interruption. The way it is setup right now, Mac computer lab clients will be caffeinated when they check in Saturday/Sunday morning, and process all relevant policy updates before going back to sleep.

Below is the current version I have setup for Premiere Pro 2024.

Another thing I like about this method is that it gives pretty good logs of what the update policy is doing while it is running. The most common issue is the download being interrupted, but I've found the caffeinate command helps with that.