Trouble deploying policies with PKGs built from Adobe Creative Cloud Packager?

[CasperSally]

Hoping someone can help me figure out how to get Creative Cloud packages installing through policies? I'm on a Windows 9.65 JSS and getting same results when deploying to OSX 10.9 and 10.10.

I used Creative Cloud Packager 8.0.0.168 to create the pkg files (one pkg for each app). I was careful to name the packages with no spaces (i.e CCDreamweaver_install.pkg).

They install fine during imaging if I set them to install on the boot drive. The installer also works fine if I manually double click and run through it.

If I try to install them with a startup or login policy via http, I get "could not connect to the http server." I can push other pkgs fine via http (I tried Java).

Under computer management, file share distribution points, all of my distribution points are set to use AFP and are hosted on 10.10 servers.

When I set the policy to use AFP/SMB I get "installer encountered an error that caused the install to fail. Contact the software manufacturer for assistance" in jamf.log.

I saw some other threads on jamfnation and I tried doing a chmod -R 755 on package to make sure permissions were right and same issues. I tried wrapping the PKG in DMG and same results using this old method https://jamfnation.jamfsoftware.com/article.html?id=161.

/Library/Logs/Adobe/Installers doesn't have anything about the package that's failing.

I didn't click 'migrate' yet in casper admin. When I drag the Creative Cloud pkg's to casper admin, they remain pkgs, should they be converting to zips?

Also, Creative Cloud packager just prompted me to update to v9 so I guess I'll try that now and rebuild one of the packages to make sure that doesn't help.

Anyone have any other suggestions of things to try?

[donmontalvo]

@CasperSally wrote:

I didn't click 'migrate' yet in casper admin. When I drag the Creative Cloud pkg's to casper admin, they remain pkgs, should they be converting to zips?

Adobe Creative Cloud packages are not likely flat, the "Migrate" button in Casper Admin should ZIP those bundle PKGs. Once you've Migrated, going forward bundle PKGs should get ZIP'd.

Migrating Packages and Scripts

[CasperSally]

@donmontalvo my understanding was even if you don't migrate, once you upgrade to 9.x PKGs should get ZIPd. I posted here on that but am waiting for a response

[donmontalvo]

I crossed the same bridge... I had to hit the Migrate button after upgrading to v9.

PS, I heard you're presenting at JNUC2015? :)

Don

[CasperSally]

No, I won't be at JNUC.

[CasperSally]

Rebuilding with Adobe Packager Builder 9.x seems to have done the trick. I can now deploy Dreamweaver via login policy. Going to rebuild them all now. Sorry to have wasted anyone's time. Will report back if for some reason that doesn't work for all.

[RobertHammen]

If your packages aren't getting ZIP'd when copying to your Windows-based CasperShare, they are getting corrupted (CCP creates non-flat PKG files with symbolic links in them which are broken when copied to a non-Mac filesystem).

[donmontalvo]

It all goes back to the share not being migrated. Once you do that, the problem goes away (I would still re-upload the Adobe PKGs to be safe), all PKGs get ZIP'd on upload, and all scripts get embedded in the JSS database.

[CasperSally]

thanks @RobertHammen - Our share is on 10.10 servers AFP. It seems to be going fine as is.

@donmontalvo I'd be happy to migrate if there was a good way to test it first. In our environment, especially with JAMF, things break every time I touch something. It took us 4+ months to upgrade from 9.32 to 9.65 because of issues we had in testing environment & 9.65 still has quirky issues for us. I don't look forward to changing something else.

[donmontalvo]

@CasperSally we have several test environments. A Mac Pro with the same JSS version as the live environment. We drop/import the database, rsync the local DP, and then change a few things, and test by enrolling a test Mac to it. Once you have a test environment, its fairly quick/easy to refresh it so it is as close to the live environment as possible. Just an idea, hitting the Migration button worked flawlessly for us - but we did it first in one of our test environments. I realize not all shops have the option to do this, but just a thought.

[CasperSally]

@donmontalvo We have a test environment, but not a test master dist point to test the migrate function.

[donmontalvo]

@CasperSally The database and DP would be in the same state as the production environment.

1. Copy DP to your test box (which should have Server.app configured for HTTP/AFP/SMB)
2. Drop database; add database; import backup
3. Tweak URL, DPs, etc., in JSS
4. Migrate
5. Enroll a test Mac and test

Once you've got a test box, repeat the above to "refresh" the test environment.

[jhalvorson]

I have been able to "archive", zip the Adobe CC packages before dropping them in to Casper Admin and they install correctly. I haven't tried any other types of packages. [Casper Suite 9.65, Adobe Creative Cloud Packager 1.9 (aka 9.0.xxxxx), with OS X server AFP/HTTP file share distribution points]

I don't know if this works only because when we went to 9.5, I had completed the migration step after setting up a JDS. Does the migration process include support for zipped files or isn't the migration necessary? Due to numerous problems, I stopped using a JDS since then.

[spalmer]

While this may not be related to the issue at hand be aware that even if you click on migrate in Casper Admin some non-flat packages, like some Ricoh drivers and Adobe CCP created packages, still don't get copied/zipped correctly.

I found a bug, Defect D-007918, where the symlinks are not copied into the zip package correctly. Instead of copying the actual symlink Casper Admin follows the symlink and copies the contents of what the symlink points to into the zip file.

The work-around until this is fixed by JAMF is to manually zip the PKG files and copy them directly to the CasperShare via the Finder. Casper Admin will discover the new package on next launch.

[donmontalvo]

We are trying to get Dreamweaver CC 2017 17.5.0 update deployed to 17.1.0 users.

We always quit the app for them, after warning them, to avoid installation issues.

Example (conveniently stolen from our buddy @mm2270 haha):

#!/bin/bash

PROCESSES=("Dreamweaver CC"
"Dreamweaver Helper")

#### Do not edit between these two lines ####

for PROC in "${PROCESSES[@]}"; do
    RUNNING_PROCESSES=$(ps axc | grep -i "$PROC" | awk '{print $1}')
    if [[ $RUNNING_PROCESSES ]]; then
        echo "Found running process $PROC with PID: ${RUNNING_PROCESSES}. Killing it..."
        kill $RUNNING_PROCESSES
    else
        echo "$PROC not found running..."
    fi
done

#### Do not edit between these two lines ####

exit 0

There is always one Dreamweaver CC process, but also there are a number of Dreamweaver Helper processes to quit as well.

The loop only quits the first Dreamweaver Helper process...is there a secret to quitting multiple instances of that process?

Or, do we list that process multiple times in the loop script like so:

PROCESSES=("Dreamweaver CC"
"Dreamweaver Helper"
"Dreamweaver Helper"
"Dreamweaver Helper"
"Dreamweaver Helper")

Hoping we can avoid any duct tape workflow. :)

TIA,
Don

[bentoms]

@donmontalvo For years i've done Adobe CC updates at logout or over the login window.

The former is caching the pkg locally, warning via policy that updates are pending.. then installing at logout.

The latter is via Munki & jamJAR.

Sorry can't help more, but we just dodged the issue.