Delete computer from JSS through Self Service

New Contributor III

I have created a policy in Self Service that will erase and reinstall Mojave. This policy is scoped to all computers with limitations LDAP Group (admins), so when we log into Self Service on the computers, the policy is available for us.
However, how can I delete the same computer from the JSS inventory through the same policy? I want the script to find out the current computer's ID (Jamf Pro Computer ID) and then through the API delete it from the JSS inventory, but since I can't scrip, I need some help on the way.


Legendary Contributor II

Is there a reason you would be deleting the machine from the Jamf Pro server during a wipe and reinstall though? If the reason is to get policies set to once per computer to run again, you can set your preferences in Jamf Pro to reset all previously run policies, and Config Profiles and other options on a re-enroll so they will get run again.

If this is wanted because you are selling these devices or giving them to end users or something, then it would make sense to remove them from your Jamf console.

In any event, the general idea is to do something like the following. You can use Serial Number or Unique Identifier or computer name among others to locate the machine in the API, but my preferences is either Serial Number or UUID since they are the most reliable ones to use.


APIUSER="apiuser"  ## Change to your API user account with delete computer privileges
APIPASS="apipass"  ## Change to the password of the above API account

JSSURL=$(defaults read /Library/Preferences/com.jamfsoftware.jamf.plist jss_url | sed 's|/$||')

UUID=$(ioreg -rd1 -c IOPlatformExpertDevice | awk -F" '/IOPlatformUUID/{print $4}')

curl -su "${APIUSER}:${APIPASS}" "${JSSURL}/JSSResource/computers/udid/${UUID}" -X DELETE

I just typed in the above right in this post, so I did not test it. But it should get you started. Be careful when testing it of course!
Also, consider using script parameters for the username and password and passing those to the script at run time instead of hardcoding them in. The account you use there must have at least delete privileges on computers, so it's usually best to protect those accounts by not hardcoding the values into the script itself.

New Contributor III

Thanks for the input mm2270

When a user is working their last day at work and returns the computer, then we usually erase the disk and reinstall the macOS, while waiting for the new user to take over. We leave the computer in the enrollment stage "remote managed window", so that it assigns to the next comming user. Since all of our mac users are local admins on their computers, we always erase the computer and install a clean version of macOS before giving it to another user.

Instead of including the username and password in the script(hardcoded), is there any way that the script can grep current username and passwords from the logged in user in self service?


@Gonzalo my interpretation is mm2270s script is all about coding a username and password that allows the Macs to be removed from Jamf which would be a Jamf Pro user account rather than a local user account with admin rights.

You’d add his script as a regular policy with a custom trigger and enable it to be used in Self Service - then scope it to users who are entrusted with provisioning Macs at your place or to the Macs you’re wanting to be removed from Jamf.

Mm2270s script in a policy would all be run before the new user ever encounters the Mac and maybe even before you wipe it and reinstall macOS readying it for provisioning again.