Cisco AMP fails to open/install for standard user

[landon_Starr]

Hi all,

I working on packaging up the Cisco AMP connector, and I've hit a wall.

Our security team provided a DMG from Cisco's admin portal, and inside is the package with the app and all other configs. If I run it manually it installs fine, but once I remove it from the DMG, things get weird.

So I've tried making snapshots that have the app in the applications folder, and the config files in /opt/cisco/amp (their default). Everything gets put into place, but the AMP app will not open. The system believes it's running, but I have zero control over it.

I've also tried to script the install but its failing too. I drop the PKG from Cisco in /tmp/AMP, and then have a little script to install:

#!/bin/sh

#Switch to /tmp/AMP directory
cd /tmp/AMP

#Install Cisco AMP
installer -pkg /tmp/AMP/ciscoampmac_connector.pkg -target /Applications

exit 0

I've tried a few different variations, but Jamf's logs continue to say that the path doesn't exist despite telling the script to run after the files are put in place.

[mm2270]

Did you ever get anywhere with this? I'm working with a customer using Cisco AMP, and I've had some issues with getting the install to work correctly myself when pushed from a policy. I discovered that there is a hidden .policy.xml file in the root of the mounted disk image that it seems the installer may look for when it's run from the mounted disk image. The file has a ton of information in it. If you just copy out the pkg installer into Jamf and run it, it will install, but may not function properly, at least in my experience.
I'll be experimenting with taking that policy.xml file out into a tmp location along with the installer and package those up into a new install in Composer with a post install script to see if it installing it from the same directory as the xml file helps.

BTW, in your script above, you want to use -target / not -target /Applications The target is only the target volume or device, not a specific path to where to install it. That's probably why you're seeing those path doesn't exist errors.

[lunddal]

You have to install from the DMG. Cache the DMG and use a script like this:

#!/bin/sh
####################################################################################################
#
# Based on JAMF Software's installPKGfromDMG.sh
#
####################################################################################################

# Variables used by this script.
dmgName=""

# CHECK TO SEE IF A VALUE WERE PASSED IN FOR PARAMETERS AND ASSIGN THEM
if [ "$4" != "" ] && [ "$dmgName" == "" ]; then
    dmgName="$4"
fi

# Mount the DMG
/usr/bin/hdiutil attach /Library/Application Support/JAMF/Waiting Room/$dmgName -noverify -nobrowse -noautoopen

# Install the PKG wrapped inside the DMG
/usr/sbin/installer -pkg /Volumes/ampmac_connector/ciscoampmac_connector.pkg -target /

# Unmount the DMG
hdiutil detach /Volumes/ampmac_connector -force

# Delete the DMG
/bin/rm /Library/Application Support/JAMF/Waiting Room/$dmgName
/bin/rm /Library/Application Support/JAMF/Waiting Room/$dmgName.cache.xml

Set Parameter 4 in the policy to the name of the DMG file.

[hdsreid]

@lunddal yep mounting a dmg was the only way I could get it to work as well. I did it by putting the dmg in the root of a composer package and using a postinstall script to mount, install, unmount and remove dmg.

[landon_Starr]

Hi all, sorry for my late response here.

I racked my brain on this forever, but ultimately found that the solution was pretty simple. It's been called out already, but yes, there's a hidden policy.xml file in the DMG and once you move the package away from it, the PKG refuses to cooperate.

So all I did to fix the issue is throw that .policy.xml in the tmp folder along with the PKG, and then run my little script as a postflight (with /Applications removed, of course).

Works like a charm!

[mm2270]

@landon_Starr That's exactly the method I began putting together - placing that .policy.xml file and the .pkg into the same location in /tmp/ via the main package installation payload and then installing it from there with a postinstall script. I expected that should work and would be a little bit better than caching the DMG, mounting and installing it from the mounted volume. (although that does work too, just more involved) So thanks for confirming what I was thinking.

Frankly, whoever at Cisco put this "package" together clearly doesn't have a clue about enterprise deployment. I sometimes think they get these people from the past through a time machine from a time when all installations were done over sneakernet or something. It's 2019. Their install is so not enterprise friendly. If they can't build a proper .pkg installer that doesn't require running from a disk image then these people are in the wrong business.

[landon_Starr]

@mm2270 I had discovered that xml file initially through Pacifist, but wasn't aware that it was the cause of my issues. I actually opened a case with Cisco TAC in order to figure it out. It's weird too because that engineer seemingly had a prompt of what to say, so I totally agree with you. You would think a company like Cisco would have something like this ironed out already.

[mm2270]

Just circling back to confirm that the method described above, dropping the .policy.xml file and pkg from the DMG into a folder in tmp and having a postinstall script install the pkg from that path, works perfectly. Cisco AMP installs, no errors in the JP console and no problems with Cisco AMP on the Mac.

[lunddal]

@landon_Starr They do have a document about the changes: https://docs.amp.cisco.com/Mojave%20Announcement.pdf

[Surajit]

Does anyone have any EA to check the installed AMP Connector Version ?

[t_jones]

@mm2270 and @landon_Starr Im having this issue. Where do you find the policy.xml and how do you put that policy.xml into a tmp folder to run with the pkg?

Is this still your process, even though this thread is pretty old?