Installing BigFix via JSS

[SVM-IT]

Apologize in advance for the newbie question.

We have 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.

When we install the BigFix client on a Mac manually, the install consists of 3 files:

BESAGent-9.2.6.94-BigFix_MacOSX10.6.pkg
actionsite.afxm # a config file
clientsettings.cfg # a file which indicates which department the BigFix client "belongs" to

The BigFix client reports to a server managed by the Enterprise, while it's deployed by our Department. That's the reason for the clientsettings.cfg file.

When I install it manually, I know it's successful because I can see BESClientUI in the activity monitor.

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.

Casper thinks it's installed, when I lookup the computer and look at "package receipts', under Casper Suite, it shows BigFix.pkg, but it's not showing up in the Activity Monitor.

Any suggestions?

Thanks in advance.

Seth

[Josh_Smith]

I don't know where the config files go, but I would probably:

1. Drop the vendor package (BESAGent-9.2.6.94-BigFix_MacOSX10.6.pkg) into Casper Admin
2. Create a package for the configuration files manually (no snapshots)
3. Give the config files a lower priority (larger number) then push them out together in a policy.

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

[thoule]

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.

/usr/sbin/installer -pkg /private/tmp/BigFix/BESAgent-9.2.6.94-BigFix_MacOSX10.6.pkg -target /
rm -fdvr /tmp/bigfixInstaller

See this post (https://jamfnation.jamfsoftware.com/discussion.html?id=18832) from @mm2270 , but instead of running profiles, you'll run installer (script clip above)

[bpavlov]

Looking at the BigFix installer very briefly, this installer SHOULD be deployable as is. No modifications needed. No re-packaging required.

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).

[AVmcclint]

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:

#!/bin/sh

# Change working directory
cd /Users/Shared/BigFixAgent9.2.5.130
# Install BigFix
installer -pkg /Users/Shared/BigFixAgent9.2.5.130/BESAgent-9.2.5.130-BigFix_MacOSX10.6.pkg -target /

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.

[thoule]

@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.

With Casper, the QuickAdd package has the server/jss and info built into the installer. Bigfix distributes the config files next to the installer.

[SVM-IT]

Much obliged. I was able to get Casper to push out BigFix to our Macs using the following steps:

Download BigFix files from campus file server.
cp downloaded files to /private/tmp/BigFix/* on the "build machine".
cp /private/tmp/BigFix/BESAgent-9.2.6.94-BigFix_MacOSX10.6.pkg to Casper Admin
cp /Library/Application Support/BigFix/BES Agent/actionsite.afxm into Composer create a package; save to desktop; drag into Casper Admin; set priority to 9 cp /Library/Application Support/BigFix/BES Agent/clientsettings.cfg into Composer
create a package; save to desktop; drag into Casper Admin; set priority to 9 Create policy in JSS to install the three files.

Thanks for the help.