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 )
- 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 )
- 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.
- 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.
- 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.
).