Skip to main content

We are deploying ClearPass OnGuard to our macOS fleet using Jamf Pro. The ClearPass application installs successfully via the Jamf policy, but it fails to establish a connection with the ClearPass backend. Manual installations, however, are fully functional. The root cause has been identified as a missing or misplaced .agent.config file, which is a hidden file essential for the initial configuration and backend communication. This file is present within the ClearPass DMG but is not included in the standard PKG installer.

The challenge is to devise a deployment method using Jamf that ensures both the ClearPass installer PKG and the .agent.config file are present on the client machine at the time of installation, allowing the application to connect to our backend successfully.

This is a problem for the vendor to solve. Their package is missing dependencies, and they need to fix that. If you were so inclined nothing is stopping you from packaging the config and deploying it yourself ahead of the install package, but again I would not do this and I would make the vendor provide instructions.

This is a problem for the vendor to solve. Their package is missing dependencies, and they need to fix that. If you were so inclined nothing is stopping you from packaging the config and deploying it yourself ahead of the install package, but again I would not do this and I would make the vendor provide instructions.

I have tried that and it didn't work there is something about the .agent.config that it seems has to be in the same location as the pkg for the installer if not it doesn't work correctly. 

This goes back to its a vendor problem to solve, you are paying for the tool and support for it; make them earn that money.

 

This can still be done but its a bit convoluted. Save the package, and the cong in the same directory. Then use composer to package both of them (yes package the package), finally add a post install script in composer to execute the vendor package. Put the composer package in a policy and deploy, when jamf runs the composer package, it will place the vendor package and config in the same directory then execute the vendor package with the post install script. Jamf will have no logging once so ever for this as you are separating the vendor package execution from the jamf policy, but it would work. However, again, reach out to the vendor as this is a broken process they need to fix. 

 

One last thought, jamf can deploy .dmgs and you said the dmg had everything it needed to run.

This goes back to its a vendor problem to solve, you are paying for the tool and support for it; make them earn that money.

 

This can still be done but its a bit convoluted. Save the package, and the cong in the same directory. Then use composer to package both of them (yes package the package), finally add a post install script in composer to execute the vendor package. Put the composer package in a policy and deploy, when jamf runs the composer package, it will place the vendor package and config in the same directory then execute the vendor package with the post install script. Jamf will have no logging once so ever for this as you are separating the vendor package execution from the jamf policy, but it would work. However, again, reach out to the vendor as this is a broken process they need to fix. 

 

One last thought, jamf can deploy .dmgs and you said the dmg had everything it needed to run.

OK i didnt know about JAMF deploying DMG’s everythign i have read on that said that you had to repackage it into a PKG file 

This goes back to its a vendor problem to solve, you are paying for the tool and support for it; make them earn that money.

 

This can still be done but its a bit convoluted. Save the package, and the cong in the same directory. Then use composer to package both of them (yes package the package), finally add a post install script in composer to execute the vendor package. Put the composer package in a policy and deploy, when jamf runs the composer package, it will place the vendor package and config in the same directory then execute the vendor package with the post install script. Jamf will have no logging once so ever for this as you are separating the vendor package execution from the jamf policy, but it would work. However, again, reach out to the vendor as this is a broken process they need to fix. 

 

One last thought, jamf can deploy .dmgs and you said the dmg had everything it needed to run.

OK i didnt know about JAMF deploying DMG’s everythign i have read on that said that you had to repackage it into a PKG file 

 

Yep, Jamf happily deploys DMGs. Sometimes you need some scripting to make them work as intended as some DMGs are meant to be mounted and manually interacted with, so you just cache it and use a script to do the thing.

This is an old script I used to mount and execute a macOS dmg from years ago that still works if you needed a starting point for how to run a cached DMG. If the DMG can be run rather than cached this script should not be needed.

 

#!/usr/bin/env bash

#* FileName: Install_PKG_from_DiskImage
#*=============================================================================
#* Script Name: Install_PKG_from_DiskImage
#* Created: r11/4/2020]
#* Author: 
#*=============================================================================
#* 
#*=============================================================================


#*=============================================================================
#* Define global Variables
#*=============================================================================
dmgName="$4" #Name of the DMG to be mounted
dmgPath="$5" #Location of the DMG to be mounted, if deployed by JAMF it will be in /Library/Application Support/JAMF/Waiting Room
intallerPath="$6" #Path to the MacOS Installer App within the DMG
installerDestination="$7" #Path to where the MacOS Installer App is to be moved
volumeName="$8" #Name of the mounted volume
#*=============================================================================
#* Global Variables End
#*=============================================================================

#*=============================================================================
#* Validation Section
#*=============================================================================
# Use Example, quotes are not needed in the parameter as they are defined with the variables above.
# dmgName="Apple_macOS_Big_Sur_11.2.1.dmg" 
# dmgPath="/Library/Application Support/JAMF/Waiting Room/Apple_macOS_Big_Sur_11.2.1.dmg" 
# intallerPath="/Volumes/Apple_macOS_Big_Sur_11.2.1/Applications/Install macOS Big Sur.app"
# installerDestination="/Applications/Install macOS Big Sur.app" 
# volumeName="/Volumes/Apple_macOS_Big_Sur_11.2.1"
#*=============================================================================
#* Validation End
#*=============================================================================


## Mount DMG file with no browse to hide the desktop icon
echo "...Mounting $dmgName"
sudo hdiutil attach "$dmgPath" -nobrowse

## Install PKG
echo "Copying MacOS Installer to /Applications"
sudo cp -R  "$intallerPath" "$installerDestination"

## Wait 20 seconds to allow for package to transfer
sleep 20

## Unmount DMG
echo "Unmounting $volumeName"
sudo hdiutil unmount "$volumeName"

## Wait 20 sec to make sure DMG unmounts
sleep 20 

## Delete DMG
sudo rm -rfv "$dmgPath"

 

Terms & ConditionsCookie settings