Adobe 2021 installation fail

[JoySeeley]

I've tried several different ways of uploading the Adobe apps, from wrapping the pkg in a dmg and using the script provided by Jamf to install from a dmg. I've tried uploading the package through Jamf Admin and letting it zip up the package. I've zipped it up, before uploading with Jamf Admin and nothing I do will allow the package install, remotely.

However, if I login to Macintosh and run the policy from command line, it is successful

Does anyone have any suggestions? I don't really want to login to 100+ Macintoshes and manually install Adobe 2021.

Thank you.

[G_Zirrak]

Hello,

I recently was able to deploy Adobe 2021 packages to Intel and M1 machines through Self Service. About a month ago, I was having a lot issues getting a handful of Adobe apps to run on M1 Macs. I would sometimes get installation failed errors on Self Service, but the install was actually completed, with a complete status in the actual policy logs. So just a heads up on that. But most recently, I've had the apps install complete properly without any error messages. And with recent Adobe updates to its applications, all apps seems to now function on Intel and M1's Macs.

With that said, below is a brief summary of my implementation:
1. I configure each Adobe application separately on Adobe admin console. Which then downloads the DMG file from the browser. 2. Next I run the DMG which opens the Adobe Package Downloader which creates a Zip folder of the applications. 3. Within the zip folder is the build folder, then the install pkg. and uninstall .pkg. I then drag the Install .pkg file directly into JAMF Admin. Depending on the App some take longer to upload than others. 4. After uploading the packages through JAMF Admin, I created a policy for each app, and enabled the Self Service feature. I did not set the policy to cache and then install from cached. Just a straight install of the app.

Just some side notes: From the testing I have done, I recommend uploading Adobe packages using JAMF Admin. I ran into issues uploading with the JAMF web interface. JAMF Admin automatically Zips the .pkg file, so no need to zip the file yourself before uploading. Also, if you happen to delete a certain Adobe app from JAMF and want to re-upload the same application, make sure to change the name of the .pkg file. As I was doing extensive testing, I kept uploading each applications a couple of times that were configured differently from the Adobe console. I also noticed sometimes if the app got corrupt while uploading to JAMF, the checksum portion of the app in JAMF Admin is blank. If there are random characters in the checksum portion then guess thats a good sign that the package is uploaded properly.

[phil_kurbis]

Thank you @G_Zirrak for this! It is a bit tedious, but working like a charm!

[ckulesza]

You must have some sort of magic powers. I tried just with the CC installer and it fails as usually. I used Admin this time to upload and not the web with the same results. Failed install in SS

[c_archibald]

So we're using JAMF Pro, no cloud. Our JAMF Admin does NOT zip anything, never has. Pretty much do the same as G_Zirrak.

1) Adobe Admin Console & package each App separately as Offline All Apps Restricted with RUM
2) Download downloader DMG, open & run App to download ZIP
3) Extract ZIP, move uninstaller out of Build folder, use Disk Utility to create DMG from Build folder, drop DMG in JAMF Admin
4) Create policy Ongoing Custom trigger w/ Self Service, add DMG set to Install, use installPKGfromDMG.sh set After w/ Param4 set to DMG name, allow restart id user logged out, Update Inventory.
5) Either Admin OR end user/usergroup scoped can install via Self Service. It queues, but runs out of order.

For some reason, since last month, RUM does NOT update to newest version till like a week AFTER release. You know, so if you're heavily Security minded or orientated, you have to uninstall/install new. At least CC App is NOT forced into these ... yet. But it will, at some point I'd bet.

Only issue we currently have is that updating a non 2021 version with 2021 does NOT change the App & Folder names. I have to set policies based off Name Has & Version instead of Name & Version. For more accurate policies where non 2020/2021 version may exist, make sure you use Name Has, else Version out of date will be inaccurate.

[skinford]

How do you get JAMF Admin, to not Zip Adobe files?  I would love that if it works as you say it does. 

Thank you for the post!

[mhasman]

Just started happening with me yesterday. Deploying 4-5 packages, each has single Adobe application. 3 were installed suxxessfuly, 2 failed. Same happening when pushing those packages with Jamf Remote. But! When I copy those two packages, failed, to Macs and run installation manually, those install with no error. Yes, all .pkg were zipped manually before being uploaded to JSS with Jamf Admin.

[G_Zirrak]

Not to mix topics on this thread, but since we're talking about Adobe installs @c.archibald Just wanted to ask how you handle Adobe Suite updates for all of the Adobe apps? I guess more specifically with updating apps from within the 2020 suite. Do the users themselves update the apps? or do you push out any sort of updates on your end? Also in the case of upgrading Adobe apps from 2020 version to 2021. From what I got was that you just install a new version of the "said" adobe app to the clients computer, without uninstalling the 2020 version?

[aaronj]

For the sake of science, I did the following to try to further determine what's going on here:

• Packaged using Adobe Admin Console, Download DMG, run to download ZIP
• Unzip downloaded file, grab _Install.pkg out of the Build directory.
• Rename with the version number (AppName-25.2.1.pkg), then zip using Finder's compress (Also tried ZIP and DITTO)
• Upload with JamfAdmin 10.28.0, saving after upload completes.
• Attempted install with policy, got the dreaded error.
• Downloaded the file from Jamf Cloud with Jamf CPR, transferred to the machine via external drive.
• Unzipped on the target machine, and installed as root with: installer -allowUntrusted -pkg /path/to/AppName-25.2.1.pkg /

The manual installation was successful, with the file downloaded from Jamf Cloud. That leads me to believe that something is being borked in the Jamf policy's run of installer.

Thoughts?

[mhasman]

Hm... when installing those packages manually, there is message like "Installer wants access to your Desktop files". Can it be an issue even if Jamf policy runs on root level?

[aaronj]

No GUI messages whatsoever when installing the packages manually during my tests as root; just identifying the package name, the target path, then a success message.

I think one of the real questions here is... what is the command that JAMF policies are using to install a package after it downloads and unzips?

[JoySeeley]

Updating on my dilemma... I think I agree with the "it's Magic" theory, as the installs started working and I am using the script that wraps them in a DMG. I'm not sure what I did, other than to walk away from the problem for awhile. I still need to test to see if it installs without human interaction when I use the zip files, but I have to tell you, I LOVE magic!

[mhasman]

I installed full Adobe applications set today to 3 different Macs, all with latest Catalina 2021-002 update - no any single package failed. Same packages which were failing randomly. Have some feeling the issue was on macOS side, and something has been fixed with last update, at list in Catalina.

[aaronj]

No joy here using Mojave or Big Sur, with the latest update installed. For those folks that are having success, could you please share the settings you are using in the the Adobe Admin Console when creating a Managed Package? I'd like to be able to compare apples to apples.

[aaronj]

Well, this is interesting...

• Created package in Adobe Admin Console, went through process to download, extract.
• Zipped the _Install.pkg file with ditto -c -k --sequesterRsrc --keepParent <source> <dest.zip>
• Uploaded zip file via JamfAdmin, changed policy to use new file
• Ran policy on target computer, failure as usual.
• Downloaded zip file on target computer using jamfcpr.
• Moved file to /Users/Shared (just somewhere to get at it)
• Logged in via SSH as admin user, sudo -i to become root.
• Unzipped with unzip <file>
• Attempted installation with installer -pkg <pkgfile.pkg> -target / ... failed as usual.
• Used exit to get back to admin user.
• Attempted installation with installer -pkg <pkgfile.pkg> -target /, which tells me I must be the root user.
• Used sudo installer -pkg <pkgfile.pkg> -target /, which.... works.

Why does sudo from an admin user work, but not root? If an SSH session as root isn't working to install the package, then installing via a Jamf policy isn't going to work, at least not without some fancy scripting.

I repeated this process with a second package, with only these steps:

• Created package in Adobe Admin Console, went through process to download, extract.
• Zipped the _Install.pkg file with ditto -c -k --sequesterRsrc --keepParent <source> <dest.zip>
• Uploaded zip file via JamfAdmin
• Downloaded zip file on target computer using jamfcpr.
• Moved file to /Users/Shared (just somewhere to get at it)
• Logged in via SSH as admin user
• Unzipped with unzip <file>
• Used sudo installer -pkg <pkgfile.pkg> -target /, which.... works.

This seems to confirm that installation will work via SSH with an admin user using sudo, but not root.

[aaronj]

The above investigation and reporting to Adobe yielded this response:

I was able to reproduce the issue by connecting to a Mac via ssh (when it was at the login screen) and attempting the installation via a shell initiated with "sudo su - root". The issue appears to be that there is no keychain accessible from the root account. Our engineering team are investigating this, but at present this appears to not have a workaround (other than using a different deployment mechanism which avoids the root account)

While they aren't promising any sort of fix, the fact that they were able to duplicate the issue and identify the cause of the issue is a good sign.

[neddington]

Hello,

I recently had a similar issue where old Adobe Packages would deploy but new ones would fail. I fixed it a similar way aaronj did but with less steps. I ended up finding out if I compressed the .pkg into a .pkg.zip it would then deploy properly (Right click the created package you downloaded from Adobe Admin Console and "Compress"). Jamf Support was able to confirm the issue. We were unable to determine the difference in the packages from the early 2020 version I had downloaded earlier in the year to the one that was downloaded 6 months later that had to be compressed.

Please note, the manual compression does not actually shrink it down at all since the .pkg Is technically a .pgk.zip. Hope this helps.

[aaronj]

@neddington, unfortunately simply compressing the pkg file using Finder, ditto, or zip does not seem to work consistently for our situation with the latest installers from the Adobe Admin Console, as mentioned in my 4/15 post. After reading through other posts here in the forums, compression was one of the first things I had tried.

My guess is that there are two issues here; one that is being caused by Adobe's installers suddenly needing keychain access and the other by some sort of permissions issue (that can be bypassed by compressing the PKG). Note that the former issue doesn't happen on every application. XD installed without issue, but Photoshop, Acrobat, InDesign and Illustrator do not.

[csaevang]

Using Jamf Cloud, I haven't had any issues deploying Adobe CC since I started uploading my packages with Jamf Admin.

Extract the Install.pkg in the build folder and upload it via Jamf Admin. It'll zip itself and it should be good to go after that.

Nowadays I only package Adobe CC 2021 with the ability for end users to update and install and I let them choose what they want. But previously with 2020 I had each individual application packaged and put up with no issues.

[aaronj]

Nowadays I only package Adobe CC 2021 with the ability for end users to update and install and I let them choose what they want. But previously with 2020 I had each individual application packaged and put up with no issues.

This is exactly why you're having success. The problem didn't exist with the 2020 installers, nor did it exist at first with the 2021 installers. It's only been the last 1-2 updates with each application that have exhibited this behavior, and only when packaging a Managed Install in which users aren't able to choose what to install and when. If the CC Desktop app is what's doing the installations, then that's happening in the GUI not via a Jamf policy.

In our environment, we need often to have both the version for "this year" and "last year" installed side-by-side because there are plugins we use that go with some enterprise hardware. The companies that make that hardware are a little slow to update their plugins, but our clients are quick to upgrade; thus we cannot just go the 'let the CC Desktop app manage installs' route.

It should be noted, however, that the problem exists on a fresh machine, with absolutely no Adobe application installed, ruling out our side-by-side setup as the culprit as well.

Extract the Install.pkg in the build folder and upload it via Jamf Admin. It'll zip itself and it should be good to go after that.

Yes, that's the original method that was being used. We only started experimenting with other methods after that method failed.

[PaulHazelden]

@aaronj Some time back Apple changed how Root works, it is now no longer the super user it used to be. Admin using sudo has more power and access. It is the preferred method in the world according to Apple. I have come across quite a lot of things that I cant do as root but can do as Admin with sudo. I also have a couple of Apps that I have to install with root logged in to the gui, what a pain they are too.

[#22]

HM, this is very interesting, I started uploading my packages a long time ago using Jamf Admin, it's convenient.
good luck to you

[ckulesza]

So I just did a few packages using JAMF Admin and zipping them before hand. To my surprise they worked and installed with no errors. I have been chasing this issue since late last year.

[user-ray77]

We use Adobe user licenses over device licenses for Adobe Creative Cloud. We deployed just the Adobe CC Desktop App, then have the users login using Google Authentication and select the apps they want to use themselves (like self service).

Regards
Ray

[abonsall]

I've been running into the same issue with an Adobe 2021 all apps SDL package and zipped up to Jamf Admin. Executing the policy with no user interaction constantly fails. I noticed that a simple SDL package with only Creative Cloud app would complete. After hours of trying different things I found a workaround for my environment. Exclude Acrobat DC from the primary package install. Add a secondary package with just Acrobat DC and it works as expected. Acrobat has always caused problems in the past and I'm not surprised it was the cause of my issues now.

[cizdziem]

@aaronj, do you by chance have a case number for the issue you discovered where installation is successful as an admin using sudo, but not as root? I'd like to cite your case when submitting my own feedback to Adobe. I understand they are looking into it, but I'd like to add my organization to the list of those impacted by this and hopefully expedite a fix. Thanks!

[echave]

We do just as Ray/@user-snpqovsIDp outlined and only have to update the installer once a year or so.

[aaronj]

@cizdziem, I do not have the case number handy as I am working from home today, however I did also make a post on Adobe's Enterprise Forums prior to opening a ticket. An Adobe rep confirmed they were able to reproduce the issue in the forum post as well.

I haven't received a further response from Adobe, however someone else reported that the change to the Creative Cloud installer that caused the issue has now been reverted in new packages, as of May 19th. I'm downloading two packages right now to give it a test run, and will update this thread with the results.

[cizdziem]

@aaronj Thank you for the update. I am testing it as well.

[mhegge]

We are cloud based. We had to break up our Adobe installs into 3 stages and 3 packages as a single super huge package was not workable with the JCDS limit of 20G. Set up three policies, with each policy kicking the next off with an Event.

[aaronj]

I can now confirm that the issue, which boiled down to an inability to run the Adobe installer via a root login, seems to be resolved in new packages created in the Adobe Admin Console. I've only tried Photoshop thusfar, but as the issue was said to be in the Creative Cloud App installer, I'm fairly confident that it should be fixed in all of the applications.

The ticket referenced by another party was CLIC-697.

[cizdziem]

I was able to successfully install InDesign using a package made on 5/24, so I share your confidence in the others. Thanks again @aaronj .

[jimkirk]

I discovered that at least with macOS 11.4.0, the Adobe Acrobat DC v21 installer checks to see if Safari is running, and if it is, it throws a "Block: Safari" error, stating a conflicting process is running, and results in a failed installation. As a result, when attempting to deploy Adobe Acrobat DC v21, you may want to do a check first to see if Safari is running, and if so, either prompt the user to close or kill it with forewarning in the description. Hope this helps someone.

[mhegge]

Yes, you cannot have Safari running. Can cause a complete cluster.

[skinford]

We were having tons of issues installing Adobe apps, and after months on a support ticket with JAMF and wrapping our head around log files, we found this that I have listed below, not sure if it will help everyone, but it definitely helped us.

Turns out the Apple ethernet card goes from a full 1G down to 100M when you're at the login screen unless someone is logged in and then it stays at a full 1G when logged in.

I found this script here that fixes the issue, it runs the caffeinate terminal command.
https://community.jamf.com/t5/jamf-pro/prevent-mac-from-sleeping-best-practise/td-p/188961

This is how I changed mine, just making 24 hours the default instead of the three hours they had set.  We install more packages and I just wanted to test to make sure they are awake for that time in case of other loads we throw at them.  You can add whatever time that you want in "$4" when running it up to 48 or anytime other than 24 hours.

#!/bin/sh

declare -i LIVE_TIME
LIVE_TIME=86400
if [[ "$4" -gt "0" ]] && [[ "$4" -lt "49" ]]; then
LIVE_TIME=$4*3600
fi
echo Machine will not sleep for $LIVE_TIME seconds.
( caffeinate -sid -t $LIVE_TIME ) &
disown
exit

I'm having no issues running Adobe or anything because the card doesn't sleep anymore if you run this first script first.  Hope that helps someone.

[cshanklin]

Hey @skinford , is there any way you can provide your proof of this? Link to the article? or what your test was? Because if it's true, it would explain a lot over the last few years.

Thanks in advance. 

[robertojok]

I have also experienced this problem. It appears that when you upload the cc 2021, somewhere along the process of uploading and zipping, permissions seem to change so you get the 403 error of package not being available. If you attempt to download the package directly from a browser you get the error no permissions. However if you perform an install of the same Adobe package at computer enrolment it is installed. So I do not understand why this version of 2021 is causing issues.