Adobe CC Shared Packaging Too Large

[MrPeppah]

How are others installing Adobe CC Shared packages in school labs? When I build the package within the Adobe Admin console, the pkg with almost all the products (media lab) is 28.2GB. 

[ktdorsey94 · Accepted solution]

create each as an individual package and then send out instead of all packaged together.

[jmcmahon1]

I break it into two packages instead of the hassle of making a dozen or more small packages.

[MrPeppah]

I didn't know that was possible, thank you both. 

[joshuasee]

Though you'll probably want to go with the previously mentioned tactics, there are some others:

1. Don't use a Jamf distribution point for that package. The size limitation is specific to the JCDS, labs are usually within reach of file servers you can use, and you can choose which packages to sync to a given distribution point.
2. Adobe installers, unlike most, are not flat packages. This means you can split one into segmented tarballs small enough to fit on a JCDS, then reconstitute and install it with a script, or with proper placement an install cached packages command.

[MrPeppah]

We are using the Pro Cloud option and use Azure so JCDS is the only option. I used to have on-prem JAMF Pro but I need 1 less server to manage. We only have 1 Apple lab so if this splitting option works, I'll take that route for automation. If not, I'll see about the file share method. If I had more machines than 22 I'd try option 2. This is all useful information. Thanks!

[btaitt]

Create an installer for each Adobe app you want to deploy. Take each of those, create a separate policy for each and number them (1 - Adobe Creative Cloud Lab, 2 - Adobe Photoshop Lab, etc) and on each other those, have them run off a custom trigger (like "adobelab" or something).

Then create a new policy called "Install Adobe in Labs", all it does is run your custom trigger. You can do this either under Maintenance or as a custom script. It will then run each policy one at a time and Jamf does recognize them in order if you number them. 

[AtillaTheC]

Installomator ftw unless you need a specific version other than the latest

[joshuasee]

Unfortunately, that only gets you the Adobe CC Desktop client, and Adobe doesn't currently have a programmatic way to trigger subsequent app installs. This is an issue for labs where students need large applications like Photoshop, Premier, etc, preinstalled and more or less ready to use when they login.

[ktdorsey94]

You can go into the Adobe admin console and download the PKGS each individually. Don't build a package with each app. SO build a package for Dreamweaver, a package for photoshop, a package for Media Encoder or whatever software you may use. Then upload each individual package into JAMF for deployment. You can then create a smart group to check to verify that a certain application is installed in the application folder before installing the next to automate the flow. 

[Lincolnep]

If any one is interested I use a turducken method.

- Create monster Adobe package

- Zip Package.

- Split zip into 7GB chunks (A limitation of pkg is that it can't take single files larger than 8GB)

- Create pkg wrappers that will install the file chunks put them back together when it has all the chunks unzip and install the Adobe package.

Been running like this for year without any issues

Here is the postinstall script I use in the pkg wrappers it also has the instruction for splitting the zip into chunks:

#!/bin/sh
# To Split files use: (NOTE PKG has a limit of 8GB per file.)
# split -b 7G file_to_Split.zip prefixname
# Note you can add more than 1 file to pkg.


# Variables used by this script.
StoredLocation="TEMP Loacation Here!!!!!!!!!!!!"
JoinedName="AdobeCC"
dmgPartName="${JoinedName}a"
fileCount="5"

# Number of files.
partCount=$(ls -1q "$StoredLocation/${dmgPartName}"* | wc -l)
if [[ $partCount != *"${fileCount}"* ]]; then
    echo "Do not have all the parts"
    exit 0
fi

/bin/cat "$StoredLocation/${dmgPartName}"* >"${StoredLocation}/${JoinedName}.zip"

# Delete the part Files
/bin/rm -f "${StoredLocation}/${JoinedName}a"*

# Unzip the zip file.
/usr/bin/unzip "${StoredLocation}/${JoinedName}.zip" -d "${StoredLocation}"

# Delete the part Files
/bin/rm -f "${StoredLocation}/${JoinedName}.zip"

# Install the PKG
/usr/sbin/installer -pkg "${StoredLocation}/${JoinedName}"*.pkg -target /

# Delete the Temp Files
/bin/rm -f "${StoredLocation}/${JoinedName}"*

Hope this helps anyone.

[taugust_ric]

...

[taugust_ric]

Here is my recommended workflow for Adobe Creative Cloud:

• Build a "named license" individual package for each application you need to deploy.  The universal packages are great and I use those exclusively now for convenience.
• Build a package that just deploys the Adobe Creative Cloud app that includes the shared device license.
• Deploy your named license packages to computers that need either a named or shared device license.
• Deploy your shared device license Adobe Creative Cloud app to only systems that need a shared device license.

The reason why this works is that a "named" license is the "normal" state of the app.  When you install a package with a shared device license added on, it writes it to a special config file to gain that ability.  The only way to remove that shared device license from the computer is to remove that particular config file or edit it's contents - installing other named packages will not overwrite the shared device configuration file on the computer as long as it exists there.

The more modular you can be with Adobe, the better, because if your needs change, or Adobe changes, it's sometimes easier to modify a more modular worklow than a more monolithic approach.  Just my two cents. 😀