Checking the health of the jamf agent

If you can change the password on the account through a JSS policy and run a recon, it is generally in good working order.

One idea I have been toying with is a launch script that performs basic checks on a periodic basis and reinstalls a cached QuickAdd package if it fails (something like running a recon after verifying JSS connectivity: if that fails, you know there is a problem).

Haven't gotten around to it yet, but I would love to see some sort of self-healing feature available.

Yeah, I think many of us collectively have been toying with that type of thing. I agree, a self healing function would be great to have included in the product. Perhaps just something we can enable in the JSS under the Computer Framework Settings, so its not a default always on option. I'd imagine it would just involve some changes to the LaunchDaemon that already exists that does some checking already. Extend it to include the ability to re-enroll the device with a stored QuickAdd.pkg or even download the one that the JSS stores right now as can be seen in the self enrollment page.

Of course even a LaunchDaemon can be disabled easily enough by a user with admin rights, so that wouldn't be fool proof. It would help though.

If I ever have the time to put something together for this, I'll post about it.

JAMF doesn't really have an "agent" running on Macs. It's using what's already built into Mac OS X (primarily launchd) to regularly run its jamf binary file.

I've never seen launchd fail. In fact if it fails then much of the OS is going to start failing because practically every process is launched with launchd.

The best you could do is create an extension attribute (if something else isn't already in the JSS to report this—haven't looked) to check the version of the jamf binary using "jamf about". So long as it's version matches your JSS then everything's in working order. The JSS is pretty good about keeping this up-to-date on its own.

Well this does NOT fully resolve this problem..
But it does at least provide you with a way to monitor the connection.
This particular script is intended to be run manually.
I have not integrated it into any automation / reenrol methods..

#!/bin/sh
# Program: Check_Connection_to_Casper.command
#
# This is a subset of the casper client startup script
#
# Version 2: 2012-08-08
# Version 1: 2012-04-05
#
echo
echo "--------------------------------------------------------------------------------"

if [ -e /usr/sbin/jamf ]; then

## Ensure the JSS is available /usr/sbin/jamf checkJSSConnection
else echo "Casper Client is NOT yet installed on this Machine: $(networksetup -getComputerName)"
fi

echo "--------------------------------------------------------------------------------"

exit 0

A Mac can show no issue with checkJSSConnection but still be unable to execute a policy, re-enrolling required, etc...

Maybe an extension attribute to confirm ALL are YES (else NO):

1. does /usr/sbin/jamf exist
2. does <managementaccount> exist in dscl
3. is <managementaccount> password correct
4. does /private/var/<managementaccount> exist
5. is SSH enabled, and if ACL exists is <managementaccount> allowed access
6. is ARD enabled, and if ACL exists is <managementaccount> allowed access
7. are required ports open (SSH, VNC, etc.)

A policy to run QuickAdd if EA value is NO.

We have "persistence policies" in place for various inventory agents (HP DDM, Eracent, etc.), to ensure they are always installed, running able to gather/submit inventory data. Of course if Casper doesn't work, the policy is moot.

Agreed though, self-heal would be an awesome function for JAMF to provide. :)

Don

I wrote a self-healing script that uses obfuscation to hide the name "jamf" but checks for the binaries and directories and runs via a launchAgent every couple weeks. Mainly to catch my recidivist jamf removers.

We have a very robust launchdaemon named casperdaemon. It's originally delivered to each Mac via a enforce policy and it leverages a plist that contains various info about our jss url, filer location to curl down a new jamf binary if needed, basically contains all the paths needed in the plist. We have it running aggressively at 15 min intervals. JAMF did a wonderful job on exit codes, it will always be 0 unless there is a configuration issue preventing communication. if the server is unavailable it is still always 0. The daemon checks that /usr/sbin/jamf is present and if so executes a simply policy event, if that works it's good, if not or if the binary is missing we re-enroll the device on the spot.

I would love for JAMF to offer this themselves as part of the binary as a migration assistant will break the device enrollment because it brings over the jamf.keychain from the old mac. Or if say a user visits apple and gets the logic board replaced. This also breaks that device cert. In all these cases our daemon bring the system back silently.

Just happy that JAMF did a good job on the exit codes.

Does anyone uses script to identify macs withbroken jamf binary ?

We use an EA to identify clients that have the do_not_upgrade_jamf flag set, and various smart groups to list devices that use old jamf binary, lack MDM profile, did not approve MDM profile and so on. We also have several policies that indicate the issue in the Self-Service.

In general we find that the framework and the Self-Service are pretty bad at indicating configuration issues, even if they are aware of them, eg failure to contact the storage servers since the client has no or a wrong certificate.