Adobe Package CasperShare replication problems

epowell
New Contributor

I am having issues with Adobe Packages created using Creative Cloud Packager after they have been replicated to other file share distributions points. Essentially permissions to access the pkg files are lost. The actual permissions shows as being the same for other working pkg and dmg files however, somehow the OS will not allow for copying them from the CasperShare. The original files as they exist on the primary distro point work fine. Is there something I am missing. Would anyone have insight into why permissions will fail only on Adobe PKGs upon replication?

Edit: The Distro points are AFP

1 ACCEPTED SOLUTION

emily
Valued Contributor III
Valued Contributor III

It won't work in a standard imaging config… We got around it by scoping the policies around a dummy receipt that we lay down during imaging that would normally include that app. The policy is set up with the script and DMG, then set to the enrollment trigger. When the machine enrolls during the imaging process, the policy runs and installs the apps.

View solution in original post

5 REPLIES 5

emily
Valued Contributor III
Valued Contributor III

I've never been able to successfully deploy a PKG created by the CCP. I think the preferred method is creating a DMG with the PKG inside and then using a script to install the cached DMG on the machine. Try following this https://jamfnation.jamfsoftware.com/article.html?id=161. If you need to see the workflow with screenshots I've blogged about it here: http://www.modtitan.com/2014/08/packaging-and-deploying-adobe-cc-apps.html

evanmellichampe
New Contributor III

@emilykausalik is correct and her workflow is flawless. My recent experience with CCP and using it to create an installer for CC Desktop EEA has been very much the same. Our organization is now being provided with separate license keys per site, so I have managed to build an unlicensed installer for all sites to use and then hit it via custom trigger to call out the specific license key. This works better than hosting 18 different installer .dmg's at 13.78GB each.

For CC Desktop EEA, you have to use a valid license key to build the installer, but then you can drill down into the package contents and delete the /Contents/Resources/ProvisioningTool/adobe_prtk after building it, which will remove the license key. Once removed, you can proceed with Emily's steps to house the .pkg in a .dmg and then move on to creating your different license files. What I've done there is use the CCP to build the separate license file (SITE-CCLicence), which is a folder that contains the following:

AdobeSerialization
helper.bin
prov.xml
RemoveVolumeSerial

I then place the folder in /var/tmp/ (personal choice) and use Composer to make it into a .pkg. After hosting the .pkg in the JSS, I use a policy to cache the behemoth AdobeCCDesktopEEA.dmg and the InstallDMGfromPKG.sh to install it. At then end of that policy, I have it trigger a custom event to run an additional policy that installs the SITE-CCLicence.pkg and the following script to run after:

#!/bin/sh

/private/var/tmp/SITE-CCLicense/AdobeSerialization

So far, so good.

emily
Valued Contributor III
Valued Contributor III

We send invites to users through the Creative Cloud web app, so really all I did was package up the Creative Cloud app itself for installing. We do have a few of the apps (Photoshop, Dreamweaver, Illustrator, InDesign) packaged using the JAMF-recommended method sitting in Self Service, so if we are setting up a new hire machine and want certain packages pre-installed without having to manually create the Adobe ID for the user, we can just throw them on there. When they finally log into the CC app, licensing is applied.

epowell
New Contributor

I am deploying the adobe software primarily via Casper Imaging, are there any changes needed in the script or in the DMG or should the combo work the same regardless of being deployed VIA Policy or Imaging config?

emily
Valued Contributor III
Valued Contributor III

It won't work in a standard imaging config… We got around it by scoping the policies around a dummy receipt that we lay down during imaging that would normally include that app. The policy is set up with the script and DMG, then set to the enrollment trigger. When the machine enrolls during the imaging process, the policy runs and installs the apps.