Hey all, we've recently run into an issue where apps that have previously been installed either through the Mac App Store, then removed from our JAMF MAS apps are now prompting users for admin credentials in order to updat (See image).
As you can imagine, this is causing quite the disruption for our users, who are not admins on their devices (And we don't run any kind of temporary admin permissions either).
Has anyone else encountered this and, if so, what was your solution?
- We have plenty of VPP licenses (Around 500 for ~200 devices);
- We use ABM to supply all VPP apps, imported from the old iTunes VPP. Previous licenses were purchased under this account, others bought with a new account under the same ABM.
OMG thank you !
Spent countless hours to understand why Jamf binary and self service wasn't installing.
This option was included in the default profile I use for pre-stage enrollment, removing it solved my problem.
@larry_barrett But would this also apply to exterior apps as well? For example, if someone is looking to install Spotify, we have this available via Self Service, but if I were to disable the "Require admin password to install or update apps", and enable the "Restrict App Store to MDM installed apps and software updates", then only apps on the App Store itself would be restricted. Other packages downloaded from external sites (Such as Spotify, which isn't listed on the Mac App Store) would be able to be installed without admin privileges?
In short: I'd like to retain the prompt for admin credentials when installing an app from anywhere that isn't Self Service, but get rid of the App Store popup when an app needs updating. If that means turning off the whole option, then it kind of defeats the purpose, no?
MDM installed apps should include anything you installed via Self Service or autoinstaller packages. Test it out, report back. This is a 20 minute test on a dummy computer. With both options checked I was able to install Firefox from Self Service (not in app store) and the user was NOT able to use the app store. If your actual question is more about blocking the notification badge icon (the red circle with the # of updates), that's covered in a few threads on these forums. It's a losing battle with Big Sur and not really worth your time. All users can modify their own dock to remove the app store badges if it's just too much for them.
When you update an app from the app store you don't have to rely on the user to do it. Patch management can be your friend here. Personally, I am a believer of letting users update programs via Self Service. It really depends on the app and how granular you need to make the update process for your end users (I work at a school, I'm super aggressive about updates for students and teachers, less so with administrative staff and secretaries). Some update notifications are a dead end without updating to the current OS to Big Sur (e.g. currently Pages, Classroom). We don't do wholesale OS version upgrades until the summer time, so it doesn't really matter if those badge notifications show up in our environment, we're not doing anything about it.
You can tweak some settings for the individual mac store apps that come with your macs (Pages, Keynote iMovie, et al) to automatically update (Computers - App Store Apps - e.g. Keynote and check Schedule Jamf Pro to automatically check iTunes for app updates and Automatically Force App Updates), but you're still going to run into the badge update issue for the same iLife apps that are designed for the next version (big sur etc). There are literally thousands of apps, so YMMV.
A good example for me is Zoom. I don't necessarily support it, but I stay out of the way too. Zoom updates are all handled via Self Service. No passwords. It's actually a bit of deception via Self Service because I'm not updating, just installing over the top to the current version.
Don't believe some random stranger on the internet about your production environment, TEST TEST TEST.
The prompt for admin consent for non-Self Service/Jamf delivered installs should remain even if you un-check that box on your configuration profile. The exception (which still wouldn't have been blocked by requiring admins for installs) are apps that come down in the form of a .dmg and are "drag and drop" to an applications folder - think google chrome. Any (or most) .pkg's should require admin credentials to install because it's invoking elevated rights to complete the install.