Device was busy. Will try again

To make matters worse, I just noticed that once the command goes pending with the "Device was busy. Will try again" status, even if I unlock the screen, nothing changes. For several minutes, the screenlock has been off and the WIFI is connected, but the command remains pending with the same message. 

Try following up on all the commands you're pushing out with the Update Inventory MDM command. This seems to jiggle other commands to go through once the device is unlocked.

As soon as another command was sent to the device, all pending commands in the queue were executed so you were correct. But that is unacceptable behavior of the product. What if another command doesn't hit the device for hours? 

Also, organizations have hundreds or thousands of devices and various states at the time of a remote command. They could be connected by WIFI and unlocked and probably okay. But others could be locked and either connected or not connected over WIFI, and the command would apparently remain in a pending status indefinitely until another command happens to kick the stuck command in the pants to get it going.

And considering the very high likelihood of a semi secure sceenlock policy of most enterprise devices, that would mean there's a good change that the vast majority of an organizations inventory has pending commands sitting there waiting for some external trigger to complete.

Yeah. I'm with you.

I don't know if this is an MDM or Apple Framework thing. Or both. Somebody smarter would have to chime in.

And there's no way we're sending an MDM command to clear passcodes so that MDM commands roll through. 

Agreed, clearing passcodes is not an acceptable workaround. If this is something that can't be changed at the MDM level, the only thing I can think of is possibly creating a scheduled task that sends a blank push to all devices at a certain interval throughout the day. That way, if a device is unlocked and has pending commands, maybe that triggers their execution.

@Lessardrp Remote commands depends on APNs even if your Network is stable. Check the Device APNs Connectivity: https://www.jamf.com/blog/test-connectivity-to-apple-push-notification-services/

Also, this could be because device is trying to complete an Remote Command and never ending which you can check from Activity Monitor app > network option. I would suggest to cancel all the Pending Commands from Jamf and send a blank push then check.

This can be the only command in the queue and it will still happen. And the connection can be fine. As soon as the screen lock kicks in I see the status go to "Device was busy. Will try again". Same connection, no other commands. The only difference is the screen lock is on.

I don't know if you ever found a fix for this but we are in the same boat - 700 iPads and at any given time easily half of them are locked because they are not in use. I feel like this never used to happen to me, only time I would see a Device is Busy message was if the device was in first-time-setup, we have never noticed an issue where we couldn't check the inventory if the device was locked until maybe v11(?). It's a PITA and Jamf support are telling me it's expected behaviour and it was always that way.

And it's only inventory updates I'm seeing it with, other commands go through while the device is locked, I can turn off bluetooth for instance. and it will go through and leave the inventory update there because the Device Was Busy

Strongly suspect this is an Apple Device Management framework limitation.

https://developer.apple.com/documentation/devicemanagement/handling-notnow-status-responses?language=objc#Handle-NotNow-Responses

Can't confirm with any references, but I suspect that Jamf is intepreting a "NotNow" response from a device, and displaying "Device was busy" in the UI.

I believe this is directly related to the original issue posted here. I'm seeing the same behavior on macOS where the computer has been rebooted but user has not logged in yet. I think a base interpretation of the issue is 'no commands processed while the volume is locked', whether it's due to screen lock or due to no user logged in. It appears that if the volume is locked, MDM commands will not process.
Answer from Copilot: 

When FileVault is enabled and the screen is locked, it does impact remote access capabilities:

1. MDM (Mobile Device Management): MDM can still manage the device, but certain actions that require the system to be unlocked (like installing software updates that need a restart) might be limited until the user logs in 1

   more or less confirms the behavior we've been seeing.
   

    

I don't know if this has been resolved but I've been seeing this issue and it is extremely annoying. I found that if I do a remote screen share, the act of authenticating for screen share will "wake up" the affected device and commands will execute.  You don't even need to complete the screen share connection. 

You'd think it was the authentication BUT an ssh session does NOT trigger the "wake".