Cisco Secure Install Fails...But Only If Upgrading From Jamf

[McAwesome]

I'm in the process of building the latest Cisco Secure client for deployment.  I am building it using Stephane Sudre's Packages app (1.2.10).  I have the Cisco Secure pkg (pulled from Cisco directly) and the Choices.xml added in Scripts > Additional Resources.  The post-install script is very straight forward and just runs

/usr/sbin/installer -pkg ./Cisco\ Secure\ Client.pkg -applyChoiceChangesXML ./Cisco-Secure_choices.xml -target /

This works every time I run it on a clean install or if I run it locally on a machine with an older version of Cisco Secure.  If I try to deploy this package via Jamf policy to a machine with an older version of Cisco Secure installed, it fails 100% of the time and uninstalls the existing install.

The Jamf policy log just gives the standard unhelpful "The Installer encountered an error that caused the installation to fail." message.  The install.log tells me that the error was with the post-install script, but that is so straight forward I'm struggling to see where the error on it could even be.

Is there some trick to deploying updates to Cisco Secure via Jamf that I am missing?  I know the package is good since it works without issue on new and locally updated machines.  I'm just at a loss on why upgrading via Jamf policy would be any different.

[msergi]

While this isn't a direct solution to your problem - would it be possible to upgrade your clients from the firewall push? this is how we have handed our Cisco client updates and it works very well, even going from Anyconnect v4 -> Secure Client v5. If you have several that are not able to be upgraded this way, it may be wise to run the uninstall script to fully remove the old version first in the policy, and then then run the fresh install of the latest version instead of going over the top.

[McAwesome]

That would be my preference as well, but the team that handles that is....not the fastest.  Now that we're also working on getting Umbrella rolled out we're needing to get them to speed up to match.

[mschlosser]

interesting, issue, it may be worth remembering that scripts that run from jamf run as root this may cause issues depending on exactly what the Cisco software is trying to do, may be best to start the install as the current user toes if that solves the issue, similar to the below:

#!/bin/bash
#variable for storing the current users name
currentuser=`stat -f "%Su" /dev/console`
su "$currentuser" -c "<command to run>"

also, while building the package it may be a good idea to double check that the posix permissions are correct on the installed files and have been propagated throughout the entire package. If IO had to guess; because it executes correct locally and errors form jamf, I'd look at user context.

Hope those two things at least give you places to look.

M

[McAwesome]

I should clarify.  It executes correctly when run locally, when deployed as a new install via Jamf, and when installed on top of the same version via Jamf.  It's only failing if deployed through Jamf to a machine that has a previous version currently installed.

I did forget about that user context bit, but if that were the cause shouldn't I expect it to fail on clean installs via Jamf policy?

[mschlosser]

Ah. that is interesting; and I see what you are saying regarding the inconsistency; as far as the reason for this sort of behavior, that is strange; I'd have to give it more thought. that said, the route of least resistance would be to remove the old version and then install the new one, in my opinion. 

[MehdiYawari · Accepted solution]

Hi 
I had the same issue with a policy which contains a script to first uninstall Cisco Secure Client and then install the new version of Cisco Secure Client triggered by a separate policy.
The uninstall part which also uses the vpn_uninstall.sh in /opt/cisco/secureclient/bin caused the issue. As in this script, every process is killed which contains the name "Cisco Secure Client". And our Script was named "Install/Update or Repair Cisco Secure Client". As this script contained "Cisco Secure Client" in its name, vpn_uninstall.sh script of Cisco has been killing my script which was triggered by our policy in Self Service.
After renaming the script in Jamf, the Problem was solved.

Dont know if this is also the issue in your case but is worth a shot to take a look at.

[McAwesome]

Renamed the package from "Cisco Secure Client" to just "Cisco Secure" and it worked no issues.  I am so annoyed it was something like this, but as long as it's working now I'm ok with it.

[Jmardian]

Could you elaborate on this? I've been running into a similar issue. I am deploying the pkg from a script similar to yours, and I get the same generic error in the logs. I can only find success when I run sudo jamf policy manually as the su.

#!/bin/bash

sudo installer -pkg /private/tmp/Cisco\ Secure\ Client.pkg -applyChoiceChangesXML /private/tmp/csc_choices.xml -target /

exit 0

[McAwesome]

In my case, my package was name included "Cisco Secure Client", so when the install ran, the initial uninstall step from Cisco's pkg force killed my pkg I wrapped it in.  When I built it exactly the same but named "Cisco Secure" instead of "Cisco Secure Client", everything worked fine.

[Jmardian]

I see.  I don't think that applies to my issue, but I appreciate the response! 

[jgaitherccu]

Have you found a fix? I've been working on this for weeks, myself. Same issue as you. If I sudo jamf policy the CSC package installs just fine. If I let the system naturally check in for an install the package install reports complete but no Cisco folder and the log says "installer: The install failed. (The Installer encountered an error that caused the installation to fail. Contact the software manufacturer for assistance. An error occurred while running scripts from the package “CiscoSecureClient.pkg”.)"

I'm going to try renaming the package to CiscoSecure like that person below suggested. If that works it's a very bizarre fix.

[Jmardian]

Sure did. The Secure Client PKG I am using packages Duo Desktop along with it. The installation errors were occurring due to the cert I didn't have for DUO not the Secure Client... SUPER ANNOYING. And none of Cisco's documentation mentioned anything about needing a cert for DUO, which is hilarious because I don't even need DUO in the first place... Anyways, if your PKG contains DUO Desktop, follow the instructions here to create and push out the config for DUO before installing the Cisco Secure Client: https://help.duo.com/s/article/6403?language=en_US 

[jgaitherccu]

..............

..........

.....

.ffs

That's about the stupidest thing I've ever seen. Especially since it installs just fine when manually typing sudo jamf policy into terminal. For posterity's sake here is what I ended up doing courtesy of your help.

>Upload SecureClient pkg to JAMF

>Create Script with the following text:

echo "Adding empty Cisco Secure Client Duo File..."
mkdir /Library/Application\ Support/Duo
mkdir /Library/Application\ Support/Duo/Duo\ Device\ Health
touch /Library/Application\ Support/Duo/Duo\ Device\ Health/DisableMacOS11CertManagement

>Create Policy with SecureClient pkg and "blank duo file" Script. Set Script to run Before.

[jgaitherccu]

Forgot to add that I also created another Script to run After in the Policy with the following text:

/Applications/Duo\ Desktop.app/Contents/Library/LaunchServices/com.duosecurity.UninstallDuoDeviceHealth

[McAwesome]

You should also be able to fix this by adding Duo specific stuff to your choices.xml file.

[Jmardian]

Agreed. I was so burnt out from deciphering what the hell was going on in the PKG that I was just happy to get the Umbrella portion working. This is the logical next step, just removing DUO from the equation entirely.