foigus' Notes

Mostly OS X Admin Related

Tag Archives: creative cloud packager

Blinded me with Silence: Adobe and the End of the Dolby License

Recently Adobe ended a licensing agreement with Dolby, “moving to native Operating System (OS) support for Dolby Digital decoding (reading Dolby files) and…no longer provid[es] support for encoding (writing) Dolby Digital and Dolby Digital Plus sound formats in the current and future releases of Creative Cloud.”  Adobe will now rely on native OS decoding of Dolby media for playback (supported by OS X 10.11+ or Windows 8.1+) and the ability to create Dolby media will be removed. As a result some versions of some Creative Cloud software titles are no longer available, and as of November 3, 2017 the following professional titles are affected:

  • After Effects CC 2015.3 and 2017
  • Audition CC 2014, 2015, 2015.2, and 2017
  • Media Encoder CC 2014, 2015, 2015.3, and 2017
  • Prelude CC 2014, 2015, 2015.4, and 2017
  • Premiere Pro CC 2014, 2015, 2015.3, and 2017

These titles are no longer available for Enterprise packaging via the Creative Cloud Packager or the Admin Console Cloud Packager. The CC 2017 versions of the applications do seem to be available via the Creative Cloud Desktop App (CCDA), however these CC 2017 titles appear to have been revised to no longer include Dolby software.

This change may create issues for customers–if a package for an appropriate version of a particular title has not been previously built (i.e. from either the Creative Cloud Packager or the Admin Console Cloud Packager), it may not be possible to install that software. This complicates both new installations (such as installing the software on additional computers) and reinstallation (such as during troubleshooting or computer rebuild situations). Beyond this, if the CCDA is used to install newer versions of software, the default setting is to remove previous versions of that software title. It is reasonable that a later version of a piece of software would be installed for testing, however if issues were discovered it would be impossible to reinstall the earlier version and be able to access the full features of that previous version.

Regarding software installation, if it’s not possible to build the software installation packages required by your organization the only option is to reach out to Adobe support and request assistance.

Also note that if it’s not possible to build an installation package for a title, it’s also not possible to build an uninstallation package for that title. There are a few options for uninstallation:

  • Software can be uninstalled by hand using the GUI uninstaller–although it doesn’t scale well, it is an option
  • If the original uninstallation package (created when the installation package was created) is available, this would also work to uninstall the software
  • If the title to be uninstalled uses a new-style “HyperDrive” package (“HyperDrive” package titles listed here) it is possible to uninstall the software via the command line
  • The CC Cleaner Tool may be used to generate an XML file to uninstall software using the CC Cleaner Tool binary. Note the CC Cleaner Tool is a command-line binary plus a configuration file that needs to be generated on a computer that has the software installed that is wished to be removed. The CC Cleaner Tool is not a traditional macOS installation package and will require being integrated into a package to be used with most management systems. Also note it appears it is not possible to silently uninstall “all” products and suppress the CC Cleaner Tool EULA–all products that are desired to be uninstalled will need to be noted in “cleanup.xml” in order to bypass the EULA
  • It may be possible to build a CCP “Uninstall ‘Package'” and modify the “AdobeCCUninstallerConfig.xml” configuration file to add additional products to uninstall. Note a CCP “Uninstall ‘Package'” is a command-line binary plus a generated configuration file–it is not a traditional macOS installation package and will require being integrated into a package to be used. Also note software installed using the older Adobe “RIBS”-based packages require “SapCode”, “Version”, “Leid”, “Platform”, “mediaSignature”, and “adobeCode” information in order to be successfully uninstalled. Obtaining this information will likely will require the assistance of Adobe support, and modifying a CCP “Uninstall ‘Package'” should be evaluated after trying the above CC Cleaner Tool option
  • It also may be possible to contact Adobe support and ask to be provided the proper uninstall package

These installation changes due to shifting licensing are unfortunate, since it shifts a potentially significant burden onto the IT administrator. Hopefully in the future Adobe’s licensing folks will work with the Enterprise IT folks in order to have a smoother transition with additional documentation.

Adobe Package Expiration

Update, 3/9/2017: Adobe has posted another KBase article about this.  Notably Adobe has re-signed Lightroom 4, Lightroom 5, and Scout.  Thanks to Graham R Pugh for passing this article along.

Update, 11:30 a.m. CST, 2/24/2017: Adobe has posted a KBase article about this and how it relates to Acrobat. Thanks to Blake Garner for letting me know. I’ve used the information in that article to update the list of affected Acrobat package revisions.

On February 21, 2017 at 1:42 p.m. CST a certificate used to sign some of Adobe’s older software titles expired. This causes some Adobe packages to fail–specifically packages that are, at their core, Apple-standard packages. These titles include the following:

  • Acrobat Pro DC Classic updates before 15.006.30198 15.006.30173
  • Acrobat Pro DC Continuous updates before 15.017.20050 15.016.20041
  • Acrobat Pro XI updates before 11.0.17
  • Acrobat Reader DC Classic updates before 15.006.30172
  • Acrobat Reader DC Continuous updates before 15.016.20039
  • Acrobat Reader XI updates before 11.0.17
  • Edge Code .98
  • Edge Inspect 1.5.486
  • Edge Reflow .51
  • Lightroom 5
  • Muse CC 2014.2.1
  • Muse CC 2014.3.2.11
  • Scout 1.1.3

While administrators may not intentionally be installing the non-Acrobat titles any more, there definitely can be forgotten titles included in long-ago created Creative Cloud Packager (CCP) packages. If macOS rejects a package due to an expired signing certificate, it will cause the entire CCP package to fail and no software will be installed.

Curiously the Acrobat packages newer than the above affected versions are signed with the same expired certificate as the earlier packages, but still pass macOS’s security muster. It is unknown why this is the case.

Rejected Adobe signing certificate:


Accepted Adobe signing certificate:


Apple packages embedded in a CCP package can be found with “find”:

$ find "lightroom_5_namedlicense/Build/lightroom_5_namedlicense_Install.pkg/Contents" -name "*.pkg"
lightroom_5_namedlicense/Build/lightroom_5_namedlicense_Install.pkg/Contents/Resources/Setup/LTRM5.6en_US/Adobe Photoshop Lightroom 5.pkg

Once found, the embedded packages can be checked one of two ways:

  • By opening the embedded package in Installer and clicking the (sometimes invisible) padlock in the upper right-hand corner. Problematic packages will have their certificate marked as “This certificate has expired” (pictured above with the Acrobat Pro XI 11.0.10 Updater)
  • By using the “pkgutil –check-signature” command. Problematic packages will be noted as “Status: signed by a certificate that has since expired” rather than “Status: signed by a certificate trusted by Mac OS X”:
$ pkgutil --check-signature "lightroom_5_namedlicense/Build/lightroom_5_namedlicense_Install.pkg/Contents/Resources/Setup/LTRM5.6en_US/Adobe Photoshop Lightroom 5.pkg"
Package "Adobe Photoshop Lightroom 5.pkg":
 Status: signed by a certificate that has since expired
 Certificate Chain:
 1. Developer ID Installer: Adobe Systems, Inc.
 SHA1 fingerprint: 9D 75 C9 20 01 4A 65 04 94 A7 63 95 E3 91 93 47 04 E8 57 DF
 2. Developer ID Certification Authority
 SHA1 fingerprint: 3B 16 6C 3B 7D C4 B7 51 C9 FE 2A FA B9 13 56 41 E3 88 E1 86
 3. Apple Root CA
 SHA1 fingerprint: 61 1E 5B 66 2C 59 3A 08 FF 58 D1 4A E2 24 52 D1 98 DF 6C 60

I believe Adobe’s response to this issue will be one of the following:

  • “Do not use the affected packages. They are old and have been supplanted by newer technology.”  This response works for Scout, Edge Code, and other non-Acrobat packages
  • “Migrate to the newest version of the affected software.” This response works for Acrobat and Lightroom packages

Options to handle this issue include:

To expand and flatten a package to remove the digital signature:

  • First let’s verify the package doesn’t install properly
$ sudo installer -pkg "/Users/admin/Desktop/lightroom_5_namedlicense/Build/lightroom_5_namedlicense_Install.pkg" -target / 
installer: Package name is lightroom_5_namedlicense
installer: Installing at base path /
installer: The install failed (The Installer encountered an error that caused the installation to fail. Contact the software manufacturer for assistance.)
  • Then locate the embedded Apple package using the “find” command above
$ find "/Users/admin/Desktop/lightroom_5_namedlicense/Build/lightroom_5_namedlicense_Install.pkg/Contents" -iname "*.pkg"
/Users/admin/Desktop/lightroom_5_namedlicense/Build/lightroom_5_namedlicense_Install.pkg/Contents/Resources/Setup/LTRM5.6en_US/Adobe Photoshop Lightroom 5.pkg
  • And we can verify the signature is expired
$ pkgutil --check-signature "/Users/admin/Desktop/lightroom_5_namedlicense/Build/lightroom_5_namedlicense_Install.pkg/Contents/Resources/Setup/LTRM5.6en_US/Adobe Photoshop Lightroom 5.pkg"
Package "Adobe Photoshop Lightroom 5.pkg":
 Status: signed by a certificate that has since expired
 Certificate Chain:
 1. Developer ID Installer: Adobe Systems, Inc.
 SHA1 fingerprint: 9D 75 C9 20 01 4A 65 04 94 A7 63 95 E3 91 93 47 04 E8 57 DF
 2. Developer ID Certification Authority
 SHA1 fingerprint: 3B 16 6C 3B 7D C4 B7 51 C9 FE 2A FA B9 13 56 41 E3 88 E1 86
 3. Apple Root CA
 SHA1 fingerprint: 61 1E 5B 66 2C 59 3A 08 FF 58 D1 4A E2 24 52 D1 98 DF 6C 60

  • We can use “pkgutil” to “expand” the package
$ pkgutil --expand "/Users/admin/Desktop/lightroom_5_namedlicense/Build/lightroom_5_namedlicense_Install.pkg/Contents/Resources/Setup/LTRM5.6en_US/Adobe Photoshop Lightroom 5.pkg" "/tmp/Adobe Photoshop Lightroom 5.pkg"
  • And delete the original, expired package
$ rm -rf "/Users/admin/Desktop/lightroom_5_namedlicense/Build/lightroom_5_namedlicense_Install.pkg/Contents/Resources/Setup/LTRM5.6en_US/Adobe Photoshop Lightroom 5.pkg"
  • “Flatten” the expanded package with “pkgutil” back to the location of the original
$ pkgutil --flatten "/tmp/Adobe Photoshop Lightroom 5.pkg" "/Users/admin/Desktop/lightroom_5_namedlicense/Build/lightroom_5_namedlicense_Install.pkg/Contents/Resources/Setup/LTRM5.6en_US/Adobe Photoshop Lightroom 5.pkg"
  • We can now check the embedded package is no longer signed
$ pkgutil --check-signature "/Users/admin/Desktop/lightroom_5_namedlicense/Build/lightroom_5_namedlicense_Install.pkg/Contents/Resources/Setup/LTRM5.6en_US/Adobe Photoshop Lightroom 5.pkg"
Package "Adobe Photoshop Lightroom 5.pkg":
 Status: no signature
  • Then test the edited package
$ sudo installer -pkg "/Users/admin/Desktop/lightroom_5_namedlicense/Build/lightroom_5_namedlicense_Install.pkg" -target / 
installer: Package name is lightroom_5_namedlicense
installer: Installing at base path /
installer: The install was successful.

Packaging Adobe Rapid Release Updates With CCP or AAMEE

Recently I was presented with an Adobe Rapid Release update and requested to install it on a handful of computers.  Adobe’s Rapid Release program provides access to betas and hotfixes for Adobe products (as opposed to a rapid release schedule such as Firefox’s).  Rapid Release installers:

The Rapid Release update was provided on a dmg in a double-clickable “” format, which doesn’t play well with software distribution systems.  Since the Rapid Release update isn’t available through any of the normal channels, I reached out to Adobe_ITToolkit via Twitter and asked what I could do with the update.  The response was:

If it is an update to an existing major version it should work via the Offline media workflow.

The “Offline Media” workflow is generally intended for situations where bandwidth is limited, but in this case it can be used to package updates that would otherwise not be available.  The procedure to package the update:


  • Disconnect the computer where AAMEE is installed from the Internet (see note following step 15 on page 34, which explains that preference will always be given to updates from the Internet)
  • Open AAMEE
  • Click “New Update Package”
  • Give the package a name and a location to be saved
  • The check for updates will fail (“The update server is not responding”)–click “Continue”
  • Click “Add Update”
  • Navigate to the update dmg and click “Open”
  • Proceed normally with packaging the update


  • Open CCP
  • Navigate to the point where “Applications & Updates” are offered (there’s so many different workflows to reach this point I doubt I can cover them all)
  • Click “Add Offline Media”
  • Click the folder icon to browse for the update dmg
  • Navigate to the parent folder for the update dmg and click “Open” (No, the dmg is not directly selectable. No, I don’t know why)
  • Click “Extract”
  • Confirm the desired update appears in the lower portion of the “Add Offline Media” window and is checked
  • Click “Done”
  • Confirm the desired update appears in the “Applications & Updates” list and is checked (note this may require clicking “Show archived versions”)
  • Proceed normally with packaging the update

Then import the AAMEE/CCP pkg into your favorite software distribution system and install.

Thanks to the folks behind the Adobe_ITToolkit Twitter account for pointing me in the right direction.

Distributing Adobe CC 2014 via Munki

Continuing on the theme of packaging Adobe Creative Cloud (CC) 2014, let’s examine using Munki to deploy the software to computers.

Import and Prepping for Uninstallation
Munki’s preliminary CC 2014 support
Munki added initial explicit Creative Cloud (CC) support recently, adding the ability to specify a Creative Cloud Packager (CCP) uninstall pkg for removing the software. When importing the CCP package it’s important to specify the CCP uninstall pkg:

munkiimport /path/to/CCP_Install.pkg --uninstallerpkg /path/to/CCP_Uninstall.pkg

“version” keys in pkginfo files versus reality
When importing CCP pkgs, pay close attention to the version numbers that munkiimport determines and check to see if they correspond to what’s actually installed by the pkg. Updates baked into the original CCP pkg may not be recognized by munkiimport–for example, if InDesign CC 2014 with today’s most current update is imported, munkiimport suggests version “10.0” rather than the actually installed version of “”. There’s no way to know exactly what software version is installed (CCP simply mentions “updates” and doesn’t give version numbers) without installing the CCP pkg.  Once the software is installed, either examine the application by selecting it in the Finder than then choosing File -> Get Info (or use makepkginfo–see the makepkginfo example under the “Installs arrays” heading below).  When the software version is determined, editing the “version” key in the pkginfo file to reflect reality should help reduce confusion.

I set “autoremove” to “true” in the pkginfo for each CCP pkg I imported.  Although this is likely organization-dependent, the need to be able to move software licenses from one computer to another made automatic removal the prudent choice.

Installs arrays
Providing an installs array allows Munki to more easily determine whether to software installation is necessary rather than depending on the Adobe uninstall databases.  Leaning on the documentation on this page in the Munki wiki (under the text that says “You can manually generate items to add…”), this could be used for InDesign CC 2014:

makepkginfo -f "/Applications/Adobe InDesign CC 2014/Adobe InDesign CC"

And then copy and paste the installs array into the associated pkginfo.  However there are some instances where CCP pkgs need some extra attention:

  • There seem to be a set of unusual pkgs (typically CC titles initially released in the last few years, such as Lightroom and the Edge series of applications) where CCP wraps a pkg around an Adobe installer which is itself a wrapper around a pkg.  munkiimport currently is not able to determine receipts or installs arrays for this software, and thus managedsoftwareupdate considers them always installed and never attempts installation. If any of these pkgs are encountered, install the CCP pkg by hand and generate the installs array.  For example, install Edge Reflow CC and then run:
    makepkginfo -f "/Applications/Adobe Edge Reflow"

    Copy the installs array into the pkginfo for the Munki installer item.  Once a usable installs array is added to the pkginfo file, managedsoftwareupdate will properly evaluate the installation status of the installer item.

  • Edge Code CC includes extraneous information in all of its version keys. In this situation the best option I’m aware of is a MD5 hash of the Edge Code CC executable itself:
    makepkginfo -f "/Applications/Adobe Edge Code"
  • Gaming SDK doesn’t install anything that’s usable for Munki to evaluate for versions. In this case, have makepkginfo evaluate the pkg located inside the CCP pkg:
    makepkginfo "/path/to/GamingSDK_Install.pkg/Contents/Resources/Setup/GSDK1.4en_US/Adobe Gaming SDK 1.4.pkg"

    And include the receipts array in the Gaming SDK pkginfo.

When uninstallation is known to not work
Even with CCP uninstallation pkg support built into Munki, there are multiple CC applications that cannot be uninstalled using their CCP uninstall pkg. Under “Known behavior and issues” in the “Version 1.3” section of the Creative Cloud Packager Readme, there’s documentation about uninstallation of various applications failing.  For Munki, the solution is to use an uninstall_method of uninstall_script (rather than “AdobeCCPUninstaller” that’s generated by importing a CCP uninstallerpkg) which removes the application and the receipt, if installed.  The applications, deletion paths, receipts, and links to Adobe’s support saying this is a proper uninstallation (if I can find it) are below:

  • Edge Code Preview CC
    Path: “/Applications/Adobe Edge Code”
    Receipt: com.adobe.EdgeCode
  • Edge Inspect CC
    Path: “/Applications/Adobe Edge Inspect”
    Receipt 1: com.adobe.shadow.pkg
    Receipt 2: com.adobe.shadow.postflight.pkg
  • Edge Reflow Preview CC
    Path: “/Applications/Adobe Edge Reflow”
    Receipt: com.adobe.pkg.Reflow
  • Gaming SDK
    Path: “/Applications/Adobe Gaming SDK 1.4”
    Receipt: com.adobe.AdobeGamingSDK1.4.pkg
  • Lightroom 5 (Note the CCP uninstaller pkg works if a user is logged in)
    Path: “/Applications/Adobe Photoshop Lightroom”
    Receipt: com.adobe.Lightroom5
  • Muse (Note the CCP uninstaller pkg works if a user is logged in)
    Path 1: “/Applications/Adobe Muse CC 2014”
    Path 2: “/Library/Application Support/Adobe/Uninstall/Uninstall Adobe Muse CC”
    Receipt: com.adobe.adobeMuseCc20142.AdobeMuseCC.pkg
  • Scout CC
    Path: “/Applications/Adobe Scout”
    Receipt: com.adobe.pkg.Scout

An example uninstall_script for Edge Reflow CC would be:

pathToDelete="/Applications/Adobe Edge Reflow"
rm -rf "${pathToDelete}"
pkgutil --forget "${receipt}"

While the installation of the serial number pkg is relatively straightforward, the uninstallation is not. Since the same serial number potentially could be used to serialize different suites, automatically removing a serial number when a particular software title is uninstalled isn’t a given.  Consider a situation where Premiere and InCopy are installed on the same computer. Per discussions with Adobe support, both Premiere and InCopy need to use the same volume serial number when installed together on the same computer.  The following could occur:

  1. Premiere is installed
  2. Premiere is serialized
  3. InCopy is installed
  4. InCopy is serialized
  5. InCopy is uninstalled
  6. InCopy is unserialized

Following the unserialization of InCopy, Premiere won’t run since Premiere and InCopy share the same serial number.  There needs to be a way to determine at uninstallation time if another installed program or suite depends on the same serial number. In the earlier post about packaging Adobe CC 2014 applications, I created serialization pkgs with the following Package IDs:


Munki’s preuninstall_script can unserialize the software, and then a “removepackages” uninstallation method works to remove the serialization file themselves.  To remove the volume serial number only when appropriate, a preuninstall_script such as the following can check for additional receipts to determine whether the serial number is in use by an additional pkg:

#Location of unserialization utility
unserializer="/Library/Adobe Licensing/Adobe InCopy CC Serial - Video Serial Number/RemoveVolumeSerial"

#If more than one installed pkg is using the Video Serial Number
if [ `pkgutil --pkgs=com\.organization\..+VideoSerialNumber | wc -l` -gt 1 ]
#Another software installation is using this serial number, do not unserialize
  echo Receipts found that use the serial number, not unserializing
  exit 0
#We're the last one out, unserialize and turn out the lights
  echo No other serialization receipts found, unserializing

Setting “autoremove” to true for the pkginfo for the serialization pkg causes the serialization to be removed when not intentionally installed on a computer.

Controlling serialized versus unserialized installation
Gathering the individual-title CCP software packages is a good use of Munki’s included_manifest feature. This allows for multiple CCP pkgs (or other pkgs) to all be installed as one collection of software.  An example included manifest named “included-adobe-CompleteCC2014” could include (in part):


Attaching licenses to software is a bit more of a challenge–sometimes we do want the serialization to occur, other times we don’t. There are two ways I can see to handle this:

  • Add both the included_manifest for the software installation and a managed_install for the serialization pkg to the computer’s manifest (e.g. included_manifest of “included-adobe-CompleteCC2014” and a managed_install of “AdobeCCCompleteSerial-VideoSerialNumber”). This requires adding two separate installer items for each serialized installation.
  • Set up the “requires” array in the serialization pkg’s pkginfo to require all the software that’s intended to be serialized (e.g. set up the pkginfo for “AdobeCCCompleteSerial-VideoSerialNumber” to “require” the software that’s intended to be serialized).  This requires adding only a single installer item for a serialized installation.

I chose the latter and went a step further–since I didn’t want an included_manifest for an unserialized installation and a managed_install for a serialized installation, I created an included_manifest that only included the serialization pkg (thus a manifest named “included-adobe-CompleteCC2014” and a manifest named “included-adobe-CompleteCC2014Serialized” exist). It adds a level of indirection, but keeps things more consistent since all software installations and removals occur within included_manifests.  Thus the following workflow is possible:

  • Munki client needs InCopy, but does not need a serial number
    • Client manifest has “included-adobe-InCopyCC2014” manifest added to its included_manifests array
      • manifest “included-adobe-InCopyCC2014” has managed_install of “InCopyCC2014”
    • Munki client installs InCopy
  • The same Munki client needs CC Complete, but does not need a serial number
    • Client manifest has “included-adobe-CompleteCC2014” manifest added to its included_manifests array
      • manifest “included-adobe-CompleteCC2014” has managed_installs for CC Complete 2014 software
    • Munki client installs CC Complete 2014 software
  • The same Munki client needs a serial number for InCopy CC 2014 and CC Complete 2014
    • Client manifest has “included-adobe-InCopyCC2014” and “included-adobe-CompleteCC2014” manifests removed from its included_manifests array and “included-adobe-InCopyCC2014Serialized” and “included-adobe-CompleteCC2014Serialized” manifests added to its included_manifests array
      • manifest “included-adobe-InCopyCC2014Serialized” has managed_install of “AdobeInCopyCCSerial-VideoSerialNumber”
        • pkginfo for “AdobeInCopyCCSerial-VideoSerialNumber” “requires” “InCopyCC2014”
      • manifest “included-adobe-CompleteCC2014Serialized” has managed_install of “AdobeCCCompleteSerial-VideoSerialNumber”
        • pkginfo for “AdobeCCCompleteSerial-VideoSerialNumber” “requires” CC Complete 2014 software
    • Munki client determines InCopy CC 2014 and CC Complete 2014 software are already installed.  Munki client installs both serialization pkgs for InCopy CC 2014 and CC Complete 2014
  • The same Munki client no longer needs CC Complete 2014
    • Client manifest has “included-adobe-CompleteCC2014Serialized” manifest removed from its included_manifests array (leaving “included-adobe-InCopyCC2014Serialized” manifest in the included_manifests array)
    • Munki client uninstalls CC Complete 2014 software
    • Munki client uninstalls managed_install “AdobeCCCompleteSerial-VideoSerialNumber”, however serial number is not actually removed since  “AdobeInCopyCCSerial-VideoSerialNumber” is installed
    • Munki client is left with a serialized installation of InCopy CC 2014


Packaging Adobe CC 2014 Applications

While packaging the various Adobe Creative Cloud (CC) 2014 applications I collected some tidbits of information.  Hopefully they’ll be useful to others.

Flexibility with installing combinations of software, including combinations that are not currently part of our purchased licenses
Tomorrow a Photoshop-Lightroom bundle could be purchased, or even a bundle that doesn’t exist today.  I want to be ready to support current and future software combinations with minimal rework.

Support for CC “non-Complete” suites
Enterprise CC licensing does not necessarily mirror the consumer and Teams “Complete” and “Single App” licensing. Licensing can be for non-Complete suites, for example mimicking the “Design Standard” or “Design and Web Premium” suites of the CS6 era.

Conversion of CC application licensing between unserialized (authenticated) and serialized licenses without uninstallation and reinstallation
Serialized installation is available for Enterprise CC licenses (and possibly some other CC license types). It comes with the advantage of not requiring sign-in to use the software, but the limitation of being unable to access Adobe’s cloud-based services and not being able to easily install CC software on a home computer.  We support a significant number of walkup Macs for intermittent use by a variety of independent contractors and temporary employees, and using authentication-based software (such as CC or Office 365-licensed Office 2011) on these computers does not provide for a smooth user experience.  Nor is it reasonable to authorize and deauthorize Adobe CC license entitlements for these users. Thus a method of serializing and unserializing CC software without having to uninstall and reinstall it is necessary.

Software serial numbers do not necessarily match up to licenses
The serial numbers provided are not aligned with the software licenses purchased, meaning a particular serial number may be used across multiple CC licenses. For example, installing both InCopy CC and CC video applications requires using the same serial number for both InCopy and the video applications.  A software license may be unassigned from a computer and the software uninstalled (such as InCopy in the previous example), but the serial number needs to remain to keep other installed software serialized. Only the last removed piece of software with a particular serial number should actually remove the serial number.

CC application marketing version numbers do not match their actual version numbers
During the Creative Suite (CS) era the release timing of programs marched in lockstep–a boxed CS release nearly always included a new x.0 version of each application. This is not true for CC–for example when CC updates were released on October 6 2014, Dreamweaver CC 2014.1 (version 15.0) was a completely separate application that installed alongside Dreamweaver CC 2014 (version 14.x).  However Photoshop CC 2014.2 (version 15.2) was an update to Photoshop CC 2014 (version 15.0).  Thus it’s no longer safe to assume the marketing-named something-dot-number (e.g. CC 2014.1) releases are going to be updates–they could be completely new versions. Start with this link to get an overview, but pay special attention to the actual version numbers of the applications installed.

Installing Creative Cloud Packager (CCP)
Downloading CCP from Adobe can prove challenging, since CCP isn’t provided outside of a CC agreement. Adobe’s notes on the subject are here, under the heading “Where do I download Creative Cloud Packager?”  If you don’t have access to CCP, contact your Adobe or internal organization CC representative for access through the Adobe Enterprise Dashboard or If your organization doesn’t have a CC agreement, see if an Adobe representative might be able to grant access.

“Named User” CCP packages
If available under your CC license, a “Named User” installation provides the most flexibility as it does not contain a license and thus functions as a trial installation. A “Named User” installation of a CC application demands authentication from a CC-authorized Adobe ID (or SAML-based authentication when available). The “Named User” installation can be serialized (and unserialized) with the “Create License File” option in CCP. However note I can only speak to the CC for Enterprise plan–other plans (education, teams) might not be able to convert a trial to a licensed installation. Consult with appropriate Adobe contacts for more information.

Create a separate CCP packages for each application
When creating CCP packages multiple applications can be included in a single pkg. While convenient to only have to install one pkg, there are a few considerations:

  • If applications A, B, C, and D are packaged together and in the future only A, or B and C, or B and D, or some other combination is needed (due to new single application CC licenses or just the desire to use less disk space), new CCP pkgs will be necessary
  • Related to the above, if multiple applications are packaged via CCP the associated uninstallation pkgs will uninstall multiple applications
  • It’s more straightforward to tie future CCP “update” packages* to single application CCP pkgs, rather than a combination pkg where the included applications aren’t as clear

*CCP supports an “update-only” pkg, which only installs an application update such as Photoshop 2014.2.1 (version 15.2.1). To create one of these, only check the update when building the pkg.  Note that update-only pkgs do not generate an uninstall pkg and rely on the uninstaller from the original CCP pkg.

Unless it’s anticipated an organization will never need to change its CC installation strategy it’s better to build in the flexibility at the beginning. Let a software distribution system handle bundling application installations. Note it is against the license agreement to split a “suite” license up by installing parts of the suite on multiple computers (although this only comes into play with serialized installations of CC). It is a license violation to install Photoshop on one computer, InDesign on another computer, and Illustrator on another computer and consider it one “Complete” license. In this case, those three installations would consume three licenses.

Since CCP caches software installers once downloaded, it might be a good idea to build a pkg all available CC software first and then build each individual pkg.  Once CCP caches the software, subsequent pkgs are created much more quickly.

Serialization pkg
Since there’s a need to serialize and unserialize applications, a serialization pkg is needed. This is one place where CCP requires more work since CCP doesn’t output a pkg but rather a collection of command-line tools. And since serialization will need to be removed, there will need a plan to unserialize as well.  The CCP-output serialization includes four files:

  • AdobeSerialization
  • RemoveVolumeSerial
  • helper.bin
  • prov.xml

If AdobeSerialization is run (with administrative privileges) it will look for a provisioning file (prov.xml) in the same directory as the AdobeSerialization binary.  If found, the serial number will be applied. If RemoveVolumeSerial is run volume serial numbers will be removed, but note this may include volume serial numbers for other products beyond what’s included in prov.xml. Additionally, Adobe support indicated that if additional CC products are installed that use the same serial number (e.g. adding InCopy to an already-serialized suite of video applications) AdobeSerialization will need to be re-run.

Given all of this, here’s the structure of my serialization pkgs:

  • Use a Package ID that includes the name of the actual serial number being used (the reasoning for the latter part of the naming requirement will become clearer in the Munki-focused CCP post).
  • Install all CCP-generated serialization files to a common directory
  • Name this common directory for the software being serialized
  • During pkg installation, run a postflight script that runs “AdobeSerialization” from the directory where AdobeSerialization is installed

A couple examples:

  • pkg: Adobe CC Complete Serial – Video Serial Number
  • Install Directory: /Library/Adobe Licensing/Adobe CC Complete Serial – Video Serial Number
  • Package ID: com.organization.AdobeCCCompleteSerial-VideoSerialNumber
  • pkg: Adobe InCopy CC Serial – Video Serial Number
  • Install Directory: /Library/Adobe Licensing/Adobe InCopy CC Serial – Video Serial Number
  • Package ID: com.organization.AdobeInCopyCCSerial-VideoSerialNumber