Best way to observe JSS Enrolled systems being Erased or Redeployed by non IT members.

Question

Hello, to clarify my request, Unfortunately I work in an environment where we are still trying to implement a centralized IT management culture, also known as &#034;If you dont work for IT dont change stuff thanks&#034;

Anywho, Im trying to figure out a way to monitor or make a smart search in the JSS or using an extension attribute to see when a system has been erased and rebuilt by a process that does not include the following standard elements we would do in IT:

Erase and reimage the system using Deploy studio, Which rebuilds the OS, among other scripts, sets time , binds it to AD ect

Renaming the system to the correct Syntax for the new person using it, Currently our naming convention is ZA(Department Letters)Last 6 of SN or something like this ZAENH9GG7V

having the user login with new AD credentials, creating a new home folder with their AD name as shortname

In our JSS, some systems show up as having (2) in the names like ZAENH9GG7V(2) , which means they most likely did not wipe the system, and just used migration assistant to transfer everything including computer settings which will use the same name from the Host System.

in some cases, the systems do end up getting totally diffrent IP address due to being moved to a different subnet in the building so a network state change also may take place in most of these situations.

So im trying to think of the variables that do not get changed correctly when its not put thur the correct process and find a way to track down those systems and correct the users ect.

We do not currently have firmware passwords on any systems in the environment which would block this issue all together, We may look at implementing this. Regardless that would not resolve the Naming convention not being corrected and also me being able to inform my Asset manager that an asset has changed hands.

tlarkin · Answer

Hi @Gabriel.Duff

I have done similar things in the past by using a simple script and a flat file in .plist format. Then use extension attributes to track those specific flags. For example when a device is imaged or provisioned using the standard workflows IT has created there is a post provisioning script that runs through a few logic checks and write to a plist file. So for example you could do something along the lines of this (not tested writing this from the hip):

#!/bin/bash
lastImageDate=$(date "+%Y-%m-%d")

defaults write /Library/Application Support/JAMF/com.myorg.provisioning.plist provisioned true
defaults write /Library/Application Support/JAMF/com.myorg.provisioning.plist LastImageDate ${lastImageDate}

exit 0

Then you can have an extension attribute read that flat file at recon, and if any value comes up blank or not what you would expect you know it was not provisioned by IT. From there you can put it into a smart group or saved search for reporting purposes. If it doesn't have "true" result or a date stamp you know that it was wiped and reimaged by a non standard IT workflow.

Of course there are probably tons of ways to accomplish this but this is how I have done it in the past.

Hope this helps.

Cheers,
Tom

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded