Issues installing Adobe CC2015 via Casper

Hey @Mitch260488

See if you can get the install.log from the Console.app. That should have some more information for you/us.
Also, is this package what you created with Creative Cloud Packager (CCP) or with a snapshot from Composer?
If you used Composer, I doubt it will work due to Adobe's post-install scripts and licensing stuff.
However the packages from CCP can be dropped right into Casper Admin and used. And CCP will generate an uninstall package as well. It is, unfortunately, a separate package but it does work pretty well.

Hope that helps,
Jeff

@Mitch260488 Do you put all of the Adobe software via CCP into one package?

I recently created individual packages for all of the software based on some advice I had received from a video presentation. I've had nothing but problems where some of the installers seem to break and not install when I have a number of them inside a policy. I use to have one large installer that set inside a disk image as per Jamf's recommendations. This worked ok but seemed to be a slower process. The advice in the video was that by doing it individually handling updates would be easier.

@jhuls,
I too used to package it as a single package, but as CC continued to grow and the package got up to 30G, I looked for other ways. Uploading a 30G package through the JSS (ahem jamf pro) servers (Admin to Tomcat /temp to DB to JDS/File Dist. Servers) is painful.

Like you, I also found articles and videos about packaging them up individually. So that's what I do now.
Also, if you enable the Adobe Remote Update manager, you can invoke the updater from the command line and let it run on each machine. Having a local update server or caching server will reduce your bandwidth concerns. You do have to enable this in the CCP package but the good news is, if it is enabled for a single package, ALL CC applications can use it.

You could even make a Self Service install out of a script that invokes this! Pretty cool!
Adobe RUM

Jeff

This has always helped me:

[https://www.jamf.com/jamf-nation/articles/161/deploying-pkgs-created-with-aamee-or-creative-cloud-packager](link URL)

@jrippy I briefly looked at RUM but in the video I had watched they suggested not using it. I should hunt the video down and watch it again to clarify the reasons why. I believe one had to do with the software needing to be quit. I tested RUM briefly quite some time ago and wasn't thrilled with the lack of feedback to me or an enduser....unless there's a configuration I'm not familiar with. It also seemed a little more challenging if I only wanted to update certain Adobe applications. Have you ran into any of these challenges?

@chad.fox That's exactly the way I use to do it. It worked but felt slower. I also found that I couldn't use this method when I would image. With the software being so large, I'd like to include software like this in the imaging process. I've not placed the individual packages in my imaging workflow yet to test but that's the direction I want to go. I'd rather have the long wait for the original install there than later.

@Mitch260488

can you describe your install process. I recall seeing this error if Casper Remote was used with no one logged in. We mark it to be installed at reboot as per Jamf and have had no issues. As other have mentioned , we also package each app separately and use RUM

I have seen this were our SMB Distribution point was still mounted and the Adobe app would fail with that error, try after a fresh restart and see if it installs. I have added the command to all my CC policies sleep10; kdestroy -a

I have seen this were our SMB Distribution Point was still mounted and the Adobe policy would fail with that error, try after a fresh restart and see if it installs. I have added this command to all my CC policies sleep10; kdestroy -a

@Mhomar your stuttering. Hahaha

@Mitch260488 can you look at the install.log and see what's there during the failure. I've been fighting with a lot of inconsistent install failures across multiple packages and the install.log always cites one of these:

An error occurred while running scripts from the package…
or
An error occurred while extracting files from the package…