FYI: Adobe issue and workaround proceedure

[#1]

Hey Guys-

I've been working to figure out an issue we've been having with Adobe Installers at image time for the past week or so. Between our work and Sam's at Jamf support, I think we've figured out the cause. I just thought I would share with you our symptoms and our workaround incase any of you have similar issues.

The Symptoms:

We have an old maintenance license for Adobe Creative Suite and therefore don't have the Master Collection, but instead we have DVDs for Photoshop, Illustrator, InDesign, etc. all as separate images. When we want to install these at image time, Casper Imaging copies all of the dmgs to the FirstRun folder and builds a FirstRun script that will install them. The problem with this is that they actually copy the FirstRun script and resources to /private/tmp before putting them on Macintosh HD and our NetInstall image can't fit all of that in it's tmp directory.

The tmp directory would fill up, Casper Imaging would not error out, and we would get partial FirstRun scripts or wouldn't get one at all.

The Work Around:

What we ended up doing was making a policy with a custom trigger called "InstallAdobeApps." This policy just installs the Adobe Apps like normal, but since we aren't in the NetInstall environment the / private/tmp directory has the entire local disk space to work with. I wrote a script that we set to run at reboot when we image that just calls the custom trigger.

One thing that I wanted to add to this was the jamfHelper.app (this window that covers the login window and tells users that it is installing Adobe apps). In order to add this functionality, I made a package that just contained the app (which can be found in the support directory inside the Casper Imaging.app package) which I had it install to /Library/Application Support/UWSP/.

Note: I initially tried to install this to /tmp, which is a silly idea since /tmp gets flushed at every boot and hence the file did not remain there.

The script then will check that the helper app exists, and if it does will fire it off before, and kill it after, the adobe installer policy is run.

The finished script looks like this:

#!/bin/bash if [ -d '/Library/Application Support/UWSP/jamfHelper.app' ]; then /usr/sbin/jamf launchJAMFHelper -path '/Library/Application Support/UWSP/jamfHelper.app' fi /usr/sbin/jamf policy -trigger AdobeInstalls if [ -d '/Library/Application Support/UWSP/jamfHelper.app' ]; then ## Unlock the login window /usr/sbin/jamf killJAMFHelper ## Remove jamfHelper /bin/rm -rf '/Library/Application Support/UWSP/' fi exit 0

I just thought I would share this since it has many other applications, especially if you want to lock down the login window.

Ryan Harter
UW - Stevens Point
Workstation Developer
715.346.2716
Ryan.Harter at uwsp.edu

[ernstcs]

Hi Ryan,

Nice work.

We have the luxury of using the Master Collection license and files here (keep in mind we only have one full copy of Master Collection to do this imaging work), but to add to this I also have a sequence of policies that also patch the Adobe suite, and some of these don't complete unless a user is actually logged in it appears. I don't have all of the updaters tested, there are some that just never seem to work IMO, particularly on different hardware types.

But to simplify the process I use:

Machine images, reboots for FirstRun Machine installs the Adobe base at FirstRun At the end of FirstRun a script calls a policy in the JSS Policy creates a local installer account, applies an autlogon package for it, installs a local copy of JAMFHelper, and then reboots Machine reboots, auto logs on with the installer account, triggers a login policy, policy triggers JAMFHelper, installs available adobe patches The final packages the policy installs is a startupitems package, deletes autologon package, and machine reboots * At reboot startupitem script deletes installer account, deletes itself, runs a recon cycle, and then triggers a final policy so I know it finished and also uninstalls jamfhelper copy

As you can see it's a fairly fun process, but it's worked fairly well. It doesn't have to be triggered just at startup after imaging. You can use that process to also patch clients by calling the same policy first run does.

I can try to share more if people are interested.

Craig E