We are extensively using VPP and device-based assignments. 600 apps are scoped amongst our ~100 smart groups - always installed as managed apps.
We are finding that when we remove a device from the scope of an app, it doesn't always remove the app from the device. We do get the license back in VPP, but the app stays on the iPad even after inventory updates and restarts. The only way to get the app off is to manually delete it from the iPad.
Has anyone else seen something similar?
The main problem here is that we restrict student iPads from deleting apps.
Most of those iPads are only 16GB models, so they are low on space to begin with. Certain huge apps (I'm looking at you, Lexia Core5) just need to be removed from time to time. When JSS doesn't actually remove them, we have to unrestrict the iPads and manually do it... that's less than fun.
Second what @mahughe said its an Apple thing and for some reason they don't force the app to removed. This is expected behavior though. I know it doesn't help you much. This is why we don't force the apps to delete or force the apps on the device. Why don't you make the app available in SS and let the students download as needed? This would really help you with your storage issues. We are in the same 16GB boat as you.
I thought the grace period applied only to user-based assignments, thereby giving the assigned-user time to either buy it themselves or export their data/settings before the app vanished.
I've been under the impression that with device-based assignments, the organization has complete control over what apps are installed at all times, with no grace periods.
Self Service isn't in the cards for us as we are dealing primarily with a special education student population, so we aim for the most simple and consistent usage environment possible - therefore: device-based assignments and no app deletion.
"Complete control over " and "Apple" don't belong in the same sentence. I am continually frustrated with what I CAN'T control - your example being just one of many. In my opinion, Apple products will NEVER be enterprise-friendly until they get over the "end-user is sacred" mindset.
And yes, I have experienced exactly what you're describing with multiple apps, including Lexia. At least the Lexia "app" itself is free, but that doesn't help if you're trying to save space.
Alright I have a specific example now:
These are the apps that were not removed in this example (bold are apps that I know for certain are definitely managed-capable):
Bugs & Bubbles
Bugs & Numbers
Duck-Duck Moose Reading
Number Pieces Basic
Write My Name
Definitely something wacky going on. I don't know if it's our JSS or if it's iOS, but I'm leaning to a bug in the JSS because the Remove App command is not being sent for all apps.
Some further testing:
Unfortunately that's not really a viable solution when we're dealing with dozens of apps on dozens of iPads.
It seems like maybe this is a JSS issue with not being able to handle a large number of commands at one time?
Your last sentence caught my eye. I've been wondering about volume of commands, as in testing (approx. 10 iPads, half-dozen apps) everything worked fine, but when deploying to 300+ iPads, a lot of them never get the app installed, and the dreaded "app already scheduled for management" error in the failed command. Clearing the errors and updating inventory works to some degree, but comes to a point of diminishing returns, and I end up with a handful of iPads that never received the app. I have attempted un-scoping/re-scoping, and then I end up with some that seem to be in an endless loop of uninstalling/reinstalling the app - even though there are no pending commands! Which is probably even worse. I have an open case on this since early last week, but so far no resolution.
I have been seeing this as well. I don't have concrete examples at this time. JSS 9.93
When I reported it I was told it should be working (unscoping sends the Remove command). I then realized that in some of the cases I had the same app scoped twice to the same iPad (push install vs. Self Service) so closed the case. Since then I have been seeing it is definitely a problem at times.
I've been buried this month so haven't had time to do any testing but I'll be following this thread carefully.
At this point we have most apps installed (less a handful of stubborn iPads), except for Google Drive. Even though it is installed on some unknown number of iPads, the JSS thinks it is installed on only a couple. However, 'updating inventory' no longer triggers an install of that app - which it used to. At this point, I'm leaning toward there being an issue with the JSS database, either not logging inventory correctly, or some db trigger that hasn't been updated correctly, or ???
I'm thinking of a work-around, which would be to create a single "generic" Apple ID (not managed), that students would use, and then use Self Service to install the stubborn apps. I'm hoping to leverage a config profile with a restricted app list to keep rogue app installs under control - anyone done that? We had planned on not using Apple IDs at all this year until we went to Managed IDs (a whole 'nother story), but we may need to break down and go "old school" just to get the kids working.
We have been seeing the same issue also with our iPads and noticed that doing an edit and save action (without any actual changes) on the app actually triggers the removal action. We currently have a workaround in place by automatically checking using the API the scoped apps (smart groups / static groups related) versus the actual apps (inventory reported) and doing an edit/save action on the apps that are out of scope but still installed to resolve this. Issue is reproducible and looks to be MDM related. Since the workaround is in place everything works as desired.
We were experiencing this same issue, where we excluded a smartgroup from the scope of an app (in hopes the app would be removed off the devices in that smart group). But the app was never removed from the devices. I tried @JurjenEisink work around posted above (edit and save action on the app) and magically the remove app commands went through and the app is now removed, thanks @JurjenEisink !
We are cloud hosted and on version 10.6 for reference and are using device based VPP assignments.