
(If you’re interested, you’ll find response examples for each API here: ) Using grep, we determine if the failed node is empty or not, and if failed commands exist will then trigger a commandflush for the machine. Normally, if any failed MDM commands exist then you would see tags in your response, but if no failed MDM commands exist then this is empty, producing a tag. Because the API doesn’t allow you to filter these commands to just those that are failures, we pass the results to xpath whereby we can gather only the XML nodes we care about.
#Jamf pro api serial
"Īfter collecting the local machine serial number, it queries the Jamf Pro Server via the computerhistory API to read the MDM commands for the given machine. bin/echo "Removing failed MDM commands … " # Clear failed MDM commands if they exist Parseresult= $(/bin/echo " $xmlresult " | /usr/bin/grep " " ) # An empty failed XML node will look like this: Xmlresult= $(/usr/bin/curl -sfku " $apiuser ": " $apipass " " $jssurl ":8443/JSSResource/computerhistory/serialnumber/ " $serial "/subset/Commands -X GET -H "accept: application/xml " | /usr/bin/xpath "/computer_history/commands/failed " ) usr/bin/curl -sfku " $apiuser ": " $apipass " " $jssurl ":8443/JSSResource/commandflush/computers/id/ " $computerID "/status/Failed -X DELETEĬomputerID= $(/usr/bin/curl -u " $apiuser ": " $apipass " " $jssurl ":8443/JSSResource/computers/serialnumber/ " $serial " -H "accept: text/xml " | /usr/bin/xpath "/computer/general/id/text() " ) Serial= $(/usr/sbin/ioreg -rd1 -c IOPlatformExpertDevice | /usr/bin/awk -F '" ' '/IOPlatformSerialNumber/ ' ) Your API user just needs the following permissions: There are tools for obfuscating these credentials so you don’t have plaint text usernames and passwords in scripts on your server. If you’ve not used the Jamf Pro API before, in order to query your Jamf Pro server you’ll need to pass user credentials. This way we could both identify and clear any failed commands in one step, rather than having to create a separate policy for handling the removal.
#Jamf pro api update
A big thanks to our machines update inventory once every day, I opted to modify the shared script to be used in an extension attribute. I had no prior API experience, but a fellow Mac admin was kind enough to share a script with me. Thankfully, Jamf has a commandflush API to remove all failed MDM commands given a device’s JSS ID. The problem with both of these methods is that it requires you to keep your eye on all of your profiles to monitor any failures and then clear them manually, either for all your machines or for a filtered subset.


Jamf provides two manual ways of clearing these failures:

Within the Jamf Pro web interface, you’ll see all these failures in the “Failed” column within computer Configuration Profiles.
#Jamf pro api install
For one reason or another, configuration profiles will fail to install on macOS devices.
