9.90 Adobe CC Packages do not install during Imaging

@KDempsey93 are the packages set to Install on Boot Drive After Imaging? I have all of my CC packages set to that and they install fine.

@stevewood The packages are not currently set to install after imaging.

Is this a requirement for the CC packages to install as we have had success previously with them during imaging?

I personally use a cached install which works perfectly.
So, Create a Policy to Cache CC, Then create a second Policy to Install Cached.

cheers

@KDempsey93 I don't know if it is a requirement, but I know that is how I deploy and it works. The problem with Adobe apps is that they require a user to be logged in to be deployed. You're not supposed to be able to deploy at the login window, only with a user logged in. Which also means that installing on a non-booted drive (which is what you are doing if installing as part of a Casper Imaging configuration) will not work.

However, I say that you're not supposed to be able to install at the login window, but that is exactly what happens when you check the "Install on boot drive after imaging" box. You are installing at the login window, but on a booted volume. I have no idea why it works, I just know that it does in my environment.

If you want to deploy after imaging with a user logged in, I use the method that @kerouak mentioned, caching first with one policy and then installing with a second policy. When doing upgrades of the CC suite (from 2014 to 2015 for example) I will cache the installers (and uninstallers) to the machine and then prompt users to run via Self Service or I'll trigger the install policy to "At logout" with a JAMF Helper dialog to let them know what is going on (why logout is taking so long).

I'm 99.9999999% sure that the scripting involved in the Adobe packages is not smart enough to target the local hard drive while you are using NetBoot. If you look back in the history of Casper, the reason why that "Install on Boot Drive After Imaging" option was created was for Adobe package installation. Regardless of whether or not they worked in the past for you, I believe JAMF's best practice was to always have them install at the first boot if you are using Casper Imaging.

@stevewood - I believe the loginwindow issues have long since passed as long as you don't try and install Adobe AIR. I install Creative Cloud on computers at the login window without issue for a few years now.

When you select packages to be installed at first boot, you are not selecting that they be installed at the login window. Casper creates a temporary user account and that the computer logs in at first boot with, then it proceeds to put up the splash screen that Casper Imaging is running, and then installs all the packages you have set Casper Imaging to install at first boot. Then the system reboots and leaves you at the Login Window. YMMV depending on how you setup your imaging.

@taugust04 - same here, I haven't had issues installing at the login window for years either, but I know others have. And you're probably correct, it has to do with Adobe AIR.

I do not install as part of a CI build configuration, rather I use a post imaging script that runs after first boot. So I have a package that installs a LaunchDaemon and a script and then the computer reboots. On that second reboot the LaunchDaemon kicks off the script which then calls different policies to install software. So, when I install CC it is done at the login window because it is done via that script.

So, I too have had this start happening when for the past few years, first with AAMEE and now CCP, I have had no issues. Now, when I try and install a CCP created package via imaging, it fails. I have taken out AIR products and ensured this is being done after imaging and part of the first run script. I cannot have this!

The package is installing just fine after the fact via Casper Remote. Maybe I will simply have to forgo the installation during the imaging process? I have several hundred Macs to image with Adobe CC so this is a real setback.

I see @stevewood, you have a work around for this by using a LaunchDaemon and script. Is this something you can share?

I wanted to amend my comments above, it still failed using Casper Remote:

I took the CCP created package and tried to install directly from it onto a known good system, without Casper at all. It begins to install, I can see many different applications filling into the applications folder. However, after about two-thirds through the installation, the installation will fail. Once it fails, the applications begin to disappear from the applications. I have doubled checked to ensure that we are ignoring conflicts and the AIR installers are NOT included. So I am a little stumped.

Anyone seeing this? Anyone else have a work around? We were planning to begin imaging all of our labs starting tomorrow, but I am putting this on hold until I have a solid work-around. My other option is to begin without Adobe CC being installed. Once working, I can then create a policy to install later.

Thank you everyone for any ideas to help me figure this out.

@mconners give me a little time today to put together the process I use in a coherent way and scrub the script and LaunchDaemon for you.

In the mean time, let me give you some details on how I deploy Adobe products during imaging and also during normal day to day.

To start with, I do not create a large CCP package that includes all apps. Instead, I create a CCP package for EACH Adobe app I want to deploy. So a package for Acrobat, a package for Photoshop, etc.

For imaging, I created a policy that has each of the apps I want to deploy in it. We primarily deploy Ill, InD, PS, and Acrobat. So the policy I have has those four apps, plus Bridge and Extension Manager. I then call this policy during the "imaging" process. Really, a script calls the policy AFTER Casper has restarted the machine twice (once after Casper Imaging finishes, and then again after Casper has installed any packages that are set to install on boot drive after imaging).

For normal deployments, after a machine is imaged, I utilize two policies: one to cache and the other to install from cached. Again, I create these policies with the individual apps that are needed. The policy that caches the installers touches a file in /Library/Application Support/JAMF/Receipts and then does a recon. This allows me to scope the second policy, the one that installs from cached, to machines that have this "receipt" in place. I can use a Self Service policy as the second policy (which I have done in the past to give users control) but most times I am installing for them via either a Recurring Check-In trigger or manually triggering by policy id (jamf policy -id <id#>).

Hope that gives you someplace to start testing. As soon as I have 10 more minutes to go over the script and LD, I will post them.

@stevewood Thank you. This was a path I was about to start going down, individually packaging each app. At least this would help me determine which app is breaking the installer. I am also starting with a barebones Mac to begin testing until I find where the conflict is.

I am suspecting there was something new introduced into the CCP, 1.9.5, and this is causing the problem.

Thanks!!