Hi @jpeters21 - I'd like to try this! I am new to Composer and not strong with scripting at all. Can you elaborate here a bit on your steps? 

1. Run Adobe downloader and copy Acrobat_Install.pkg from the downloaded archive to /private/var/tmp on a source machine.

2. Run Composer, drag the path /private/va/tmp with the pkg to Sources in Composer. 

3. In Composer, ctrl click Scripts to add a post install Perl script. 

4. ???

I actually copied the whole folder (wondering if there are external dependancies that were causing the upload of the install.pkg from working properly). And then the Bash script below. Just remember to double check permissions in composer as it seems this always has to be changed to "root" and "Wheel", select the three dots and apply the permissions to all enclosed. Hopefully the images below help. While I have been scripting for Mac a while, I am a Jamf and composer newb.. but if you have a bunch of apps and just spend a couple weeks packaging you get the hang of it pretty quick.. adobe was one of my pains though. That,  Unreal editor and AMPSS have been the problem children. 

Great! I went ahead and moved the entire folder to ~/tmp and applied Write to Wheel (you were correct, was not present), then applied to all enclosed as noted. Copied your example of the installer command and replaced with my own path. Composer did give me a "!" on save of the script, and compile noted an error for "getcwd" at ln 0... I spaced #! /bin/sh. Because I know nothing about scripting, absolutely no idea if this is a vanity thing by Composer or if it impacts the script running, but it got rid of the "!" so my imposter syndrome driven ocd is abated ha. 🙂 Will test upload and deployment shortly here and report back. Many thanks for the detailed and quick reply.

Edit: @jpeters21 This solution worked for me on an Intel 11.6 Mac! It sounds like this may be a useful approach for other installers/packages too; copy it to local, run installer once its on local. Probably obvious to folks working with Mac management on the regular; but the details really help here. I hope a few others can chime in and verify as well to get this marked as a solution.

great to hear it helped.. I found this method most useful when there is a plist that sits outside the installer .pkg.. but still I give it a try even when thats not the case if I am getting errors on other methods. Another less used method is using curl commands in a script to pull down the installer (I use that same /private/var/tmp location). I do that on a couple things so that the same deployment package is always the most up-to-date software. Removes my need to come back and do too much patch management. Also check out the jamf training library, lots of good information there. 

This is great that it is working for you, @MasterNovice! Thank you @jpeters21 for sharing!

Unfortunately, it looks like things on the M1 side are being a bit more difficult.

When I have Composer convert to source, I get the following error message:

That's frustrating! I'm running a slightly older version of Composer, but I was able to reproduce this same error by dragging the install pkg from the exctract into packages and then trying to convert to source.

When I was able to get this to work, I grabbed the downloader package from Adobe Admin. I ran that to dump all of the install files to a folder in private\\var\\tmp and then dragged that entire path, with the other folders and the install pkg in it from Finder to Sources in Composer. As jpeters noted, permissions needed to be changed as well.

Have not had that one yet, but just a shot in the dark here, in composer check the preferences. 

I have found the executable types not working to well as "Automatically detect executable type" .. and the other options working a bit better on anything with universal or ARM binaries. 

Adobe doesn't know how to make deployment friendly pkgs. They are useless for anything except for desktop support running around with a flash disk installing it manually. They generate a fat pkg, so at a minimum it needs to be wrapped in another installer that runs the embedded installer. Since these are large packages, that means it needs to decompress the contents twice causing it to go much slower than normal. On top of that, their installer will only work while a user is logged in, so you can't install it while the machine is at a login window, before first login, or with a utility like MDS. 

I'm pretty sure the error you were getting from the script was because you copied @jpeters21 shell script into the perl script you created. The first line that starts with "#!" tells the system what kind of script you're running. So, composer was expecting "#!/bin/perl", but you entered "#!/bin/sh" and it threw an error. Since you broke up the line, it probably saw it as a comment and ignored it (normally, the "#" at the beginning of a line makes the script ignore that line, so that comments can be left in scripts for people to read).

I have not worked with perl scripts, but am getting experience in shell. Composer gives the postinstall script option for for shell scripts as well, so that is what I used.

Just want to pile onto this and say it was an issue for us as well in Jamf School. Going the route suggested by @jpeters21 worked like a charm for both M1 and Intel MacBooks.

I think you're correct here, thank you for the detail @Fluffy - I realized while writing up the internal doc for this process. I have no experience with scripting languages and applying them is always an exercise of copying existing solutions and applying as a monkey-with-a-wrench. Modern administration in some of my Microsoft environments has forced more work with Powershell (thankfully), but even that is often strings of ad hoc commands and less of a flow of operations when I script them. It just isn't my wheelhouse. That lack of fundamentals often leads to small syntax errors that sometimes can hold me up for a long time. At least now I know the difference between defining the language for a script, and commenting out a line!

Just had my very own frustration with Adobe installers, and after reading about your efforts I knew I wanted an easier solution, because I'm lazy. Even found one, an astonishingly easy solution using AutoPkg (here) and adding the repo by Rich Trouton (here). It not only download the latest Adobe installers, but also creates an installable package for either Intel or Apple Silicon (or both, if you prefer).

This whole process of getting Adobe to install and working with Jamf School really outlined some of the limitation of the product and how it feels poorly supported by Jamf over Jamf Pro. I ended up going the long way around to fixing this problem (which in the end, is probably a good thing; more on that in a minute).

I have setup a server hosting a Munki repository and have invested quite a bit of time to learn AutoPkg, AutoPkgr, and Recipe Robot. Instead of using the Jamf School package loader, we just install the Managed Software Center (which we have rebranded with our school logo, name and colors) and let it take over from there. There are a lot of members of the community that have made recipes for almost all of the applications we use. For the rest, I use Recipe Robot and some Google-Fu to get things setup.

In the next month or two, we'll be migrating to Jamf Pro due to a major expansion of our Mac fleet and if I don't like how Jamf Pro handles package management, I know have a MDM-agnostic way of handling package management.

tl;dr Adobe is still horrible, Jamf School feels under cooked, and I'm happy I invested time to setting up and learning Munki

That works fine for the base installer. Using Installomator is another option to install just the latest version of the base installer. If that is all you need then it is trivial. The issues in this thread are encountered if you want to embed applications like Photoshop or InDesign in to the installer or use some of the managed deployment options. Unfortunately you are stuck with the deployment unfriendly Adobe Packager in this later case.

Funny that you would mention munki, because that's been the first thing I introduced when I started at my current employer (at that time there was no, zero, zilch, management at all, software was deployed using ARD. That was 2020, ancient history now). I'm currently moving everything into Jamf, at last.
Do you use Jamf admin for package management & scripts, or is that not available for Jamf School? (Sorry, still a bit new to it)

I thought I was missing something. No argument about Adobe Packager from my side, though. Sorry.

Adobe Packager deployment issues are not unique to Jamf School or Jamf Pro. Adobe basically designed it for sneaker net. They expect a desktop engineer to walk around with a flash drive and manually install it. The only reliable automatic method is just sticking with the base install and let the users manage their own installs and updates.

I wonder if Adobe would also deliver new sneakers if your Mac fleet exceeds 500. They could even brand them Adobe Personalised Update Service or something..

I don't think Jamf Admin works with Jamf School. Everything is loaded in through the web interface. Jamf School does have scripting, but I know it is relatively new.

No need to apologize! I'm in awe every time I visit these forums. A lot of very experienced users and I'm glad everyone is willing to share their trials and tribulations.

This whole post started with the need of just loading Adobe Creative Cloud onto our Macs so our users can self-service. None of our users have (or will every have) admin rights and using the package from Adobe Admin Console that enables standard users to load the apps they need has been the pain in my side. We have mixed use of Adobe on our campus and simply loading CC and letting the users eat from the Adobe buffet has been the way to go on the Windows side of the house.

Here is what I did.

1. Created a managed  Adobe package in Adobe Admin console. I made two packages because Jamf couldn't do more that 30 GB of an upload, so I split them up.
2. Downloaded the DMG file from Adobe.
3. Downloaded the ZIP file from the DMG.
4. Extracted the ZIP file.
5. Copy and pasted that extracted folder into /private/var/jamf.
6. Dragged and dropped that location "/private/var/jamf/Adobe", or wherever you wanted to put it, into Composer to create the package source.
7. Expanded the Composer source so that it showed the scripts folder and added a post-install shell script with the following commands.

#!/bin/sh



installer -pkg "path to Adobe installer.pkg" -target /



sleep 2



rm -rf "path to Adobe installer.pkg"



exit 0​

• Saved the Composer package as a package and uploaded that into Jamf.
• Created a Jamf policy to install the uploaded package.

This did the trick for me as well. Completely ridiculous that it's necessary, but thanks for the fix.

I apologize as this is an old thread, but Adobe CC is not playing nice with JAMF School for us.

When I deploy the package on a computer, the installer gets copied to /private/var/tmp, but immediately gets deleted before installing.

It sounds like the issue you're facing is related to how Adobe packages its Creative Cloud installer. The file you download from the Adobe Admin Console is typically a wrapped installer — essentially a folder containing multiple components rather than a single .pkg file. This can cause problems when deploying through Jamf School, which prefers flat .pkg files. 

Thanks for the reply. Weird thing is if Adobe Creative Cloud was already installed on a computer and then uninstalled, Jamf School installs it without issue. Only on clean installs does it present this issue of copying the installer but not installing.