Seems to be about the same likeliness that they will break even when not moving them.  If we pull say 6 out of a cart of 24, after the first wipe 4 of them will break after a few minutes, then after wiping the 4 a second time, 1 will still not work and need a 3rd wipe.  We have a ticket open but haven't heard anything back yet.  We've let teachers know unfortunately the iPads aren't ready and we're working on it.  But if the 1300-ish in 5-8 have the same issue its going to be a long few weeks.

When you wipe them are you also deleting them from Jamf?

Sorry if you've said this already, but are you deleting the records out of Jamf prior to setting them back up again?  If not, try that.

Also, are they switching to a new SSID from a profile that is installing from Jamf?  I don't know your wireless environment, but does that profile have the random mac address turned off?  I would doubt it would have any affect on your environment unless you are doing MAC address filtering, but just something to try maybe.

During the summer we delete all student devices as we're working on them so they unscope from all apps, keeps them from "loading up".  Staff are the only iPads we don't delete.  Right now we are deleting the ones we're fixing as well.

They do switch to a new SSID from a profile after they are setup but seems like they stick to the unprotected one we use for setup until they start switching AP's, the one from the profile must have a higher priority for it to choose it first.  We did type the password into the SSID manually for a while yesterday, the same one that comes with the profile, and still were getting the random 1/3 or so that would break after a few minutes.  We're waiting for the apps to finish installing, then if we can get a bluetooth enable command through it seems they're okay.  If they get stuck in the middle of app installs or wont take a bluetooth/MDM command of some sort after then they're broken and get wiped again.

I should point out, we are using Jamf Pro.  I got to this thread from Google 😅.

Add my district to this long list - thread is over a year old! I honestly don't know why we put up with this crap. We manage tons of products from Linux to ChromeOS to Win, and NOTHING gives us anywhere near the pain Apple's $@!% does. 

Rant over. The additional problem we're facing is that they don't re-enroll cleanly, so wiping isn't really an option. They start the prestage/remote mgmt process, then "blip" they go to the generic/unmanaged setup screen. Haven't had time to try to figure that out yet, but it's not the first time or year that's happened.

The only thing I've had partial success with is to manually apply our wifi profile via Apple Configurator. For a good number that weren't checking in, that seemed to get them talking again. And for a smaller number, updating to the latest IOS worked. But we still have at least 2 grade levels where the majority are not checking in, and consequently we have an out-of-date app (i-Ready) that they are trying to use to do assessments here in week 1. Aargh. This has been going on, with minor variations, for years. I sure wish Apple would get their APNS communications "triangle" sorted.

We use Jamf School, so about the only certificate we can deal with is the APN certificate.

We have around 30 iPads not checking in, some are because the battery just went flat, easy solved.

Most however are because the Jamf Cloud certificate is unverified, and when I look at it, it's because it expired.

Best I can work out is that the certificate likely expired when the device was off-wireless (most likely flat at the time), then when the device was charged up again, it gave up trying to check-in.

Why the device is unable to get a new certificate I will never know though.

I have had some luck hotspotting the iPad to my phone, that gets it to check-in once, but then never again, even using my phone as the hotspot.

The only solution I have found so far is to wipe and re-enrol the device.

But that isn't a permanent fix for some of them, I have at least 3 iPads where I wiped them, then the very next day they started showing signs of not checking in.

In all cases, the iPads are being used by students, on the internet, with wifi (WPA2-Enterprise) working 100%.

Same here! Does anyone have open support case numbers I can reference? It started happening to us at the end of last school year Apr-May but it's a lot more apparent now that we re-enrolled everything. Oddly enough, we refreshed a large majority of our iPads (to 9th gen) and none of those are having issues. We kept a lot of iPad 7's and those are hit-and-miss on communication, app downloads, check-ins, etc. 

In talking with Apple this is an issue that has been seen since around 16.3 supposedly, too many app install commands cause things to come to a halt and nothing will continue until those app install commands are complete.  They also said this only happens with 7th gen and older, which explains in our case that our 2nd grade and 5-8th grade iPads are totally fine, they are 8th and 9th gen.  We've found you can delete some of the currently installing apps that are stuck to get things moving sometimes, but thats hard to keep track of with a dozen iPads doing the same thing and being in a different state of setup, and sometimes it still refuses to continue.  Supposedly this is fixed in 17, so we were going to try the beta on a few but with it being hit or miss its hard to tell.  We are wanting to restrict the erase all content and settings option on all of our student iPads, we unrestrict that while we work on them in the summer, but have waited as we can't wipe them from Jamf if they aren't working.  If they're stuck, you can delete the apps that are installing, send a wipe command, then restart the iPad and usually it'll let one command through when it comes online again.

Did you open any support cases with Jamf or Apple? I have open but if we could reference each others, in addition to this thread, it might help them see the urgency. I can't wait until 17 drops and find it mindblowing that this would only affect 7th gen and older devices. 

We had this happened to a few devices last year.  As devices are turning on with the start of the school year I have seen a few suddenly that have certificates that have expired.

Very interesting post! Thank you for that information, it validates much of what we've been seeing. As I said above, we have the added difficulty that we can't re-enroll devices after they've been wiped/deleted (a separate unresolved issue), so we're really restricted to a few things we can try to get them working. What we're finding is that, even when they do start installing apps, they will "stall", never completing, and most importantly, never checking in with Jamf Pro. Even if we clear all commands, when they start getting their app suite again, they often freeze. At that point, since we can't re-enroll, they're essentially bricked - or at least unmanaged, and therefore no use to us. 

And the generation thing is exactly what we're seeing. The new fleet of 9th gen's are working perfectly - the problems are all with old 5th gen's. Surely this wouldn't be Apple "unintentionally" obsoleting older devices would it? 

I don't, we've been working with an Apple engineer this summer on some M1 deployment stuff so I emailed him our "overview" of this issue and the console logs of an iPad from the setup screen to being stuck, and he said he as seen that with some other schools recently.

I don't think this is our issue.  We try to keep most certificates expiring during the school year as the most number of our devices as possible are out being used/running.  Any that expire during the summer we renew before working on devices so they just get the new.

Are you seeing 9603 errors in your VPP logs? My initial support case with Jamf was opened because of this. More recently, we started noticing most app stuck issues were primarily being reported from my 7th-generation iPads.

Also, we're finding updating to 16.6 helps "move things along" but requires multiple reboots (at least 3-4) before things start acting somewhat normal and communication to Jamf is restored. I'm going to try a mass push to get iPads updated, but the dilemma is if they can't communicate properly with Jamf, then that command won't go through...

Yes we are, 9603 several times in between each “Running license monitor” and “license monitor complete”. We are having a hard time getting Epic and Google Slides to install. Each goes from pending install to still pending with “The device was busy. Will try again.” Then from there it will be a failed command “No license was found for app com.getepic.Epic/com.google.Slides”. Some iPads will install both just fine, others will take one and not the other, then some take neither. I’m not sure if each 9603 error is for a certain app that’s not working and we haven’t found out yet that 2 or 3 others aren’t working or what. Anything online about that failed command error says to refresh that license in the VPP settings, but that functionality was either deprecated or removed in the last year. I can’t remember what version number to see if the release notes say why, though. I do now have a ticket open with Jamf for the not installing Epic and Google Slides apps, I created it at 4pm though so no response yet. I have assumed the bricking and failing app installs are separate issues, but if fixing one fixes both that would be amazing at this point. I am now concerned that if too many app installs bricks an iPad, all of our iPad apps are set to automatically update. If it’s only like 3 commands is all that it takes to break it, what happens if 3 developers release updates in one day and Jamf finds that during the 1am App Store check and just bricks all or most of our <8th gen iPads on one shot sending app updates?

This issue started occurring for us once we upgraded to from 10.42.1 incremental to 10.44.0 then to 10.47.0 over the summer. I thought this was happening because the device hadn't checked in in a while, or an expired cert, but after reading through this thread it is likely I am experiencing "PI108400 - Blank Device Identity Certificate causing devices to no longer communicate with the Jamf Pro Server" as a user @opeura stated above. I saw 10.50 recently released but the PI still exists and has an updated description: 

I am currently experiencing all the issues everyone has been mentioning here and referred me to the same Third Party Issue - I have attempted wiping manually a few and even after reset they seem to brick and no longer proceed with installing the applications. Even try bypassing some IPs on our firewall to allow all forms of communication on the iPads and nothing seems to work. Yes I have seen some ipads work after rebooting 3-4 times but that is very tedious as I have a fleet of 500-600 iPads to reset. Even then majority of the fleet out here is 7th generation and its causing us delays as we are in the same i-Ready situation. Has anyone come across a resolution for this? Or are we still waiting pending the information from Apple regarding this to be "resolved" in iOS 17? Any form of insight would be appreciated. I am on JAMF School program.

Interesting... that makes sense why devices would stop communicating, but it still doesn't explain why I'm only seeing it on specific models (only my 7th gen iPads). We've had some success with wiping and re-enrolling, but after a few hours or days things get "stuck again". Is there an easy way to determine whether or not we are affected by this specific PI? Is the cert itself gone from the device when looking at the MDM profile in settings? 

We've also been exploring some potential content filter/VPN policies we have in place that are potentially causing some interruption. The resolved issues page for iPadOS 17 lists some related fixes for VPN and SCEP certs:

(Beta 3) The allowVPNCreation restriction no longer prevents MDM from installing VPN
payload.

(Beta 5) SCEP requests no longer fail with certain server configurations. Please test
enrollments and configurations that rely on SCEP in this beta.

Has anyone else tried the iPadOS 17 betas and determined it resolves these issues? I've had good success with a few devices I've tested on. But that still leaves us in a hurry-up-and-wait state...

So, I tested out 8 new iPads from our new fleet we received 9th generation and they loaded onto JamF enrolled and pushed out all Apps simulteanously without issues. Is it safe to assume that this issue is only affecting iPads 8th gen and older? 

No, I have several 9th gens that have the same issue.

What I have noticed with a lot of the ones I have had to wipe and re-enrol, is that prior to wiping them, they had an expired Jamf Cloud certificate (We use Jamf School).

Even weirder, is that a couple with the expired jamf cloud certificate, the certificate expired in March-2022, however these were devices that I wiped and re-enrolled in June/July-2023.

It's almost like sometimes Jamf School is giving the correct certificate, and other times it is giving an expired one.

Maybe Jamf haven't updated all their cloud servers to have the correct certificates.

I can understand if a certificate expires, communication is lost, but I think most of us are seeing situations where certs are still valid. Yet, communication with Jamf is randomly lost or never fully established correctly.

I've had iPads that have been okay for months, then suddenly stop checking in. Others I've just enrolled and, for some reason, never get the proper "checks" to continue working. I lean heavily towards some kind of interruption happening at enrollment that's causing my issues in particular. Whether that's the Wi-Fi profile that kicks in or a content filter app and accompanying profile that gets installed. The device looks fine on the surface, but on the backend, Jamf just isn't trusting it and subsequent apps and commands won't go through anymore.

Whatever mechanism (if it exists) to verify, and more importantly re-establish connectivity to Jamf, isn't working. Having to wipe and re-enroll is not a valid solution. Maybe for a handful, but when you're dealing with hundreds to thousands it defies the simplicity of what an MDM should be helping with.

One tidbit here. We have found that if we use Apple Configuration to "Update" the iPad, it seems to shake things loose. Of course, if the iPad is already up to date, that's not an option. Since 16.6.1 dropped, we are now able to use that method for a few more to get them working again. Convoluted and weird, but it works. Due to how we have our config profiles set up, we have to subsequently re-apply the wifi profile (also via Apple Config), but then it starts communicating as needed. 

Same.