Auto-Enroll after Clients have been deleted from JAMF

[sgoetz]

In our JSS I have roughly have the queue that has not checked-in after 180 days. Its my guess that these machines just have not been used in that long, or have been retired. What I would like to do is delete all machines that do not check-in with-in 180 days. Than if a machine so happens to come back online and check in with the JSS, it would check to see if the record exisit and if it doesn't re-create (enroll) into the JSS again. Has anyone figured out how to do this? Any input would be helpful.

Thanks!

Shawn

[mm2270]

I had looked into something similar where I am, but if I understand your question, you're asking if there is a way that the JSS can auto re-enroll a Mac that attempts to check back in if it finds no matching computer record? If so, I'm nearly certain that can't be done. If the Mac isn't already managed in some way, i.e. if there is no computer record for it, I don't see how the JSS could run any packages or commands on the device. It needs some way to connect to the Mac and run a policy on it and it simply can't do that in such a case.

What I had looked into was developing a LaunchDaemon that I could deploy to already managed Macs checking in regularly that would ensure they stay managed. For example, if it accidentally gets deleted or unmanaged, or if the user finds some way to disable management. Something that could kick off a script once a day, check connectivity to the JSS, then confirm its under management, possibly by locating its own record in the JSS using the API, and if it finds its not managed, or finds any components missing (jamf binary, launchdaemons, etc) it could run a QuickAdd.pkg that is tucked away hidden on the system to get it fully enrolled and managed again.
That may be possible to do, but I haven't had the chance to work out the details just yet.

In your case, if you're seeing Macs not checking in, I think the best you can do would be to leave the record in place, but un-manage them in the JSS. You'd have to uncheck the "Manage this computer" box in the Computer Information tab under the details.
Un-managing them would have a few nice affects:
- The Macs will still be able to do its check in if it comes back online. You can run reports on Macs that have checked in recently that are un-managed to see what may be communicating again
- The Macs will no longer show up in any Smart Groups or policies (only managed devices can be in Smart Groups)
- You can adjust any reports you run to exclude any non managed Macs, using the "Managed > Is > Managed" criteria

Hope the above helps.

[rcuza]

As you've probably discovered, `jamf recon, jamf mcx, and jamf manage` both return a "This computer is not managed by the JSS." error (exit code 1). This seems like the best indirect way to determine if a re-enrollment is required. It has the perhaps unwanted side effect of running the process if the machine is managed.

Have you discovered other ways to determine the managed state for a computer?

One solution I would not implement nor recommend involves modifying the StartupScript.sh. In an environment where you want to delete clients from JSS and give them the option of re-enrolling, you could modify `/Library/Application Support/JAMF/ManagementFramworkScripts/StartupScript.sh` in the following way:

#!/bin/sh

## Ensure the JSS is available
/usr/sbin/jamf checkJSSConnection

## Get MCX Settings for the computer
if ! /usr/sbin/jamf mcx
then
/usr/sbin/jamf enroll -invitation 0000000
fi

## Log the event to the JSS
/usr/sbin/jamf log -action startup

## Check for policies on the JSS
/usr/sbin/jamf policy -action startup

## Start SSH
/usr/sbin/jamf startSSH

exit 0

The change I made was that if the already present step of `jamf mcx` returns an error, then `jamf enroll` is run. This is not ideal because `jamf mcx` might return an error for a reason other than the machine not being managed. This would need to be investigated.

What this very brittle solution buys you is that whenever a machine starts the jamf process it also re-enrolls if the computer is not managed. Besides this change easily being undone by a Casper update, it also places an invitation number in a place anyone can see. This number is one of the necessary things needed to gain access to the managed users password.

If you want to go the wiser route of creating your own process, then ` /Library/Application Support/JAMF/FirstBoot/Enroll/enroll.sh` and accompanying launchd configuration are a good template. This script and configuration are there after a computer is imaged with Casper Imaging.app and is deleted after it successfully runs. Instead of the if/then statement checking JSS, it could run a command that returns an error if the client is not managed.