PI-009041 Jamf attempting to remove unmanaged apps

Hi, Sandy.

I just noticed this today while I was checking on a managed iPad. My google search led me to your post. In my case I do not have any unmanaged apps being removed, at least not that I've noticed.
Also, I'm relatively new to Jamf. Can you tell me what is meant by PI?

PI-009041 is the code from jamf, how they track current open product issues. I did not find this one on the published list but got it from support when I opened a ticket
I have had 4 instances of Apps being removed but so far have not been able to backtrack why on this small number of iPads and not the others.

I am getting reports of UNMANAGED apps being removed from Teacher iPads.
These apps were downloaded from the App Store with a personal Apple ID.
I am unable to isolate the particular situation that allows this to happen, since we have 500 staff iPads similarly managed and App Store in use, but a small number of apps being removed (....so far)
It has been individual l apps, and a different app on each device reported....
Nobody else is seeing this?

I'm still only seeing the errors themselves, but I haven't gotten any support calls from the iPad owners.
I really hope this gets sorted out soon.

Remove App - ZOOM Cloud Meetings 4.6.2 The app “us.zoom.videomeetings” is not managed. 10/30/2020 at 9:00 PM Remove App - Facebook 310.0 The app “com.facebook.Facebook” is not managed. 10/30/2020 at 9:00 PM Remove App - Google Docs: Sync, Edit, Share 1.2021.06204 The app “com.google.Docs” is not managed. 10/30/2020 at 9:00 PM Remove App - Google Slides 1.2021.06207 The app “com.google.Slides” is not managed. 10/30/2020 at 9:00 PM Remove App - Canvas Teacher 1.8.5 The app “com.instructure.ios.teacher” is not managed. 10/30/2020 at 9:00 PM Remove App - Google Drive 4.2020.48302 The app “com.google.Drive” is not managed. 10/30/2020 at 9:00 PM Remove App - Microsoft Word 2.47 The app “com.microsoft.Office.Word” is not managed. 10/30/2020 at 9:00 PM

I think I have found what triggered the removal, but cannot prove it yet
While working on a different issue regarding VPP Codes, we were no longer able to acquire an app from Self Service where we had known good VPP codes uploaded to jamf. As a result of that testing, I disabled the Codes Catalog items and removed staff from the scope. I uploaded all my remaining good codes to Google for techs to pluck manually for new staff.
That event (I think) triggered "some" unmanaged App Store Code Acquired apps to be REMOVED FROM DEVICES.
Ironic that Waaaay back when, we distributed codes to staff so they would "have the apps forever" and never need to worry about them losing scope...
So I re-enabled and re-scoped those non-functional codes catalog items and am now holding my breath, trying to think of a way to evaluate the size of the ShitShow. Not everyone redeemed every code. First person today did not have an iCloud backup that went back to before the app was removed so files are lost.

There's nothing worse than finding out the bugs and limitations of a product because it affects our users. I hope it works out!

Well... since I do not hear from anyone else on this issue, I'm going to accept that the environment that triggered this is quite an anomaly. Having a VERY mature jss, in a district that had student iPads on the cutting edge 10 years ago, I am not bitter :)
Those early days, PRE- VPP and MDM were crazy and some decisions made back then based on "What we had to work with" sometimes return to bite us.
"Kids will still learn".
S

Hi Sandy,

We are seeing this in our environment also. Running 10.27, cloud-hosted. On a support chat now with Jamf and found your post.

"Make app managed when possible" can be deselected if the distribution method is set to "Make available in Self Service".

Deselecting that option appears to stop the failed commands. That said, it's still unclear why this would have any affect on devices that aren't in the App scope.

In our environment, this has nothing to do with converted codes, as it is affecting apps where we acquired the licenses after moving 100% to VPP.

This is also happening in my environment. Running the same version of JamfPro.

If your'e self-hosted, you can alter the "Make app managed if currently installed as unmanaged" flag in SQL. It's probably not supported, but it can certainly be done. You're looking for the take_over_management field in the mobile_device_apps table. The following will show you all apps that have "Make app managed if currently installed as unmanaged" set.

select app_name,mobile_device_app_id,take_over_management from mobile_device_apps where take_over_management = 1 and deleted = 0;

Hey @cbrewer, thanks for that, however we moved to the Jamf Cloud last Wednesday :)
I am working with a jamf engineer currently to find additional information and possible remediation.
S

Hey folks. Just to say I'm also seeing this issue in our on-prem instance. I was confuzzed as to why most of our iPads have failed 'remove' commands for all sorts of Apps that weren't even in scope for the devices in question, and here we are. Hopefully this can be resolved swiftly as I'm in constant worry that those commands will eventually be successful!

Posting to confirm I see this in my on-prem instance as well. The issue seems to be tied to the "Make app managed when possible" field being checked, which also looks like it cannot be unchecked unless you switch to Self Service install.

Having this issue as well with staff devices. Current on-prem version is 10.28.

It's the same in our environment, on-premise, version 10.27. I've been seeing this behavior for several months+. I put in a ticket with Jamf and finally gave up due to no solution. They asked tons of questions that I felt were mostly unrelated so it became frustrating. What's interesting is none of the apps in question are even scoped to Staff iPads. 

I recently had the same problem with the app management error and so I reached out to Jamf support. This is what we figured out together. Hope this helps everyone!

"To recap, the reason we were seeing Remove app - The app “AppBundleID” is not managed for some of our applications was due to the application record being within Jamf Pro and the user installing the application manually.

When we do this, Jamf Pro sees the application on the device, Jamf Pro then thinks that the application shouldn't be on the device because the device isn't in the scope of the application record in Jamf Pro. So it tries to remove it. Being that the application isn't managed by Jamf because it was installed by the user, it presents the failed command of, Remove app - The app “AppBundleID” is not managed.

In order to resolve this behavior, we need to do one of the following:

1. Add the device to the scope for the application record in Jamf Pro, check the box - make app managed if currently installed as unmanaged
1a. This then adds an application license to the app and makes it managed

2. Remove the application record from Jamf Pro if it is not needed. For example, the Facebook app, if we don't need to deploy this app and users can install it themselves, let them install it themselves and remove it from Jamf Pro so Jamf Pro isn't trying to take over management.

3. Let the failed commands be there and ignore them knowing Jamf Pro won't be able to remove the app due to the above-discussed behavior. (Note - if we have 17 failed commands for apps, on 1000 devices or more this can cause performance issues depending on the environment. It would be recommended to use option 1 or 2)."

Having the same issue... Apps won't remove because they are "not managed" but when you look at the same devices installed apps list they appear as "Managed". I'm not sure where the disconnect comes in at here but when one screen says they are managed and another says they are not something with the management software is off.