Is there a timeout for Jamf API commands?

[ajc196]

I'm going down the rabbit hole of fixing our devices that stopped checking in due to the invalid device signature issue that has been seemingly plaguing customers. I've had great success using Jamf API commands (jamf-management-framework) to get active devices re-enrolled and talking again.

I have a sizable chunk of devices that I've marked as "Unamanged", to reclaim licenses from devices that may have fallen to the wayside. However, now that I know the device signature issue is a thing, I recognize that some of these devices could still be active and not actually stale.

My plan was to send the API command to re-enroll to all the devices that are unmanaged. Based on a test, it appears that the re-enrollment just latches onto the exact same computer record in Jamf Pro, and it carries on with life.

So on that note, how long do these API commands stay queued up before they time out or otherwise clear out? Or do they stay queued indefinitely?  Because my line of thinking right now is to send the command to everything in an unmanaged state, and whatever talks back over a network again will get fixed.. and if it's truly stale/gone, it will stay unmanaged.  But I didn't want to get into a state where I send a command, it times out after [x] days, but then the device actually comes online after [x+1] days or more.

EDIT: Typos

[mm2270]

---

@ajc196 wrote:

...

My plan was to send the API command to re-enroll to all the devices that are unmanaged. based on a test, it appears that the re-enrollment just latches onto the exact same computer cord in Jamf Pro, and it carries on with life.

This is correct. As long as the Mac hasn't had any hardware changes (i.e. the Mac's UUID/UDID is the same) and the record still exists in Jamf, it just pairs up with that record and will update accordingly.

So on that note, how long do these API commands stay queued up before they time out or otherwise clear out? Or do they stay queued indefinitely?  Because my line of thinking right now is to send the command to everything in an unmanaged state, and whatever talks back over a network again will get fixed.. and if it's truly stale/gone, it will stay unmanaged.  But I didn't want to get into a state where I send a command, it times out after [x] days, but then the device actually comes online after [x+1] days or more.

---

I wish I had a good answer to this. My general understanding is that as long as there is no actual error in pushing the MDM command to the Mac, it should stay in a Pending state while it patiently waits for the device to come online.

That said, I have definitely seen MDM commands error out, but I suspect the errors are because of an actual issue getting the payload to the device and not due to a timeout. I've usually seen these errors under the Management tab of a computer that is waiting to get a Configuration Profile pushed to it, so the errors are likely related to an issue with the profile, since in those cases there is actually something to install and not just an instruction like UnmanageDevice.

Someone else who knows more about what goes on under the hood with this may be able to answer your question for sure, but my general sense is that for something like this, it should stay pending until it reaches the device. If it didn't, things like Remote Lock and Remote Wipe commands wouldn't be very useful or reliable, since we can't be expected to babysit these in the console to make sure they don't just die if the machine is offline for x number of days.

[ajc196]

Thanks for the reply! I think I may have the answer though after looking around a computer object. The API command does trigger management commands that show up in Jamf Pro, which should stay pending into perpetuity. I was mistakenly thinking that this would not be the case.