iPad not checking in

New Contributor

I've got an iPad that just refuses to check in. I've confirmed it's connected to Wifi and unlocked. I've also checked the APN in JAMF and Apple. Any suggestions?


New Contributor III

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?

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

I have updated a couple to ios 17 now and they have not checked in still after the update.

Contributor III

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.

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.

New Contributor III

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: 

PI108400 - PI-002187(Third-Party Issue) Device identity certificates may incorrectly be removed from a device, preventing the device from communicating with the Jamf Pro server.



New Contributor III

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

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

New Contributor

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? 

New Contributor III

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.

New Contributor III

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. 



I think there are multiple issues here that have the same symptoms or the same end result.  Some are certificate related, some are OS bug related, and some are network related, it just depends on the configuration of the device and the environment.  It's unfortunate but for the most part the solution, at this point, is to start wiping devices, which for most of us isn't a viable option or is a huge chore because it involves touching hundreds and hundreds of devices, sometimes multiple times.  For us, a cart of 24 devices might have 10 not working, and those 10 will take us nearly two and a half hours to babysit to make sure everything loads again without getting stuck and being in the same broken state as before.

Pretty much exactly what I believe, and our experience much the same. We have ~ 375 iPads across 7 grade levels, and we've touched/re-touched at least half of those. What's most frustrating is they appear to be working, so you deploy, only to have them come back having lost communication in a day, a week, or ??? We've been keeping a close eye on Last Check-in times, to try to get a sense of how many are "lost in space". We seem to be slowly gaining on it. Unfortunately, of your 3 issues, I think we may have some combination of all of them!


I just wiped and set up a 5th gen running iOS 16.5, which is what a majority of our devices have as we updated in May before beginning to work on them, and also wiped and set up 5th gen running iOS 16.6.1 right next to it.  The iOS 16.5 iPad worked in one try, the 16.6.1 iPad bricked mid app install and I'm now wiping and doing it again.  I haven't tried iOS 17 yet (obviously would need to grab some 6th gens or newer) but it doesn't appear to be fixed in 16.6.1.

New Contributor III

Same here. Still see it on 16.6.1.

But I at least got confirmation from Jamf that I am affected by PI108400 and they have a ticket open with Apple. Workaround - Wipe and re-enroll. 

Also got confirmation from Apple that this behavior are known bugs and are expected to be fixed in iPadOS 17 and further releases. Workaround - wait for iPadOS 17

My testing on the betas has been successful so far. Let's hope we get some better timelines during Apple event tomorrow. 


That sounds promising.

We have a lot of 5th gen iPads, most are 6th gen and higher though.

Will be good to hopefully have this fixed in iPadOS 17 (will wait and see), just wish they would backport whatever the fix is.

Looking at Jamf School:

41 x 5th gen
106 x 6th gen
27 x 7th gen
36 x 8th gen
60 x 9th gen
3 x Air 3rd gen
1 x Air 4th gen
1 x Pro 9th gen
21 x Air 2

So that means we have 62 devices that won't support iPadOS 17 and 234 devices that will.
I can live with that, between insurance and replacement due to age, that'll eventually remove those 62 :)

New Contributor

I have updated some iPads that were not checking in and updating them to iPadOS 17 did not get them checking in.

New Contributor

Big picture here. JAMF completely useless? Are there alternatives?

It's certianly starting to feel like that. Honestly, if it wasn't for all the potential security issues of non-managed devices, I would seriously consider giving up on the MDM. But I don't believe it has much to do with Jamf per se - it's Apple's (crappy) not-so-"managed" ecosystem.

Yeah that is a bit of the Jamf line right now but as I am runnin hundreds of Jamf ipads, and hundreds of Meraki ones....only the Jamf ipads are running into this.  They are blaming ASM, but somehow no issues like it on the Meraki side.

I run schools on different systems and although it is not the cheapest Meraki mdm has been great for me.  Far less weird issues like this and a better interface for me.  Support has been very strong as well.  You don't need Meraki hardware, but it integrates into the system as well.

I'm confused. When you say hundreds of Meraki ones, you mean iPads managed by Meraki? When I first read it, I thought you meant Meraki hardware.

Interesting, I haven't had a hiccup with them, especially on the hardware.  For the MDM same thing, much more trouble with JAMF.  Just shows that there are a ton of behind the scenes things people run into is tied to the cloud and issues in the areas as well as roll out of different versions I think.  Just wish there was more info in logs to dig through in Jamf Schools.


Anyway wifi and hardware aside I have found Meraki MDM to be much more stable.

I misunderstood you. My experience was with Meraki APs only. We never used the MDM. I liked their web interface, hated the hardware. But I'm pretty much hating Jamf these days as well, or at least the combined Jamf/Apple experience!


No worries.  Yeah expecially back in the first few years of Cisco owning meraki the hardware was so so.  Most recent roll outs I have had are bulletproof, but of course...mileage will very.  I can say I have never had a device on Meraki MDM stop checking in and not be able to come out from it.  Also, the combination of the hardware and MDM being in the same interface makes fora  lot of simplification and cross data collection but...other story there haha.


Anyway, main issue, if Jamf tells me one more time it is an ASM issue and I still don't have a  meraki host going nuts I may lose it.  Good luck on your jamf fight!

Well Like you.. we use both JAMF (Macs) and Meraki (iPads). Don't ask me why.. LOL I walked into this setup a few years back after our MDM specialist left and they could not find anyone to do what he did for what they pay.... haha. I ended up getting in to try something new. I'm actually having this issue on Meraki managed iPads but cannot find any way to fix it. For the most part for us. Tickets started coming in this fall when school started and after our network team upgraded all of our Aruba access points throughout the district. I am one guy managing 4k+ iPads... I had an open ticket with Meraki and they pretty much said that all they can see if if the device is online or offline... Pretty Bad. I have a lot of teachers just giving up on the use of the iPads.  

New Contributor III

with my case that I had open with Jamf, logs were pulled from a device that stopped checking in for no reason. Confirmed we are running into PI108400.  Only two solutions is to create and airdrop/email an new enrollment profile to the affected iPad, or wipe and re-enroll. since our profiles are not removable, we had to go with the latter. Per support: "This is a third-party product issue with Apple and I do not believe there is a fix at this time." 

New Contributor III

Have this issue to with random iPads. Oddly the iPad is still able to communicate with Jamf, so if we update it to iPadOS 17, the version is updated in Jamf Pro, and if we request an app from Self Service it becomes queued in the pending commands but Jamf Pro itself never seems to send the command to the iPad. I did raise a case with Jamf and they seemed pretty uninterested and told me to just wipe it.

Contributor III

Lately I have seen this issue caused by students putting the iPad into Low Data Mode.  The iPad stops checking in and apps stop updating.

Interesting bfrench I just had a user say that was coming up but didn't go down that rabbit hole.  Will have to check it out.  Looks like no way to control that in wifi or profile settings to stop it from being an issue.  Any ideas on how to stop that would be great but I have a feeling there is just no way to control it.

New Contributor II

Seeing these issues as well! 


We re-wiped around 1/3 of our K-4 iPads in the first 3 days of school (roughly 500 5-7th gen iPads) to get them working as they should've been after the summer work.  It took a lot of patience watching their app installation process and many required multiple wipes over and over, as many as 4 or 5 tries even, to ensure they didn't break again.  Otherwise just wiping 500 iPads once and letting them sit in their carts to finish could've been done in one day. Thank god it doesn't affect 8th gen and newer as we'd easily have had 1000 or more iPads to fix at the beginning of the school year, and our 8th gen and newer iPads aren't kept in classroom carts so we'd have to get them from the students individually.  We have another probably 100 or so that have broken again since the last go around and will need to be dealt with soon as they aren't receiving any app updates or new app install commands now.

When we setup a 5-7th gen iPad for a new student you can get lucky sometimes and set it up one time and it'll be good to go, or sometimes it takes 3-4 attempts to get it to complete the app installs without breaking.  Since 5th gen iPads won't be getting iOS 17 we're going to have to stop wiping them each summer for the next group of students or just struggle through getting them to work.

New Contributor

With in your JAMF wireless profile setting, assure that your Legacy Hotspot is enabled (Mobile Devices - Configuration - Profiles. Create your wireless profile (in my case, I called it Wireless). Under Wi-Fi, find Network Type. Select Legacy Hotspot


New Contributor III

For context, a similar incident occurred with us, but we quickly understood the reason behind it. Lately, we have been facing some problems with log retention and were instructed to clear out pending, canceled, and hung-up requests. While doing so, inadvertently, we canceled some pending MDM renewal commands just days before they were supposed to expire, leading to the issue. 

TLDR: A command set to renew the expiration of the MDM profile may have been canceled (not confirmed but highly likely), which in turn caused the issues. A quick reset of the device can fix the problem and is what resolved it for us with the few devices that had this issue.