Posted on 01-21-2016 07:32 AM
I am having a strange issue delivering CrashPlan (using Install CrashPlanPROe.pkg 4.34) using JAMF, and I am looking for some feedback.
Using the "Administering CrashPlan PROe with the Casper Suite, Version 9.0 or Later” document, we built a custom CrashPlan install workflow. It has worked flawlessly for several months and continues to work fine if we deliver the software using the Self Service app. However, we have had some users that we want to push the software to, without any involvement from the user–a silent install. No worries, right? We just set the trigger to something automatic and it should install. That is not working correctly.
Here is the distilled version of where we are:
If we create a policy and the end user initiates the install from Self Service, the custom settings files are laid down and then the 4.3.4 OEM installer from Code42 runs and the application installs fine–CrashPlan works as expected, starting a backup without user intervention.
If we initiate the policy automatically using the JSS, by some other trigger (say, at login or at the regular interval check in), the custom settings folder gets laid down, but the "Install CrashPlan PROe.pkg” errors out when it runs. The error message is not very descriptive:
Installation failed. The installer reported: installer: Package name is CrashPlan
installer: Upgrading at base path /
installer: The upgrade failed (The Installer encountered an error that caused the installation to fail. Contact the software manufacturer for assistance.)
Here is the bizarre part:
JAMF policies can be triggered by running the command: "jamf policy -id xxxx", where xxxx is the number assigned the policy when it is ingested into the JAMF database.
I can use Apple Remote Desktop to push that command out to a Mac that needs CrashPlan and the installer .pkg will run successfully. (keep in mind, this is merely a different way of calling the policy that JAMF is triggering automatically)
I can ssh to a computer that needs CrashPlan and send that command and the installer .pkg will run successfully.
I can use the Terminal to run that command and the installer .pkg will run successfully.
I can use JAMF”s “Casper Remote” to run that command and the installer .pkg will run successfully.
In all of these scenarios, the user account “auto-populated” will be wrong (root or admin), but can be changed and backups will run–but the installer runs fine.
I tried to replicate the workflow manually to get JAMF out of the equation.
I copied the CrashPlan custom settings folder to the /Library/Application Support directory, then ran the Install CrashPlanPROe 4.3.4 installer by double-clicking it on the Desktop–the CrashPlanPROe installer ran fine.
I have tried modifying permissions on that custom folder that gets laid down to 777 for both files it lays down. No joy using a trigger other than Self Service
Anyone have any ideas?
Posted on 01-21-2016 08:04 AM
@Kevin do the computers your are trying to push the software to silently already have a version of the software installed? If they do you will probably have to kill the process before trying to install it silently. I ran into this the other day with Adobe Reader. I got the exact same message that you got and after I killed the running instance of Adobe Reader the installer completed.
Posted on 01-21-2016 09:09 AM
They do not have an existing CrashPlan installation.
Posted on 01-21-2016 10:34 AM
Do you have a user logged in when you trigger this policy via ARD, versus no user logged in when you try to install it at imaging? In our CrashPlan setup, we need a user logged in at time of install even if installing silently. Because of this, we trigger the install on first login of assigned user.
Posted on 01-25-2016 03:31 PM
This only runs when a user is logged in and we have an explicit exclusion for our local admin and management accounts.
Posted on 04-25-2016 01:13 PM
I am seeing the same issue for this.
It works fine via self service or if I run the installer locally. Have you found any solution?