Displaying status of enrollment on client

[chilcote]

We are building a status checker that the end user can use to verify that various services are running healthily on their systems. Regarding the jamf agent, what would be the best way to verify that the machine is enrolled and receiving regular transmissions?

jamf checkJSSConnection simply checks whether the JSS is available, and can return a false positive if there was an issue during enrollment (i.e. the machine was not on the network).

jamf manage is useful, but requires escalated privs. I'm looking for a quick way to have the status check run without user interaction.

Anyone out there doing something similar?

Cheers,
--joe

[mm2270]

I'm working on something somewhat similar, though in my case, I have a menu status item I'm building that will pull a bunch of information from the system and report it back. Right now I'm only checking if the JSS is available, but doesn't check if the Mac is properly enrolled. I haven't found an effective way to do this.

You can script checking for the management status of the Mac from the JSS with the API, but even that isn't too accurate. A Mac may not be communicating in but still be shown as "managed" in the JSS.

You could check to see if the "every15" check-in LaunchDaemon is running, but unfortunately it requires sudo, as in ```
sudo launchctl list | grep "Every 15 Minutes"
```
If you remove the sudo from the above, nothing gets returned because its a LaunchDaemon, not a user level LaunchAgent.

Same with doing a recon, requires root privs, so that's no go. I can't think of anything else that would effectively show you the Mac is properly enrolled and managed. its a tough one.

Ultimately I would like to see JAMF include some verb in the jamf binary to check the enrolled status of a machine.

[ctangora]

You should take a look at Trouton's Casper Check. While it isn't what you are looking for, it does do a health check (making sure network connectivity works, making sure jamf binary is in place, can see the JSS, and can run a policy).

Seems like it could easily be modified to suit your needs.

https://derflounder.wordpress.com/2014/04/23/caspercheck-an-auto-repair-process-for-casper-agents/

[iJake]

Second vote for Casper check. I implemented it as a safeguard in my environment and the logic is great.

[tlarkin]

Hello Everyone,

I hope everyone is doing well. I have written a few proof of concepts for customers in the past regarding this. As mentioned a ping, or even a curl of the JSS is not really a valid method since it doesn't actually authenticate to the JSS. The same thing with a checkJSSConnection from the JAMF binary, it simply just sees if the JSS is available.

The method I personally have used is a manual trigger policy, that touches a file on the Mac locally. This ensures to me that the device can check, and actually authenticate to the JSS and run a policy. If that policy fails, then I know that somewhere along the line the client is no longer properly authenticating to the JSS. Here is a snip of code I use in the scripts I have written (which are mere proof of concepts) to test the client to JSS authentication:

jamfCheck() {

jamf policy -event testClient

sleep 5 # give it 5 seconds to do it's thing

if [[ -e /private/var/client/receipts/clientresult.txt ]]
  then echo "policy created file, we are good"
       echo "removing dummy receipt for next run"
       rm /private/var/client/receipts/clientresult.txt
       rm /private/var/client/receipts/clientfailed.txt
       exit 0
  else echo "policy failed, could not run"
       touch /private/var/client/receipts/clientfailed.txt
fi

}

So, this policy just touches a file in that file path from the run command box in the advanced section of a policy. The script is driven by launchd, so it will run on a scheduled basis. If the policy succeeds, the file will be present on the local file system of that Mac. So, the next part of the code checks to see if any of the logic checks failed, and if they fail, they touch a file that indicates the client failed.

if [[ -e /private/var/client/receipts/clientfailed.txt ]]
    then downloadBinary
            jamfEnroll
    else echo "no failure found, exiting"
fi

I have two separate functions to download the binary from the JSS and then enroll the device. If that succeeds the 'clientfailed.txt' file gets removed. If that file is present, the launchd will try to download the binary and enroll the device again the next time it runs. If the client succeeds, it removes all those receipt files until the next time it runs, so it will stop trying to enroll itself.

It is very similar to what Facebook posted on their GitHub. If you look at their script, for the most part it was very similar to what I built as well. That would be a great starting place to build something like this. I also encourage a feature request created and up-voted here on JAMF Nation as well.

Thanks,
Tom

[SeanA]

feature request created at https://jamfnation.jamfsoftware.com/featureRequest.html?id=2279

[tlarkin]

Hi Everyone,

I am currently on a plane back to California, but this week while I was back in Wisconsin visiting one of our main offices we played around with some scripts I have written as a POC. I have two versions, one uses a quickadd, and this one has been tested and does work as a POC. The second one I have yet to really test due to time and travel. It actually just curls down the binary by itself and doesn't deal with quickadd packages.

I decided to toss them on our Support GitHub account. Please fork them if you would like to contribute to this. I will try to answer any questions regarding this and would be happy to commit any awesome changes to the master repo.

https://github.com/JAMFSupport/autoenroll

I agree that having a self healing option in the binary built in would be a better solution than the laucnhd with a script. I tried to make the read me file explain it, but I am sure that needs improving too. So, feel free to give us any feedback on this matter. I look forward to working with some of you on this and collaborating over GitHub.

Thanks,
Tom