Adobe CC Revisited---sorry

CCP is certainly the proper packaging tool at this point. I think everyone has given up on even trying to package those crappy apps with Composer.

And for a sanity check, yes, they're huge packages and take a long time to install any with way. Best you can do is image/install across gigE end to end if possible, or maybe sync your DP to a FW or TB drive for local imaging/install.

If you need to get the apps installed on existing equipment in a hurry, what's the chance of turning it into a student run project and getting the students to do it?

In our environment we have chose to go the "Cache" direction, and have very few "Install" policies. Basically we cache all updates or new installations, and then have a weekly install all cached policy.
For Adobe, we use CCPLauncher to create the Adobe packages, then we make a Composer package with the Adobe package installing it to a /Library/caspersupport location (since we notoriously get errors if we try to cache the Adobe package directly). In the Composer package we have a Post Install script that then runs the installer, make aliases, deletes the /Library/caspersupport/Adobe package, etc. We then create a policy that caches the Composer package. Finally, we have a weekly (Thursday afternoon) log out policy that runs all cached packages. This has worked very well for Adobe installs and updates.

@mconners

I actually deploy the entire Adobe CC Suite 2014 as individual packages through Self-Service for our environment and dealt with a lot of headache figuring out how to do it. It's very similar to @ronb's method, but Ill list it in steps for you.

For the sake of this example, the name of my CC folder is going to be Photoshop.

Step 1: Build the install out like you normally would with the Adobe CCP tool, which should then export as a folder(Photoshop) with all the dependencies inside (Build, Photoshop.cc, Exceptions).

Step 2: Use composer to make a package that places that folder somewhere in the directory of your choosing(ex. Applications folder).

Step 3: Make a shell script that installs the PKG at "Photoshop/Build/Photoshop_Install.pkg", and add a line to remove the folder after the install. Make this a post-run script for your policy.

That's it. Took some time to make each one individually, but it was a lot faster and more reliable to download one Adobe application at a time, versus the entire suite for us in our environment. The users can que up which ones they want in self-service as well to have them just continue back to back.

Anyway, thats just my 2 cents and how we do it through Self-Service with policies.

+1 for Single Apps rather than using the Full CC Suite.

We deploy our apps from CCP as single installers directly though Self Service, it has been great.

What's the best way to deploy CC apps during imaging? I always have quirks using the 'install at reboot' checkbox in Casper Imaging. Can they be put down as part of the config or no?

I have thought of the self service except for one dilemma. We would be deploying to labs where students don't have access rights to download or install apps with their ID's. In a lab situation, I am dealing with several hundred deployments and I would like to make the installs uniform.

Self service wouldn't work too well I don't believe. Again, being new to Casper, there are a dozen ways to do the same thing, I'm trying to find a tried and true way. I know, it's Adobe. Thanks for the ideas and more are welcome.

I have CC install at imaging time, and it does take forever (usually around 45 min. on our network). For machines that are already imaged, it's in Self Service with a notice that it could take a long time.

If you wanted the install to happen when people aren't around, you could schedule it with Casper Remote or with a time restriction on the policy.

So bvrooman, are you installing the entire suite or apps from it?

I install via Self Service as well, and via policy if I need to push them to someone. All of my CC apps are single apps and not "suites" in the JSS. If I deploy to a user via policy I cache the installers first with one policy, and then trigger the install with a second policy. I've had much better luck deploying this way with all of the Adobe products, going back to CS4.

If these are lab computers, primarily, that you need to get CC onto, then I would probably schedule it for after hours. I can think of two ways to do that: 1) as a logout policy or 2) by setting the computers to wake in the middle of the night. Either way, I'd cache the installers I need to the machines, use a Smart Group to look for machines that have cached files, and then scope the second policy to that Smart Group with a trigger of Logout. When the machines get shut down, the policy will kick off. Each time I've had to upgrade our office (140+ machines) to the newest CS/CC suite this is how I've done it.

You absolutely have to package the apps individually. I can confirm from lots of testing that even though it would be great to be able to package our eight apps we support into one super package for the labs it just doesn't work.

I also always mention with anything Adobe that you will never want the previous version installed on the same machine. CS 5 to CS 6 was a nightmare for us because we didn't know this fun fact. Let me know if this works for you, if not I have some other more fine-tuned suggestions.

It's come to the point, where, due to Adobe's inconsistencies, that you have to package the applications from the Creative Cloud individually.

Example:

Adobe Dreamweaver CC 2014.1 cannot be installed via Remote Update Manager if you already have Adobe Dreamweaver CC 2014 installed. For some reason, it's considered a "new install" by Adobe, even though there are other applications, such as Photoshop and Illustrator that have been updated to versions 2014.1 and even 2014.2 by Remote Update Manager.

Unless you want to have Dreamweaver CC 2014 and CC 2014.1 installed at the same time and confuse your end users, you'll want to uninstall the old version when you push down the new one. However, if you built a "suite" of packages that are installed together, the uninstaller that is packaged up along with it will want to uninstall all of the applications that were deployed, not just Dreamweaver CC 2014. Therefore, the only true way, going forward, that you can guarantee to be able to only have the most recent versions of the Adobe applications on an end user's computer is to package and deploy them individually, so that you can uninstall and upgrade future releases as they become available without having to uninstall the entire suite of applications.

Did that make your head spin? Things are better with Adobe than they used to be, but its still not saying much. They're still not providing/building flat packages at this point, which complicates the deployment of these applications with Casper. I'm still doing double work by re-packaging packages to guarantee reliable deployments. It's kind of silly that we still need to do this legwork in the year 2015.

~Ted

@mconners][/url, because I'm apparently a masochist, I package them both separately and as one giant installer. :) Plus I make a separate package for updates to each.

The actual application/install policy that appears in Self Service for our users depends on the specific license that they purchase through our contract. The vast majority of people want, and purchase, everything; in those cases I deploy the whole 17GB installer mess. I've actually never had an install failure since I added one step to my workflow (before adding the package to Casper Admin):

chmod -R 777 */path/to/install.pkg*

For users who just buy a single license, like Photoshop or Acrobat, they are scoped to the appropriate app installer only. For some unknown reason those installers seem to work fine without the permission change.

To comment on @taugust04][/url's post, I generally use Casper to install an update-only package (appropriately scoped so it only tries to update applications that actually exist on the endpoint). In CCP you can uncheck the application itself but leave the updates checked - this is great for us because we can have a single group of updates that gets packaged, tested, and deployed all together, all at one time. The updates definitely need the permission fix though before being uploaded/deployed.

@taugust04 This is so helpful to know. I was going to package up the entire Adobe CC suite together. I didn't know there were issues with certain apps not being able to update to Adobe CC 2014 or 2104.1 or .2 or whatever they're at.

However, I thought that each installer comes with its own uninstall shortcut. I could be wrong on that though. So wouldn't you be able to simply call that uninstaller rather than uninstalling the full CC suite?

It looks very much like I'll package up the apps separately though just to play it safe....then package them up in one big PKG with a post script that calls each of those installers out individually and push that out via Casper. It's a little bit more leg work but it does sound like it'll make packaging the full CC a bit easier to troubleshoot in the future.

One other question, am I correct in assuming that Adobe CC needs to be installed while a user is logged in?

@bpavlov - as long as you choose not to install items that are considered exceptions, such as, Adobe AIR, a user does not need to be logged in for Adobe Creative Cloud to be installed. Adobe AIR is one of the handful of apps that I still capture and deploy with Composer to get around their horrible proprietary installer.

@bvrooman and others who install at image time, do the apps need to be installed 'at reboot' or can they be baked into the config installed while in Netboot? We are looking at having to reimage thousands of machines with various apps from the suite.

@CasperSally, from what I've read from others.. You still need to to install at restart.

@CasperSally Yes, Adobe CC still needs to be installed at reboot because the installers cannot be installed to any volume other than the current boot volume.

Funny thing is that it's such a simple fix for Adobe. When they trigger their installers, all they need to use is a built in variable instead of a /.

It appears that creating individual packages is the way to go. I was venturing down this path but wanted to confirm. So with these individual packages, are you simply putting each one as built by the creative cloud packager into Casper admin without any modifications or are you capturing the the installation using Composer for each application?

Just curious about how others have dealt with the Adobe packages. I want to be clear on what is, let's say, best working practice.

Thanks again!

I just got done doing this @mconners. The upfront legwork took a couple days but now that it is done users can pick and choose what they want from self service not a big lump of all the applications because they wanted Muse. Casper Admin zips the package and it deploys fine as is for me.

Ok, just to revive this thread, and ask a few more question:
How are you guys handling licensing for the CC Suite? Are you on a per user or per machine license, and how are you managing that?

Can you "cheat" like with prior versions of the CS apps and just have your initial image have the apps installed and already licensed before imaging (or re-imaging as the case may be)?

I currently have CS 5.5 (yes, it's that old), and I can deploy that on my front-loaded image (site licensed software. I really hate that you can't get a perpetual site license anymore). If I go forward with CC, I take it I'm going to have to add even more processes to wiping and re-imaging machines, yes?

You can get a licensed file, but you typically need 100+ CC seats for that to make economic sense. "Enterprise" licensing.

Otherwise you are using Creative Cloud for Teams, and the users must create/sign in with Adobe ID's that have been assigned the software by a Team Admin.

Just to add my 2¢ worth!

We have a site-wide Enterprise License.

We have approx 200 iMacs (plus unknown number of Windows PCs that I have nothing to do with) running the full CC suite! The last time I packaged this was late 2014 using CCP and we deploy as part of the imaging process with the 'install on boot drive after imaging' selected.

This has worked fine for us as we had time to image suites at the start of our school year (January) and so it wasn't an issue for it to take a while (3-4 hours for a lab of 20 iMacs).

However I am now in the position of having to update the CC suite for the start of next semester. Ideally I would want to do this without having to re-image the all our Macs again. So do I simply 'Edit' my original package and deploy that or is there some other way that I am missing. Am happy to start a new thread if this is getting off the original topic.

Not sure if I'm not just missing something in the scenario Alan, but...

I would think you would just use the Creative Cloud app or if you have the Enterprise Dashboard, see what updates are available to what you have deployed. You can then use CCP and package up those updates only.

From there make a new "Update" Casper policy with that package, and scope it appropriately.

Hi Ron, thanks for your reply.

We don't use the Creative Cloud app, nor do we use the Enterprise Dashboard. To be honest I'm not entirely sure what either of these are.

I use the Creative Cloud for Enterprise part of the Creative Cloud Packager, which gives me 3 options:
1. Create Package
2. Edit Package
3. Create License File

I've done a bit more thinking and researching and have come up with what I believe to be a couple of options.

Option A) Run the Uninstall package that gets created as part of the original packaging and then deploy the new fully updated package created with the 'Edit Package' option

Option B) With 'Create Package' I can just select the 'updates' by clicking on each app available and see what updates are available and select them and then Build the package from that. So if I deploy that package, then I'm hoping it will simply update the existing apps in situ!