Adobe product package fails to install

I had the same issue. Kept telling me the file path was incorrect even though it was already looking at the PKG file. I tried lots of different packages but couldn't get it to work even though running it manually worked fine. I used the exact same process the year before which did work. I put it down to something to do with the OS version or file name encoding.

I contacted Jamf that wasn't really able to help but they pointed me in the direction of installing the apps via the Mac Apps page and using the Jamf App Catalog to install the adobe products. This has worked although it's not great.

Yeah, I run into this with Acrobat. The solution I'm using is a workaround. I'll jump on another Mac and manually check for updates for Adobe Acrobat.

I'll use Composer to package just the Acrobat app. And then I use a patch management policy to deploy. I'm sure that's a better way, but I can't get the package from the Adobe Console to work when I upload to Jamf.

I also use Adobe RUM to manage updates, and this helps. But I end up packaging it myself as well to get those pesky CVEs down.

i typically get machines to update adobe products including acrobat by running the adobe update manager in a form similar to this remoteupdatemanager --action=install, before running this command, I typically use the following style of command to close whatever app I am trying to update ex. osascript -e 'quit app "Acrobat Pro DC"' ; hope that helps.

Zipping the dumb thing actually worked. Ill take it, thank you!!!

Now if only JAMF or Adobe would document anything relevant involving this entire process. 

I learned about RUM a few months back, and have been using it ever since. Adobe could do to be more obvious with RUMs existence, but it does work well. The only downside is on older installs of Adobe products RUM was not included and does not automatically install on its own. 

Glad that worked for you! I'm pretty sure that zipping the file prior to uploading was from one of the Jamf support crew. I've used that trick quite a few times in the past year.

This worked for me too 🙌 Thanks for sharing the knowledge - I was tearing my hair out trying to figure out why it kept failing!

This issue has recently popped up for me, as i just updated all of our packages on Jamf. I eventually realized that Sequoia doesn't support legacy packages, so redid them as flat packages. Still no good. I then tried zipping before uploading. Still no good. I followed the advice of someone earlier to use Jamf app catalog, and those work fine, but here's the issue. We were using managed packages and we don't want users to be able to update apps at will. We were able to do this creating packages on Adobe's console, but the ones from Jamf catalog allow full access in Creative Cloud app. any way around this? Or how can I get the packages from Adobe to work? Thanks in advance.

Please feel free to describe your issue in more detail if necessary. Given what you posted above, my guess would be the excessive large size of the adobe installer packages are causing issues. Sometimes they will take awhile to clear the availability pending hurdle if they ever do. You can try toggling the cloud distribution point file share option without changing anything and that will sometimes get them to clear the availability pending if that is the issue.

Two alternative approaches would be to use a local HTTP based distribution point for your larger packages; if that is not possible, i would remind that you package the adobe apps; individually and just chain them together in a policy; these are two possible approaches with my assist. Hope that helps/

You are a king! Toggling the distribution point cleared the pending status and now they work fine. Thanks so much for this.

Hey Wgphoto,
Could you elaborate how you do this?

I'm in a pickle. I've just deployed a lab of mac mini's and all my 2024 PKGs were incompatible with Sequoia.

I then proceeded to repackage everything. Flat packages was already checked by default and I zipped the flat packages up and over wrote my last installers in JAMF cloud.

Weirdly, they all came back as upload failed after a short time on Pending. I did a few extra attempts, even without zipping and still no dice!

I then went back and tried packaging with flat packages deselected, and the Uploads are still being marked as failed upload.

This is all stupendously random.
Trying to work out what I'm doing wrong!

I've opened a support ticket with JAMF support, and also attempted to contact Ent support at Adobe. We're just about to go into our mad packaging phase ahead of the summer and Adobe is acore app for student labs!

Any info you can offer, I'd be much obliged!

The solution that i was describing above, is to go to:

<settings>cloud distribution point>edit>DO NOT CHANGE ANYTHING>Save

That process will often help packages that are stuck on pending availability, clear that status.

A better solution may be to have you packages on a local drive; any local drive and setup the below utility to connect to your instance of jamf. 

https://github.com/jamf/JamfSync

And use that to upload packages into the jamf cloud, I have found it to be by far the most stable;e way to upload packages into jamf cloud. Recently I used to add over 500 packages to my production instance. Also rename your packages (you can use the finder to batch rename them to force jamf to create a new package entry and calculate a new checksum. Works well. Hope that helps

(JN was in rwad-only mode yesterday)

Thanks for the clarification about the Pending status ‘nudge’.

I’m curious about your suggestion for syncing a local DP to the Cloud DP.

Previously with JAMF admin, we’d upload to our on-prem DP and then sync it to JAMF cloud.
With bigger packages, I had more success uploading bigger PKGs via the browser, then syncing from Cloud to on-prem (I think our JAMF cloud 'Cloud Distribution' -> 'Content Delivery' -> 'Principal DP' setting, has the checkbox checked.)

JAMF sync arrived, and I’ve continued as before, upload to JAMFcloud, then sync to on-prem DP.

If you’re seeing greater success syncing up a local DP to the cloud, could I ask for some more details as to how it’s done?
I worry if I go in blind and fiddle, I’ll wind up erasing the contents of the Cloud DP and replacing it with new Adobe CC PKGs 😃

I’ve checked this morning, and we have around 500GB on our on-prem share. Should I first find a spare device with fast storage/networking and first sync down the current contents of the Cloud DP to be stored locally. Then manually add the Adobe PKGs to the folder and sync it back the other way?
Or perhaps this step isn’t necessary – and there’s no risk of binning all PKGs from our JAMF cloud DP, by simply syncing the contents of a folder directly?

When JAMF sync mounts our JAMF-DP share, if I have permissions, perhaps I can just copy the PKGs there directly, then sync the on-prem DP to the cloud instead?
- Update: I checked yesterday and the '~/Volumes/JAMF-DP$/Packages' folder has PKGs that have been rejected in it as well as the ones I had originally replaced. Maybe by design it's set to hold onto errored files for a short time afterwards.

I appreciate the guidance 😊

Wheel

---

@Qwheel wrote:

I’ve checked this morning, and we have around 500GB on our on-prem share. Should I first find a spare device with fast storage/networking and first sync down the current contents of the Cloud DP to be stored locally. Then manually add the Adobe PKGs to the folder and sync it back the other way?

I appreciate the guidance 😊

Wheel

---

yes this is what i did, just to be safe, I was building a local https DP anyway so i needed to download everything at least once anyway. All my packages stopped installing due to a bug jamf introduced in one of the 11.x series (lost checksums) updates, so re-loading everything helped to get jamf to calculate new checksums so the packages would  work again.

i downloaded everything from the cloud using Sync, this download doesn't have to go to a configured DP per se; it can be any folder that has enough storage, whether that be on the network or a local disk.

I then configured a local HTTPS based distribution point, and went from the cloud to the www directory of the HTTP server and for future additions  I add new packages to the cloud and sync them back down to the HTTPS; this will ensure that jamf puts the file in a directory path that it expects, ie. www/Packages.

I never had an issue of sync overwriting something I didn't expect, That said backups are your friend, I was very glad I had a back ups of the cloud packages when all the checksums were lost,

One gotcha with the local HTTPS DP, the server needs a x.509 commercial cert on it. One thing I found out was that all the clients need the same cert added to there system keychain or the jamf policy will throw errors. At least it did in my experience. The x.509 profile can easily add the cert to the keychain. hope that helps