Wehave JSS 9.81 up and running in a basic kind of way, but are struggling a bit in using it to full advantage. Our first task is to use it to install BigFix on all of our Macs (ironic, I know). We're just going to use the BigFix client for power reporting, and still plan to use Casper for everything else.
Then I built the package via composer. I clicked on "Normal Snapshot", then followed the instructions and ran the BigFix installation. This created a source. I didn't add anything to the scripts, settings, or snapshots folder. I created the package and then copied it to Casper Admin. In the JSS I create a policy called Install BigFix, selected the package, selected Install as the Action, set trigger to "Recurring Check in", selected a single computer as the target. Policy is enabled. Then I went to the target machine and manually had it check in. It ran very quickly, but the logs say that the BigFix package was successfully installed.
You can create the package for the config profiles several different ways....with Composer by dragging them into the Source section to create a new package (if they are in their intended destination on your Mac it will build out the folder structure for you and you just need to fix the permissions...if they live in your user directory it's a bit trickier).
Advantages to using separate app and config packages:
1. You don't have to modify the vendor's package (assuming it works, they often do)
2. When you get a new client there is a chance you won't have to update the config package, just swap out the vendor package
What you want to do is put the Bixfix installer and its support files into /tmp/bigfixInstaller/ using a Composer package so the BigFix Installer Package is installed to there. Then have a postinstall script which runs the BigFix installer.
What you do want to package up separately are the config files. Keeps things separate and work on the things you need to work on and don't work on the stuff you don't need to work on. If a new BigFix installer is out, then you can upload/replace the installer you currently have without the config file package being touched (and vice versa if the config file package needs to change).
For our BigFix deployments I have a Policy that contains a single .DMG file that contains the installer pkg and the .afxm file in a single folder. I have them copied to /users/shared/ That's just my personal preference, you may want to copy them to /tmp or something like that. it is up to you. The other part of the policy is the installer script that runs After and consists of:
As @bpavlov mentions, the pkg SHOULD be deployable without the script. The only reason I haven't taken that step out is because our InfoSec team is adamant that it install via that script. It does work this way for us so I haven't been motivated to fight their decree.
@bpavlov The BigFix installer is distributable as is, but it needs to be next to a config file. The postinstall script in the BigFix installer looks for the config files next to the installer package so that it knows what server to bind to.
Jamf's purpose is to simplify work by helping organizations manage and secure an Apple experience that end users love and organizations trust. Jamf is the only company in the world that provides a complete management and security solution for an Apple-first environment that is enterprise secure, consumer simple and protects personal privacy. Learn about Jamf.
This site contains User Content submitted by Jamf Nation community members. Jamf does not review User Content submitted by members or other third parties before it is posted. All content on Jamf Nation is for informational purposes only. Information and posts may be out of date when you view them. Jamf is not responsible for, nor assumes any liability for any User Content or other third-party content appearing on Jamf Nation.
I recommend looking in the bigfix documentation about the methods supported to deploy software on these Operating systems as this is more about bigfix deployment method than XDR installation coverage. . If bigfix supports msiexec for Windows deployment you should be fine using the steps in our documentation[1], the same applies for Linux[2] with rpm/dpkg and MacOS[3] with a unified configuration profile for MDMs similar as jamf process.
3a8082e126