How do we know a Mac is actively managed?

[acostj]

Have run into this several times and haven't found a specific fix or documentation. So with jamf binary you can check if JSS connection is available as well as know that the binary is installed. Unfortunately no way to check if enrollment is currently active and valid, also if the Mac for whatever reason hasn't fallen off and not communicating into the JSS. My question here is there any hidden feature I don't know about and if there is no feature is this feasible if a feature request is added. Also would like to know more about jamf binary possibly having some security measures added to self heal itself in scenarios where a Mac just needs to be re-enrolled.

[aturner]

Have you set up a smart group to look at last checkin or recon time? You can do this so the JSS will tell you when a computer hasn't checked in within x days. This means it is no longer enrolled or something fishy is happening. Of course, keep in mind that if your JSS isn't open to the outside world, simply taking a computer off campus will break its connection to your JSS and put it in this group.

Also, I would put three things in your inventory view, JSS binary version and last recon and last checkin time.

I don't think there is a way to self heal the binary but you can always recon a machine over and over which will heal any broken issues and reconnect them to the server

[aturner]

More or less, if the computer is on the network and hasnt checked in in a while, you can probably assume something is broken in the connection and if other computers are growing well, then it is probably the end user computer in question.

[acostj]

Thanks, but don't want to assume want verifiable data to show if the jamf binary knows the connection and knows how to communicate in I need to be able to tell my Help Desk run this command and it will tell you that the connection is there and in good shape. We have x days since last communication and this isn't passing for us. Some of our users go off grid for weeks longer that x days since last communication and that does not help. I need the jamf binary to have a verifiable method that the connection is good and can report it back to JSS and my IT teams can be sure it is working.

[bjohnson]

So if i'm understanding this correctly you want to be able to report on a machine that isn't reporting back into the JSS??? The big question is whether this machines are on during that time that they are not checking in or are they just in someones desk. If they are just in a desk not being used there is nothing that you will be able to do about it. If that machine is on but just not on your network you will need to look into getting a Web Application in the DMZ so that your clients can check in all of the time and not just when they are on your internal network.

[aturner]

I would fully agree with bjohnson. You can also forgo the DMZ server, but this is less secure and not best practice. For working on machines off campus, without a DMZ server, there is really not much that you can do. Knowing whether they are still functioning properly with the JSS then becomes an afterthought. This is because you can't do anything with them. With the DMZ and distribution point in the DMZ, you will actually be able to use the JSS with those computers.

If you need help with that setup, let me know. This is especially useful with your setup:

"Some of our users go off grid for weeks..."

[alexjdale]

Here is what I am thinking, and what led me to this thread.

I want a way to self-heal the Casper client, in case it stops working for some reason. I keep the Quickadd package cached on each system, so I could set up a login hook to run a script that does a couple things:

-Ping the JSS to see if it is reachable (if not, assume client is off-network and exit out)
-Check to make sure the system's JSS record is active and healthy

If the first check passes and the second check fails, reinstall the cached Quickadd package to get the system healthy again.

Unfortunately, the only way I see to do that second check is to run a recon, which is not something we want to do on every login since it has a system impact.

Honestly, the biggest problem I see is technicians reusing Ethernet dongles and overwriting system records, and this would be a workaround to solve it. We have hundreds of techs globally who are not all careful about this.

[acostj]

Found a way to test if communication is there and is good.

Using bash script to return result of command:

jamf log
result=$?

This will log to JSS and of course tell you if the communication was good "0" and if not able to reach or Mac not enrolled "1"

Jose

[PeterClarke]

Here is a script I use to do his check manually, when I am troubleshooting…
It performs TWO useful functions…

Checks if Casper Client is installed
Checks if Casper Client is connecting to the server.

-- Peter

#!/bin/sh

# Program: Check_Connection_to_Casper.command
#
# This uses a subset of the casper client startup script
#
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