Weird, I had the issue when upgrading to 12.3.1 from 12.3.

I finally have an answer for my situation!

What is happening is when the iPads are set to automatically do software updates, they get stuck when our command is pushed out. If you were to turn off those automatic updates and wait the 15 minutes for the OSScheduledUpdate command to push out again the iPad will update. At this point that is the workaround or wait for the device to update at 2am.

Jamf Case: JAMF-0688047
Apple Radar Ticket: 20000054935452
Jamf Product Issue: PI-007214

@ayork I'm not certain, but I don't think I have automatic OS updates enabled on any iPad. Where can I go to confirm this?

@krispayne We have a restrictions config profile so under the payload configuration, it's under the iOS and tvOS, Functionality. I changed ours to defer the software update for 60 days.

Still getting this issue when trying to update tvOS 13 today. We are currently on Jamf 10.15. We do have a configuration profile to defer software updates for 90days, but was under the impression if you force a "remote command>Update OS Versions on supervised devices>etc" to update over the air it would still continue to update regardless of the software update deferral profile we have set already.

Well to test this I went ahead and disabled the "software defer for 90 days" and pushed it out to the test AppleTvs but I am still getting the OSUpdateStatus hanging.

Hi

jamf version:10.15.0-t1567105782

Also can confirm @dubprocess ipad ios update have the same issue here with software deferal updates and command up update the ipad on 13.0 error message Complete The remote command failed to send.

pushing 13.1 has same output.

tests were on ipad MD785X/B air and MTXN2X/A pro

I have opened a support case with JAMF regarding this same issue. We are attempting to go to 12.14.1. We are receiving the same error message:

"The remote command failed to send"

The tech I spoke with indicated there is a known issue with 12.14.

When we attempt to go to 13.1.1 we had no issue. I have sent JAMF the debug logs and a JAMF Summary.

I am currently waiting to hear from them.

Have the same issue now, we have a retail with several iPads in different stores.
Some stores updates iPads without any concerns but some stores you need to manage for a couple of days before it updates.

It seems like Jamf need to release a best practice how to handle the updates.
One thing that would ease up the update handling is to have some information in Jamf on the device that the update has been downloaded and ready to install.

I´ve worked with other MDM-tool which had the feature to display if an update was available which was great and I didn´t see this type of behavior on that system either.

I use to do like this:
1. A couple of days before the update I download the update without installation
2. When the day for update come, I´ll press on the button to initiate the update
3. Waiting game begins...

This works sometimes, but not always which is weird!

I have three iPads now which is not updated... And it seems not to update either... What am I doing wrong or is it just a bug in Jamf? It should be instant as long the update is downloaded.

This issue has been an eternal frustration. Currently requires too much hands-on or user interaction when it should be just downloading, installing, and restarting. Could be because I am running v10.12 currently...

Still does it on v10.16 iOS versions 12 & 13. Cases prevent updates, looking at the update screen on the iPad prevents updates, Updates being turned on prevents updates, having a passcode prevents updates, when by some miracle updates do try to run Apple throttles the connection so it takes 2 days to download it.

Out of about 60 iPads eligible for iOS 13 roughly 40 never updated to 13 at all after pushing 13.0 - 13.2.3 - I walked around to each one and 20 of those are stuck at Update Requested / Estimating Time Remaining for non-current OS versions. By stuck I mean no change after 24 hours - persists through restarts and resets.

Can confirm that we are seeing this same issue. I just reached out to support to get some answers as even one off downloads offsite over the weekend seem to take an extremely long time. Device restart appears to cancel the operation but the limited network usage makes me think it never really was running.

Anyone had any luck with this issue? It's been several months since last post so wondering if it's solved itself, or if we're still in a "this sucks and I don't want to deal with it" state. =/

@rstasel It's been a major improvement since then, in my view. The things that have worked best, and without being able to confirm if they are related are:
1. Turn off automatic update of all devices.
2. As we use a lot of shared iPads, make sure to push and push the info to remember to logout. As we still do not have a way to mass logout users from JAMF. Remind the teachers to use classroom and logout students. As you figured this is in a school enviroment.
3. The command do not succed 100% when pushed out. You have to send remote command, wait. After 1-2 days, cancel command (and failed commands) and resend the remote command. This will somehow help with the bottleneck of deploying iOS (ipadOS) updates.

This is totally unsupported by any logs or whatever, it just is what works for us at the moment.

Thanks! These aren't shared ipads I'm dealing with, but that's a good tidbit.

We're testing with turning off automatic updates.

Will also try removing the "failed" (it's not really failed, it's just sitting there in pending) command. Also going to see if 10.21 fixes the issue since it has some improvements to app catalog updates (we're seeing what looks like an app update is "in front of" the OS update, but stalled.