adobe_prtk
./Applications/Utilities/Adobe Application Manager/CCP/utilities/APTEE/adobe_prtk
.adobe_prtk
among those. But it turns out, if we take a look at the strings of AdobeSerialization
- which the docs say we can run with “admin privileges” to license the software - some of the first strings found in the binary look an awful lot like flags to adobe_prtk
:AdobeSerialization
seems to be a purpose-built version of adobe_prtk
with options baked in. This tool loads your authenticated data and license details stored in an opaque format from the prov.xml
file to perform a transaction with Adobe’s licensing servers and commit the results to the local machine’s Adobe licensing database.AdobeSerialization
there’s the RemoveVolumeSerial
tool. Unfortunately, as mentioned previously and in Adobe’s official CCP documentation this tool is supported for “Enterprise and EEA customers only” - which means it can’t be used to deactivate a machine that is using a Device license in a Teams-based agreement. In fact, it has an LEID baked in along with the adobe_prtk options: V7{}CreativeCloudEnt-1.0-Mac-GM
. (For reference, the current LEID for the Creative Cloud Teams “Complete” product is V6{}CreativeCloudTeam-1.0-Mac-GM
.)adobe_prtk
. From my examination, these roughly boil down to using the --tool=GetPackagePools
flag for a device (Teams) license (see references to “DBCS” throughout the code, ~/Library/Logs/oobelib.log
file and the prov.xml
file), and --tool=VolumeSerialize
for a serial number (Enterprise) license.adobe_prtk
tool and knowing the LEID of the product we want to deactivate, we can also do what the RemoveVolumeSerial
tool cannot do: deactivate a teams-based device. The tool options don’t seem to be different depending on a device or serial license, the issue is simply that RemoveVolumeSerial
has a hardcoded LEID, whereas we can know ours by looking up the list, or even better, retrieving this automatically from the prov.xml
file.adobe_prtk
can perform a superset of the functions these two special binaries output from CCP can do, using a single binary. So in order to build a “licensing package” that can be installed as a native OS X installer package (and deployed with Munki, Imagr, DeployStudio, Casper, etc.) we have our necessary ingredients: we need the adobe_prtk
(or “APTEE”) tool, the prov.xml
file corresponding to our license, and we know the commands to install and remove the license. Still, we need to know which command flags go with which license type, and we need to set the correct LEID if we want to ever be able to deactivate the license. Why not instead use the binaries that are output by CCP? As I described above, the removal tool will not work for all license agreements. I’d rather not have to keep track of multiple different binaries if one can do all the work.adobe_prtk
, which will be discovered automatically if you’ve already installed CCP on the system running the script, and your prov.xml
file output from your “Create License File” workflow. Everything else should be figured out for you, and a package will be output given the package parameters you specify:uninstall_script
key with an uninstall script that will be populated with the appropriate LEID. Either way the uninstall script will be saved to the package’s output directory for your own use in other systems./var/log/install.log
). Adobe documents their error codes on their website, and so the install/uninstall scripts generated by this package actually report this info to standard output/error so you can at least immediately get a short description of why any failures might have occurred. There will always be full debug output in the various AAM logs, but the locations of these files are rarely easily discoverable or well-named (for example, ~/Library/Logs/oobelib.log
).