Adobe Creative Cloud Deployment - Creative Solutions

[mallen13]

If you are reading this discussion, I'll assume you have fallen into one of Adobe's many pitfalls for rolling this out in an enterprise environment. I'll address some of the most common and head-scratching issues here, and will offer some creative work-arounds that have been very useful for me.

- You use an SMB distribution point
- Your package install fails for no good reason -- install.log is not helpful, and states "Contact Manufacturer"
- You want users to deploy from Self-Service
- You want users to be able to deploy off-network ( advanced )

1. SMB distribution point:

Yes, SMB is king of the hill. We know. Sorry AFP, you're just not common enough for the $$.
Though AFP may not suffer some of the issues we see on SMB distribution points, it remains less common in enterprise environments. Good thing apple decided to STOP making the Xserve right ?

As per Adobe: " The Creative Cloud Packager does not support NFS or SMB "
( http://helpx.adobe.com/creative-cloud/packager/creative-cloud-packager.html )

We can only assume this has to do with the wide variety of file 'modes' needing set for various steps of the deployment. I'm sure many of you have resorted to ' chmod -R 755 CC-installer.pkg ' on your packages.
So how do you work around this ? -- Wrap it in a DMG immediately after building the package with AdobeCCP
( look at: https://jamfnation.jamfsoftware.com/article.html?id=161 )

1. Your package install fails for no good reason

Most of the time when an Adobe install fails with the generic "Contact Manufacturer" error when running scripts,
it's because one or more of them have lost their execute flags. Using ' chmod -R 755 ' on your package WILL normally allow it to install, but it's really just a side-effect of the bigger issue: the file modes were jostled in the first place. (sometimes just COPYING the pkg will leave the necessary file modes out of whack on the destination.
Even from linux/mac <-> linux/mac via SCP...) If you built your PKG using the Adobe CCP tool, they should install without issue immediately after build.

1. You want users to be able to install via Self-Service

"OK. I used my mac to build the .PKG then immediately put it in a DMG. Now what ?"

In any scenario, pre-caching the DMG file makes good sense.
When you select 'ALL' Adobe CC apps, the package can grow to 20GB.

Kick off installation of the already-cached package via shell-script.
( see: https://jamfnation.jamfsoftware.com/viewProduct.html?id=3&view=scripts )

If you have the option, this is the best overall solution, and seems to work beautifully.

The faint of heart should stop reading here. -- for 99% of deployments, this is as messy as you'll want things to get.

If you are brave, and not afraid to get your hands dirty, read on.

1. You want users to be able to deploy off-network ( advanced )

In most instances, you can pre-cache a package, then have the user install it directly from Self Service.
Well, that would be great, but just dropping the installer.pkg on their Mac probably isn't much help if your users aren't admins.
Making a script 'available offline' doesn't necessarily fit the bill either.
In my experience, Self Service has no issues caching PACKAGES for offline install, but scripts often tend to fail when the distribution point is unavailable.

Food for thought: You could always wrap a shell-script inside a package. Composer makes this pretty effortless.
PROBLEM: If 'installer' is busy installing a .PKG that runs a shell-script, that tries to use installer to install another PKG, you will get nowhere. Installer needs to close one package to open the next. If your shell-script tries to start another instance of 'installer' your process comes to a dead halt.

e.g. Self-Service -> [ installer -> { shell-script -> installer } ] <--- halt. the first instance of installer can never finish.

workaround: Create LaunchDaemons to do the dirty work. Use your initial offline package to drop resources in place, then kick-off the next step.

e.g. Self-Service -> [ cached-package-A -> installer-A -> shell-script-A -> { LD ] -> [ shell-script-B -> installer-B,C,D,E,F,G ] }

All that make sense ? Good.

Here is how I've been handling our CC deployments. (things have been working surprisingly well)

- Policy to Cache DMG file and CC-Installer.pkg <- let cook for a while

- Separate Policy for Self-Service scoped to smart-group with criteria: must have DMG file and CC-Installer.pkg cached (The Self-Service package will install (and finish) within a few seconds, but it's only dropping the installer, not completing the actual CC deployment. So we are not relying on completion of this particular job to evaluate overall success. We're dropping our own receipt later.)

- The installation package immediately insists on a re-boot (triggered by shell-script-A embedded in resources package.) There are several reasons you might want to do this. In this case, we changed the sudoer timeout so sudo user notifications / other root-permissions would be available POST CC-install. The default super-user timeout is 15 minutes. If your Creative Cloud package installs inside of 15 minutes, you are one of the very lucky few. Our install times are ranging between 45 and 90 minutes.

* Please make sure you understand how sudoers work before messing with these settings. IT IS POSSIBLE to shoot yourself in the foot if you malform the sudoers file. Furthermore, consider best practices when even thinking about this. Avoid if possible.

- After re-boot, the first LD (set to run at start) kicks off shell-script-B

- Shell-script-B performs the following magic:

Notifies user: "Verifying Installation Files - Please wait" ( jamfHelper ) Verifies integrity of cached DMG file via MD5 checksum If fail: abort with message. If pass: Notifies user: "Install is happening - please do not interrupt" ( jamfHelper ) force-quits all adobe apps + the cc launcher panel / sync agents starts a second LD to watch for pass/fail receipts backs up plug-ins directories; uninstalls all CS5/6 apps; runs CS-suite cleanup tool uninstalling all CC/CC14 apps; runs CC cleanup tool Installs clean copy of CC suite migrates plugins directories to new homes drops current version of AdobeUpdater.Overrides reverts sudoer file to default timeout values once CC-package installation is finished, un-mounts and removes DMG file from 'WaitingRoom' drops completion receipt (*2nd LD produces completion message based on the outcome) <- we can report against this receipt in the JSS perform inventory -> send to JSS removes all LaunchDaemons + shell-scripts Notifies user: "OK. All done" ( jamfHelper )

So there you have it. It's a bit ugly, but we've had excellent success.
Using this ' [ package -> script -> { LD ] -> script } ' method has been extremely handy.
I'll reiterate: If you are able to do all of your deployments ON-network, you will certainly live a longer / happier life.

I'm happy to share all of these scripts / LDs for those that are interested.

[geoffreykobrien]

Awesome write up, we share a number of similarities in deployment methodology.

[donmontalvo]

LOL...I never noticed the NFS/SMB warning...or the warning not to install PKGs on Windows computers. :)

external image link

[acdesigntech]

Agreed, great writeup. Does anyone know if CC can co-exist with CS4 (weird question, I know. Hi, I work for a dinosaur :) ).

I've also run into the pitfall of scp/unix filesystem rules and using the zip binary on the Mac.

zipping the file and probably scping it, dittoing it, etc somehow break a lot of either sym links or permissions, or other nonsense Adobe uses on their installer package. The only foolproof method I've found is using CCP, then immediately wrapping the package in a dmg, NOT a zip, tar, rar, etc. for storage on a non-AFP volume.

[emily]

@acdesigntech I've found that users with older versions of Adobe apps get failure notifications when they try to run updates of the newer CC apps through the Creative Cloud app. It's been annoying. Fortunately they've all been okay with the solution of removing older versions and just using one version of each app on their computer.

We pretty much only deploy Adobe apps during imaging, and for that what we do is put the installers in a Self Service category that only Corp IT members can access with their login, then running the installers through Self Service as we're finishing configuring the machines. When we rolled out CC to users, we just used the invite system, had them enroll, and had them install what they wanted through the CC app. Fortunately for us, all Mac users are admins of their machines. So far this system as worked well.

I wish there was a good way to integrate the apps into a true imaging workflow, though. Has anyone found a way to get things installed during imaging using Casper imaging?

[Anonymous]

Great write-up will come in handy. The Adobe software is a beast to maintain.
generally all of our users are non-admins, and deploying and managing CS has been relatively good, but a lot of "why can't it just work this way..".
When we rolled out CC, all updates and notifications were turned off, the CC Desktop app was not installed, and we're going to start individually wrapping the CC Applications instead of an entire suite. So it may be a bit redundant then the way adobe does it, but it helps us keep everyone one the same version instead of updating and someone can't open up an adobe document because its .1 ahead of the other user...
So we've made an individual installer of Photoshop, Acrobat, Illustrator, etc...I like that modular approach as it helps (in my content mind) contain the beast that is Adobe installs. and if we need to remove a single app that may be causing an issue, we just deploy the uninstaller for that app itself and doesn't seem to muck with any other Adobe apps.

trying to keep as light or scalable as possible.

more ideas and workflows for Adobe CC is always welcome

[alanmcseveney]

InstallPKGfromDMG.sh solves all my CC deployment woes.

[#8]

Also, don't forget: http://helpx.adobe.com/creative-suite/kb/error-case-sensitive-drives-supported.html

Issue

When you try to install an Adobe product, you receive the message, "Case-sensitive drives not supported" in the Install Options panel. Or, you receive an error message such as the following:

File system of setup volume not supported.
This software cannot be installed because the file system of the OS volume is not supported.
Unsupported OS version.
Unsupported file system on system disk.

Solution

Install the product onto an HFS+ or HFSJ non-case-sensitive drive.

I ran into this while trying to apply Acrobat X1 updates..

[donmontalvo]

@alanmcseveney wrote:

InstallPKGfromDMG.sh solves all my CC deployment woes.

Same here, once we put all the stuff into DMGs, cached and triggered with this script, problems went away.

[mallen13]

emilykausalik : Installing at image-time is something I'm working on now.
I'll make sure to share my results (hopefully all positive) and will drop a link on this thread when it's working.

:-)

[cwaldrip]

Glad I'm not the only person sehttp://
eing oddity in deploying at image time. I built a Photoshop CC 2014 pkg using Adobe's Cloud Packager. Added it to my image config. Imaged a machine. No Photoshop. >:(

Looked in the logs...
[Installing Adobe Photoshop CC 2014.pkg...
Successfully installed Adobe Photoshop CC 2014.pkg
<snip>
Deleting user adobeinstall...
Deleting home directory for adobeinstall...](Installing Adobe Photoshop CC 2014.pkg...
Successfully installed Adobe Photoshop CC 2014.pkg
<snip>
Deleting user adobeinstall...
Deleting home directory for adobeinstall...)

Just no Photoshop 2014. :-

[RobertHammen]

What's your distribution point? A Mac (AFP) or a Linux or Windows box (SMB)? Or are you using http?

Do you have the installation package set to "install on boot drive after imaging"?

What do the installation logs in /Library/Logs/Adobe say?

[stevehahn]

I'm trying to figure out how we can manage preferences for Creative Cloud--specifically, we need the menu bar icon to go away and we need to turn off the notifications. I actually need to turn off Notification Center on these Macs anyway so I hope that would take care of the notification problem, but I'd still like to figure out ways to programmatically apply user preferences.

[Anonymous]

@stevehahn are you using Creative Cloud packager? What kind of preferences do you want disabled/enabled?

When using CC Packager, you have the options to disable the Desktop app (which is that menu bar icon), disable auto-updates or turn them off all together and just deploy updates conveniently for you.

external image link

then disable desktop app, notifications, etc
external image link

[cwaldrip]

@RobertHammen Sigh. I forgot to check "install on boot drive after imaging".

id10t error. :-)

[RobertHammen]

Why that option isn't automagically selected when you upload pkg/mpkg files via Casper Admin, I have no idea. Glad that worked.

[dferrara]

@randy Since you wrote this last year, how is the modular/lightweight approach working for you? I'm finding that installing the entire Creative Cloud just takes too long, even with a successful cache. Have you run into any licensing issues? Are you primarily using Device licenses, or Named User licenses too?

Cheers!

[Shane]

Hey everyone, Like to breath life back in to this thread. I am curious as well, I too went the individual apps route when I deployed CC2014. Used CCP to package everything individually. Wrapped all pkgs inside dmgs. Deployed via installpkgfromdmg.sh It has worked well having users install the apps from the suite that they needed. I then made a Self Service item called Update Creative Cloud apps that would recurr monthly. This was nothing more than a command to invoke RemoteUpdateManager. This has worked well.

Now, I have packaged the CC2015 apps in the same fashion and am ready to deploy. However, I want to remove the 2014 versions of the apps. No luck. I have tried uploading the VariousCCApp_uninstaller.pkg created by CCP. I have tried the same pkg wrapped in a dmg. Is there not a good way to remove these apps via a policy?

Ideally, a user goes to Self Service and clicks Install Photoshop CC 2015. In the background, Photoshop CC 2014 is immediately uninstalled, the 2015 dmg gets cached then the installpkgfromdmg.sh takes over and works it magic.

How are others accomplishing this?

Cheers and we will see you next week @ JNUC 2015

[stevewood]

@Shane in my testing, I've been able to simply upload the uninstall PKG without wrapping in a DMG and run that to remove the apps. I've been able to successfully remove the CC2014 app and install the CC2015 app in this way.

I'm running 9.73 with a JDS distro point running SMB/HTTPS and have never had to wrap my Adobe apps in a DMG to deploy.