Adobe CC 2018 Fail to Install

Can you post an image of your CCP prefs?

Do you have it set to ignore errors during install?

Do your machines have an previous versions of CC installed?
If so, I find renaming/removing the /Library/Application Support/Adobe folder helped me out

that should be enough, however, if you have an app open (even the CC Desktop app) it can cause the install to fail.

Another issue is a lack of space, jamf caches the install before installing, so you will need extra space as well.

Finally, if those two things don't work then it's time to dig into the log files..

Ran last week into the exactly same problems on all our 53 Art/Visual Computers. Did today the "workaround" with wrapping the Creative Cloud Composer pkg to an DMG an deployed via policy and the installPKGfromDMG.sh Script. Worked almost perfect (only 2 errors and you have to login as local admin) but perhaps you should get it a try...

The workflow was as listed here: https://www.jamf.com/jamf-nation/articles/161/deploying-pkgs-created-with-aamee-or-creative-cloud-packager

Thanks Guys!
I was able to install the pkg manually on the same iMac so I know the package should be okay. I always had problem deploying Adobe pkg files in the past so I will try @michelbertschy turning them into DMG.
My CCP is set to ignore errors. I will have to have a look at the log file then.

On another note, how do you guys package the Updates only?

Are you deploying the default .pkg created by Adobe CCP?*

If so, and your deploying over the top of an existing CC install, Adobe installs Adobe Acrobat is an orphaned application.
(Even though its installed as part of a bundle CC app, the install its not actually classed as part of the main CC suite, but as an independent application on its own).
While you can easily install different builds of CC over the top of an existing install, due to Adobe creating their own non-Apple standard installer program which will always fail if it detects a previous version of the Acrobat.app already present on the computer. (Either as part of a CC install or intently as a Acrobat Reader or Acrobat Pro install)
As a quick’n’dirty approach I just run a pre-script as part of the install process to manually delete the Adobe Acrobat folder in the /Applications/ directory prior to any CC install

Once removed, we can then also install multi-builds of CC (2015,2017,2018) on the same device but it always uses the version of Acrobat deployed by the last deployment (as every all previous version of Acrobat get deleted)

You can test if the same issue that I see by just manually trashing the Adobe Acrobat folder first on the test device and then deploying your CC pkg afterwards

*if you created your on install via DMG or Composer you won’t see this issue, its only happens with the Adobe CCP built pkg
In general, Adobe CCP is a real big in the backside

@gbidwell Yes I did use the PKG straight from the CCP build folder.
What you just said makes so much sense. I am going to test it now.
Thank you so much. So do you recommend to turn the PKG to DMG?
Also, can you package updates only using CCP?

not really, I just keep them as the default Adobe pkg's as its far less work and use a pre-script common to any CC install to cleanse the old version off the device before a new installation (or use a script just to remove the Acrobat only, if we need multi-versions of CC installed for testing).

My experience is that in 9/10 cases this happens it's due to previously installed Adobe products on the target. The pkg installers build from CCP are very picky and prone to create failures when installing on top of other Adobe software.

If you can successfully clean up previous installs, your installation of CC2018 will go just fine.

Cheers

I totally recommend packaging the Adobe apps individually vs creating a monolithic package (they install side by side fine). That way, you're likely to get more reliable deployments (smaller downloads) as well as being able to identify problem apps more easily. Also, in our environment, staff are grateful for being able to just install the apps they want vs download the whole monster that is everything. It is more work to create separate policies etc to deploy it though.

Patrick Fergus (aka @foigus ) did a fantastic session on the ins and outs of dealing with Adobe stuff a couple of years ago - it's still very relevant: https://www.youtube.com/watch?v=i5cRLn5x754

upload the package, create a policy and use the package installer.
Cache the package.
Then create a script that rm -rf /Applications/Adobe* this will remove any adobe that is there.
Then use the installer command to install the cached package. The package once download store in the /library/Applications Support/Jamf/Waiting Room
also in the script tell it to rm -rf the package file in the waiting room. so it will remove the large package download after its installed.

set the script to run { after ] and not before other wise the script wont do anything.

It looks very similar to issue i posted in thread shown below

patch-management-installer-error-the-package-path-specified-was-invalid

I am having this issue with Acrobat Pro DC (CC 2018 Serial License).
It only happens with Acrobat, I have the full CC 2018 suite split into individual packages and the rest don't fail.
The best part is, the install DOESNT fail, Acrobat installs and runs fine, but it always errors out (even on freshly imaged machines) which causes our DEPNotify workflow to hang graphically (it completes in the background but has to be force closed)

An adobe rep should be calling me today, will post back with any results.

@mkotara - we had issues reinstalling Acrobat. We found that if we deleted the files in Library / Application Support / Adobe / Acrobat, the installation would succeed.

Now our issue, we moved from named licenses to device licenses. We've uninstalled all the apps and reinstalled them; however, Acrobat still wants us to sign in with an Adobe ID, and sees our old named license and wants us to 'Buy' a license. So our Acrobat is stuck on a named license it seems.

Adobe support is garbage, I get transferred 3-4 times, and then hit a 'Connecting you with a specialist' wall that eventually never gets connected.

We always had the same problem, The way we solved it is, that when we package the apps using the Adobe CCP (with a site serial number) we untick the box that adds the Creative Cloud Desktop Application.
Then upload the package like you do. But instead of making a policy , we only ever push it out using Jamf remote. Cache it first, then install it. It works every time.

Just had this problem again, but with Photoshop on a clean machine without installing the Acrobat Package.
This problem seems to be intermittent and I have never been able to recreate the issue in a Mojave VM.
My call with Adobe support also revealed nothing, nor did the Adobe installation logs.

CCP Preferences: CC Desktop app is UNCHECKED for every package

I am going to attempt a cache policy for the Adobe CCP .pkg (which get zipped when uploading to jamf), and I will attempt with a composer PKG, composer DMG and I will also pull the flat package out of the CCP package and install the license payload separately. Will report back with my findings.

FWIW some of the packages will still report an error even with a manual install of the PKG so I don't think Jamf is the problem.

@nethers

I also ran into this problem, Serialized packages with the CCP app would tell me a sign in is required. The solution was to delete everything Adobe off my machine, though I think Acrobat telling me its not licensed is specific to my computer because I used the same package on a different machine without an error.

@mkotara I believe you're right about uninstalling everything to get stuff to work. That worked, but I was hoping to avoid doing so. Ah well.

Just tried again with the following packages on a VM: (CC 2018 with Serial License)

ACROBAT, BRIDGE, DREAMWEAVER, ILLUSTRATOR, PHOTOSHOP, INDESIGN, LIGHTROOM, PREMIERE,

This time it hung at Illustrator, mind you all these are CCP made packages. The packages haven't been modified in any way. Next test will be with Composer built DMGs/PKGs. If that still fails I will try again with a cache policy. This is getting very annoying honestly, jamf says the script exited with error code 1, but the only exit 1s in the script provide a reason in the log. This doesn't tell me what failed or why. (Also Illustrator installed and so did the rest of the packages but DEPNotify is hung at 'Installing Illustrator'

---EDIT---

I wrapped my PKGs in a DMG just fine. We use a SMB share at work, and according to https://www.jamf.com/jamf-nation/articles/161/deploying-pkgs-created-with-aamee-or-creative-cloud-packager PKGs made with CCP on a SMB share will fail.
To test this theory I will image my VM at home while pulling from the cloud server. If that goes along with no errors I would suggest just wrapping the CCP PKG in a DMG and caching it then installing with a script.

IMO it's going to be too much work to use composer for every single package, especially since my machine has residual files since I use this to build everything.

We use SMB shares here and they certainly do break the Adobe packages.
I don't use Composer or the dmg route to install them. I compress the pkg in a .tar.gz archive, then in Composer add in a post install script to run the pkg and tidy up after the install. build that as a pkg, and set it for distribution.
I find this works. It is simple and each install is a totally fresh one direct from the pkg. The .tar.gz protects the adobe package from the errors from the smb share.
I also use this for a whole load of other installs too. You can also put more than one pkg in the archive and install them all.

Updates are done using Adobe remote update command line for all apps apart from the Creative cloud Desktop app, this requires elevated privs to be set in CCP for it, and then the non admin end users can update it as and when it is required.

@PaulHazelden

I tried this again last night while pulling from the cloud server. Tried it with the CCP packages that were zipped by jamf when uploading and tried with DMGs. Both failed. Mind you for the DMGs I was caching the package and then running a PostInstall script to handle their installation, and in theory the cloud share should be able to recover from any packet loss because the HTTP server supports download pauses, right?
At this point I am not sure if its DEPNotify, Jamf or Adobe.
How does compressing to .tar.gz help more than jamf admin zipping it during upload?

@mlizbeth I tried zipping the packages and that too failed in a similar way to the smb fail. I am not sure why it works, but the .tar.gz compression works. It also works on a lot of other things too.
It is something to do with the way Adobe create their pkg files. With the SMB shares the files contained in the pkg drop their links to the file they require, and so it breaks. It does something similar when the pkg gets zipped. But the tar.gz compression preserves these links. I believe the DMG route is similar in preserving the links.

I used to spend a week or so building CCP packages, and then capturing their installs with Composer, then building a pkg and uploading it then testing it all. Often the Composer snapshot would miss something and it would be back to the start, erase the Mac and try again. I tried the DMG method, but ran into a couple of issues, I then stumbled across the tar.gz method, and now I can usually knock out all of the CCP installers in a day.

My work flow is...
Put the package in a folder, located in a good location. I use an Install folder I create in /var, and then put the pkg in a sub folder.
In Terminal cd to the parent folder, and then tar.gz the sub folder.
Drag the tar.gz archive into Composer.
Add a Post install script to it.
Then create a pkg of it.
Upload this to Jamf Admin, and set it to distribute.

The pkg you created will then put the tar.gz archive in your Install location, and then the post install script will run. The post install script will expand the tar.gz, which will result in a folder with the CCP pkg in it, and then the script will install the CCP pkg. I then have it clean up everything. The pkg distributed then reports back to the JSS that the install is complete.
If you want you can put several CCP pkg's into the archive and then install them all in Alphabetical order. I do this with Logic samples, around 60 at a time.

@PaulHazelden

Cool, I will give it a try. I still think the problem is with my DEPNotify script because I had it install our "Common" suite which contains 8 packages. It fails with the .pkg.zip and DMG route over SMB and HTTP. Though the same exact policy called through Self Service completes successfully (with the .pkg.zip files from CCP)

Hope it works!

-----EDIT-----

You are a genius my man! I made the packages into a .tar.gz and made a package in composer with a PostInstall script. Worked absolutely flawlessly with my DEPNotify setup! However it's a little bit inconvenient...

Q1: Does jamf know what to do with .tar.gz files? Will it try to .zip them, or even attempt to extract them?
Q2: The package is 12GB. So by the time it downloads and then extracts the tar files, it's using around 25GB of space. Then it starts to install the Adobe packages, which will use about 15GB of space. I have the script deleting the .tar.gz files after it extracts the pkg, but I don't have the pkgs being deleted until after all of them are installed. Is there better way to do this?
Q3: How well (or poorly) will it work if you take the CCP PKG files and make them into a single PKG with Composer and use a PostInstall script?

I am just trying to find ways to reduce disk read/write time. Anything you can provide is greatly appreciated.

Not ideal but it solves the excess disk usage.
I changed my policy with the .pkg.zip files to cache and then after that policy is complete DEPNotify calls the install cached policy.
Working on my machine with a SMB share.

Hopefully this thread helps somebody else!

@mlizbeth Thank you, I am glad to have helped you out.

Q1 The tar.gz compression protects the vulnerable adobe pkg. And then it is wrapped into a pkg from Composer, which is handled just fine by Jamf.

Q2 My post install script bins each pkg after it installs it, not after they all install. I use a loop in the script to pick each pkg, install and delete it, I even use the same script if it is one pkg (I am lazy like that, and it works so why bother messing with it). I also have the Adobe Apps as separate installs, rather than one Uber one. With priorities set on them. This increases the overall time of the full install but decreases the GB used each time, as it puts the high priority ones in first, then has to wait for the next heartbeat to check for the next priority ones, and so on.

Q3 Again, here I have them all as separate policies. I did not believe they were actually using all of the Apps, so I accidentally failed to install some and strangely nobody asked to have most of them. But to answer your question it will work just fine. I use the same method to install all 800 or so of the Apple Loops for Logic. I grab their installer pkg files, and then throw them in folders of around 5Gb ish in size, usually up to 60 pkg's to make that. Then using each of these folders as a starting point I follow the same procedure. When the policy runs, the post install loop works its way through all of the pkg's it finds and installs them. It cleans up as it goes along.
You could build them as individuals, and then put them all in one policy as multiple payloads.

I have found a bunch of other installers that are also similarly challenged like the adobe ones, and this method works just fine with them too. Also like with the Logic installs, wrapping up 800 installers saves loads of searching through lists and lists to find an installer for a policy.

I used to Cache and then install, but as we are on prem Jamf, and our network can handle it, all of my policies are set to install. Its only when they all run the Apple or Adobe software updates that I cause network issues here now. The Distribution share points are all SMB shares, and they seem to handle the load quite well.

My post install script....
I use a variable for part of the location, when you work on loads of these you only need to put the name in once and the script then does all of the work. When setting it all up I keep to this one name for the folder and the archive etc.

# What file is being installed
csgfile="LivePacks_13"

# Uncompressing the Installers
# Move to location
cd /private/var/csg/Install/
# Uncompress the archive
tar -zxvf "$csgfile".tar.gz

# ---------------------------------------------------//------------------------------------------------------------

# Install the pkg files found in a temp location

for PKG in $(ls "/private/var/csg/Install/$csgfile/" | grep "pkg$")
do
/usr/sbin/installer -pkg /private/var/csg/Install/"$csgfile"/"$PKG" -tgt / -allowUntrusted
# Then it will remove the installers
rm -Rf /private/var/csg/Install/"$csgfile"/"$PKG"
done

# Remove the folder and the archive
rm -Rf /private/var/csg/Install/"$csgfile"
rm -Rf /private/var/csg/Install/"$csgfile".tar.gz

I have one of these tar.gz installers to put NoMAD and NoMAD login onto the Mac. It runs the installers, puts the images I want in place, and then the post install script also populates the plists with the correct information to allow NoMAD to work from the start. Its just a variation on the above post install script, with the addition of the list of defaults write commands to create the configured plist.