If you’ve been using jamf for any period of time, I’m sure you’re familiar with the jamf binary. This is the bash commands that are installed on any enrolled computer. You’ve probably used a couple of them, including “jamf policy” and “jamf recon” – however, you may not be aware of how powerful the jamf binary actually is, especially if you’re a proficient scripter. Lets look at a couple powerful ones, include “jamf policy” and “jamf recon” :
jamf policy
You may know that jamf policy kicks off the recurring checkin, and probably use it in testing so you don’t have to wait the 5-60 minutes for the recurring checkin to kick off. However, there’s a lot of powerful flags that it also has:
-trigger
This allows you to kick off a particular event other than recurring checkin. For instance, if a policy is set to run a login and you want to test it without logging out and back in, you could do jamf policy -trigger login
You can also use this to kick off a custom trigger, which you can define within the policy itself inside jamf. For instance, if you had several policies with a custom trigger of “test” – you could kick that off during your script by using jamf policy -trigger test
-id
This allows you to trigger any policy by adding its id number, which you can find in the address bar when you’re in a policy. For instance, if your policy has an id of 7, I can run jamf policy -id 7 to kick off that policy.
I use this flag anytime I’m testing out a policy for three reasons:
It kicks off that policy and ONLY that policy
I don’t even need to set a trigger for it
Recurring check-in sometimes runs into a random delay of 300 seconds. However, if you use the id flag, I will never run into that.
jamf recon
You probably know this policy to force the inventory update for a computer. This is easy to do via Terminal so you don’t have to potentially wait a week to get updating inventory for a computer when testing. However, this can be used to port useful information into the inventory for that computer.
For instance, if the computer is bound to AD and you want to port their username into the “User and Location” payload of the computer’s inventory record, you can run the following two line script:
Username=`/bin/ls -l /dev/console | /usr/bin/awk '{ print $3 }'`
jamf recon -endUsername $UsernameThe great thing is if the JSS is integrated with LDAP, this will also port over all their LDAP information as well, including full name, email, building, department, ect!
But it’s not just username info you can port in, you can port over all kinds of useful information. Check out this list:
-assetTag The asset tag of the computer -endUsername The user name of the primary user -realname The real name of the primary user -email The email address of the primary user -position The position (job title) of the primary user -building The text representation of a building in the jSS -department The text representation of a department in the JSS -phone The phone number of the primary user -room The room that the computer is in
jamf help
Arguably the most obscure and useful part of the jamf binary is the jamf help pages. These basically function as a man page in a more robust way, but it’s not super intuitive how it works. It’s also worth noting that there is no man page in the jamf binary, so this is all you got.
jamf help (command)
If I just run jamf help, it will show me all the commands I can run on the jamf binary. However, if I run jamf help followed by a command, it will show me all the flags I can add to that command. For instance, if I run jamf help policy it will show me more information about the policy command, along with all the flags I can run. You can also do this with recon, enroll, or any other command within the jamf binary.
sudo
Every part of the jamf binary needs to be run as sudo, EXCEPT for the help command. However, you can add sudo to jamf help to run as a super user, and oftentimes it shows more information than if you run it as a normal user.
-hidden
This is an obscure flag that’s not documented anywhere, but you can add it to any help command you run. For instance, you can run sudo jamf policy -hidden to see ten more flags you can run on the policy command! Note that you do have to use sudo, or it won’t show you any of the hidden flags.
Moral of the story: Anytime you are using “help” – run sudo before and -hidden after to see ALL of the available information.
What’s your next steps?
I’ve hopefully convinced you of the power of the jamf binary. If you’re using Jamf to manage the computers in your environment, spend some time experimenting with the different commands available to you. Experiment with the commands I’ve listed above, and look through the help pages. If you feel a bit overwhelmed, here’s some commands I’ve found to be useful, taken straight from the jamf help pages:
displayMessage Displays a message to the current user
enroll Enrolls this computer with the JSS
removeFramework Removes the JAMF Binary and associated files from the computer.
checkJSSConnection Checks the availability of the JSS
getComputerName Displays the computer name on a volume
createSetupDone Ensures the Setup Assistant does not launch immediately on the next boot
deleteSetupDone Causes the Setup Assistant to launch on the next boot