Automation of Adobe Creative Cloud Packages

At the 2017 MacAdmins Conference at Penn State University, Adobe recently announced some upcoming changes to their IT-focused packaging tools. Some of these changes will have a big effect on organizations using AutoPkg to automate the creation of Adobe packages.

A quick recap of the changes:

  1. A new admin console will be introduced later this year. Regardless of account status (Teams or Enterprise), companies will be slowly migrated over to this new unifying console. This is a welcome change for anyone who has had to deal with both the Team and Enterprise console. The only difference will be that certain features will be unavailable depending on the account your organization has.
  2. The new admin console introduces the same features that you find in the Creative Cloud Packager (CCP) as far as packaging is concerned. You will only be able to download installer packages that are utilizing the new Adobe installer technology. Note that by the time the admin console has been rolled out, all Adobe apps will be releasing with this new installer technology. I believe only 1-2 Adobe apps are not currently using the new installer technology as of this post.
  3. The CCP application will stop getting updates once the new admin console has been completely rolled out. This means that at some point it will stop working and you will need to rely on the admin console for downloading installer packages.
  4. The new admin console will be doing away with Serialized licensing. It currently supports Named User licensing and by the end of the migration to the new admin console will also have support for Device-based licensing.
  5. There is a feature in the works to allow you to block the latest versions of Adobe apps from being installed through the Creative Cloud Desktop App (CCDA). This is meant to appease admins who are concerned about compatibility issues created by newer Adobe app versions.
  6. All downloads of installer packages will include Remote Update Manager (RUM). No changes announced surrounding Adobe Update Software Server Tool or RUM.
  7. New notification options will appear in the new admin console.

The biggest concern for IT administrators is the deprecation of CCP which is being used for automating the creation of Adobe packages through AutoPkg. Adobe at this point in time does not have anything planned to fill this gap. Because they do not currently have any insight into how heavily this tool is being used, it is not a priority for them to have a viable automation-focused solution for IT administrators. In order to do so, they need feedback. I have two ideas that I think may help. But before I share those ideas, let me preface this with a concern that I think is being ignored here.

Despite the push by many software vendors to allow end-users to help themselves, very often IT departments are tasked with making sure tools are readily available on computers and that the end user only has to worry about using those tools they need for their job. That is to say, end users in many organizations should not have to spend time trying to figure out where they can get applications, what version they should be installing, how long an install will take, etc. In many cases this is a waste of time, resources, and money.

With the above concern in mind, here are two ideas for Adobe that might help automate deployment of Adobe apps as an IT admin.

  1. Create a RESTful API that would allow the downloading of Adobe packages. Through this API, we would be able to take the exact same steps we can take through the admin console which includes the ability to choose: Adobe app, app version, whether CCDA apps panel is available, whether CCDA has elevated permissions, whether RUM is pointing to an internal AUSST, etc. Adobe should hopefully be able to gain insight metrics on how heavily used this API is.
  2. Update RUM so that it can install and uninstall Adobe applications in addition to the ability to update within the same version. We should be able to specify the Adobe app and version number of what we want to install/uninstall/update.

Idea 1 would allow Mac administrators to use AutoPkg to automate the creation of new Adobe applications. Since the packages are automatically created (and potentially uploaded to the software repository for whatever deployment tool is in use), there is very little work for the administrator to do. That is the whole point of AutoPkg in the end.

Idea 2 comes in handy because you are only pushing out RUM (you’ll probably need to push out CCDA just to install RUM) which in turn you can then script around to install the Adobe applications you want. This comes in really handy if you are not keen on having to upload a lot of Adobe packages to your software deployment repository, but still want to ensure that the Adobe apps your end user needs are installed.

Just to reiterate, Adobe is NOT going to implement either of those ideas unless IT administrators reach out and request these features. It will be helpful if you include the size of your user installation base to provide them an idea of how many users/devices are impacted by this upcoming change. Reach out to your Adobe rep and/or go to the MacAdmins Slack and check out the #Adobe channel and email the address located in the Channel Topic section.

If you have better ideas, feel free to drop a comment below.

7/17/17 EDIT: There is one obvious idea that I did not propose because it just seems that Adobe will never go this route (at least not anytime soon). However, other Mac administrators have made the good point that we should always ask because otherwise we will never get what we want. The idea is dead simple: Adobe should make proper standard Apple packages with the full Adobe app bundle in  the package payload like most other installers. Last year, they did move to new installer technology as referenced earlier which is why I don’t see this happening anytime soon. But it would be great if they simply separated out the following components into proper Apple packages: Adobe application, Creative Cloud Desktop App, and RUM.

This would lessen the amount of work and logic that is often involved in trying to make sense of the Adobe packages with tools like AutoPkg and Munki. Further, by making standard packages they could easily be downloaded and made freely available. Why? Nowadays to use an Adobe application, you need a license. That means that if someone downloads the package and installs the Adobe app, they won’t be able to use it until they license it.

7/18/17 EDIT: A very good comment by @flammable on the MacAdmins Slack states: “what i’d really like: if adobe followed microsoft’s lead and provided sku-less installers for all of their products, from a freely downloadable website. they should be standard apple packages, with a real payload (not everything shoved into a posinstall script). if installed as-is, they would operate in named license mode, and require the user to login with their adobe ID. if installed in conjunction with a separate volume license package, the software would operate in serial/device license mode, and not prompt the user for their adobe ID (unless they want to sync their documents using creative cloud).” I don’t want to speak for all IT admins but they should be the dream. And just to add, Microsoft has been doing something really interesting to further push their customers away from volume licensing and toward Office 365 licensing. Office apps that are volume licensed actually have LESS features unlocked versus those using a 365 license. Adobe could do something similar. A little heavy handed perhaps, but it would at least keep serial licensing and named licensing co-existing in a future where Adobe currently wants to get rid of serial licensing altogether.

Advertisements

One thought on “Automation of Adobe Creative Cloud Packages

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s