Checking if a computer is already enrolled

[emmayche]

We have some users who need to wipe and reinstall their Macs with a baseline image we provide to them now and then. This baseline image automatically tries to enroll the computer with a QuickAdd package. However, as I'm sure many of you know, things get messed up if you try to enroll a computer that's already enrolled.

So what I want to do is find out how to tell if the computer - even though it's been wiped - is currently enrolled with the JSS. It would also be nice if there were a way to automatically unenroll it (so that re-enrollment would go smoothly), but I'll settle for knowing if it is or not.

Does anyone know how to approach this one?

[mm2270]

I'm a little confused. Are you saying you want to know from the client side if the Mac is enrolled? If so, I would think just running a sudo jamf log or sudo jamf manage would tell you that. If those don't work while on your network, or if the jamf binary simply isn't present, then it's not enrolled.

If you meant something different than that, maybe you can clarify it a bit.

[emmayche]

That's exactly what I mean. Remember, the computer has been wiped - thus, the JAMF binary would not be there, but the computer would still be enrolled as far as the JSS is concerned.

So you're saying that I could reinstall the JAMF binary and do a sudo jamf log, and if it fails it's not enrolled. OK, that makes sense.

[mm2270]

Wait, why would you want to copy over the binary just to do that? If the device is wiped as in 'nuke and pave' imaging, its no longer "enrolled" in your Jamf Pro server, period. There may be a now orphaned computer record in the JSS, but that would be it. By design, once things like the binary, LaunchDaemons, device certificates and other Jamf related stuff is wiped, the device can't communicate with the JSS anymore, and is effectively unmanaged. I don't see the reason to actually copy/install the binary to run that command, or to really worry if it's still under management at all in that case.

If the concern is about leaving an orphaned record in the JSS, well, you could address that with a script that uses an API account to locate the old record via the Mac's serial # or UUID, both of which shouldn't change unless there was a hardware repair and/or the new mobo didn't get serialized back. You could even direct the script to locate and delete such a Mac record, but keep in mind the API account would need delete privileges on computer records in that case, so be careful with that. You don't want that account being compromised.

Last thing to keep in mind. The JSS will pair up a machine that gets re-imaged and re-enrolled with it's original record, effectively updating the computer record with whatever new information it found. This is because of the hardware identifier it uses (UUID/UDID) but only if you leave the record in place. if you delete it, upon re-enrollment, it creates a whole new record, since no previous one exists.

[emmayche]

Actually, since the JSS really messes up if you leave the identifier around and try to re-enroll the same device, we had to come up with a positive method for removing a device from the JSS. The following shell script does the trick:

disenrollFromJSS.sh:

#!/bin/sh

URL="https://your.jss.url.goes.here.com:8443"
userName="dedicated.jss.username" # We created a special username for this purpose with limited privs
password="aDifficultPassword" # That account's password, of course

serialNumber=$( system_profiler SPHardwareDataType | grep "Serial Number" | awk -F: '{ print $2 }' | xargs  )

/bin/date "+%Y-%m-%d %H:%M:%S  Current device serial number: $serialNumber"

/usr/bin/curl -k "$URL/JSSResource/computers/serialnumber/$serialNumber" --user "$userName:$password" -X DELETE

if [ $? = 0 ]; then
    /bin/date "+%Y-%m-%d %H:%M:%S  Removed device serial number from JSS: $serialNumber"
else
    /bin/date "+%Y-%m-%d %H:%M:%S  Failed removing device serial number from JSS: $serialNumber"
fi

exit 0

Hope this helps someone.