Device was busy. Will try again

[Lessardrp]

Doing testing in my office and pushing out several commands and profiles to a device. The device is connected to WIFI and has 5 bars signal strength. Everything works great until the screenlock kicks in, at which point, all progress comes to a complete halt. Any commands not executed going into pending with the status message "Device was busy. Will try again".

Seriously, if a device has a good WIFI signal and connection, we should be able to send updates to it. This is clearly related to the screenlock kicking in. Question is, why? Is there some helper service that stops responding if the screenlock is on? Or does the WIFI stop transferring data if the screenlock is on?

What if we tell our people to leave their devices plugged in over night to do a bunch of updates? Will they be pending all night long and then basically make the device useless in the morning when they unlock the screen and want to get to work?

[Lessardrp]

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. 

[obi-k]

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.

[Lessardrp]

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.

[obi-k]

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. 

[Lessardrp]

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.

[Ashok_A]

@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.

[Lessardrp]

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.