The Worst Admin Task...

We just have a smart group for devices that have not checked in within the last 90 days.  Every Friday morning, we go in and delete the computers in that group.  The way we see it, if the machine hasn't checked in for 90+ days, the user is gone, got a new computer, or some other issues are happening and we don't know it anyways.  All devices are in ABM so if it "grows" feet we can still get our fingers on it.  

Same as @DBrowning , although our security policy states 60 days, and we look for both last check date and last connected date.  They are not always in sync.  For those that aren't we use that data to check up on the device and fix whatever needs fixing.

we also move this devices that are due to be weeded out into a Purge Site for another 15 days so we can report them out to the same security group, then they get permanently deleted.
Our off-boarding process I don't think even remotely qualifies as sub par.  More like non-existent.  You're not alone.

But after deleting the device from Jamf, the management profile is still left on the device, as well as all certificates, etc. 

How do you handle that? E.g. devices that are stored in a drawer for whatever reason.

Thanks @pbenware1  and @DBrowning , this helps.  Can you tell me this: if in your workflow, you deleted a Mac record of someone who's out on maternity leave or long term disability, how do you go about getting their computer re-enrolled?  That is something I'd like to avoid, removing records of those who are still with the company and are out.  

@steve_summers In My case we have over 6000 devices that are managed across faculty and staff.  Its really not possible for my very small team to know who has left the org, is on extended leave or just left the device in a drawer.  We have a strong dedicated field support team that is responsible for supporting end users and ensuring devices are compliant with our security policy.  The support model is such that field techs are more familiar with the comings and goings of faculty and staff and are best positioned to address the non-communicating devices when it happens. Its part of the previously mentioned reason for moving them to a Purge site; I generate reporting based on that, and it provides an opportunity for the field support staff to review the list of devices to be purged and if something jumps out at them we can prevent it.

It is far from perfect, and our lack of a comprehensive off-boarding process doesn't make it easier.

@Simonus Yep.  Its absolutely a problem for us as well.  In those cases, the device may (like, maybe 50% of the time) end up in the hands of the field support team first, before the user puts it back into action.  Again, its the benefit of having a large distributed field support team and more recently a very strong security posture.

In the near future we expect to have posture assessment tools in place alongside our network access controls that will scan for MDM and other security software.  I don't know exactly what it checks for (haven't seen the solution yet), but the goal is to prevent network access unless the device meets the security requirements, of which MDM will be one.

I vaguely recall somewhere seeing some sort of self heal or re-enroll process that can be deployed, but I can't find it at the moment.  There are feature requests here: https://ideas.jamf.com/ideas/JN-I-22443 and here https://ideas.jamf.com/ideas/JN-I-22490

@pbenware1 , sounds like you've got a pretty good system there.  We don't have as much of a field support arm, if you will, as you have.  I also have a smart group where machines that haven't checked in over a certain amount of days appear.  Right now though, I'm the only one who does anything with the folks on the list and that is where my heartburn lies.  Maybe I should gather the list and let our L1 or L2 folks hunt down these folks instead of me.

I appreciate your response, you've given me quite a bit to consider.