Microsoft Office is my first experience with VPP. It doesn't look like the end user can manually update the apps, instead it appears that the updates have to come from Jamf (either through update automatically, or clicking force update).
Both of the above options would kick off updates for all clients. Is this the expected behavior?
Ideally I'd like to be able to manually update my own apps before clicking force-all updates just to make sure there aren't any issues. Anyway to do this?
It sounds like the behavior your are looking for is to uncheck the "Automatically Force App Updates" option for the office apps, and then use the "FORCE APP UPDATE" button once you have verified the app updates are ok.
The easiest way to do this is to install the apps manually on your own device via the App Store (using a personal Apple ID), and update them via that mechanism. This would allow you to avoid duplicate app catalog items with exclusionary scope, different update settings, and the associated confusion that may arise.
Thanks, that may certainly be the route I have to go.
Is there no way for an end user (with or without root permissions) to manually update a VPP app on the Mac itself? Or must the update always be initiated from the MDM side?
I thought I'd try reviving this old thread instead of creating my own since I have the same question. Once you've deployed an app, can a user click update in App Store to update it, in Self Service, or any other option besides forcing the updates out? I've searched throughout JAMF Nation and can't find a solid answer. I'm fairly new to VPP as well, with this year being our first totally imaging-free experience.
I'd also like to bump this. I've been playing around with VPP a little more recently on macOS and the implementation seems poor.
I have apps set to not automatically update. Once I'm ready to update them, the only way to do so is by editing the VPP app and clicking update now. This presents two problems:
1. All of the computers get the update at the same time. I have content-caching configured though I am still concerned of potential bandwidth issues.
2. If the computer reboots before the update completes, they never resume the update. It seems like macOS does not retry at next reboot, and Jamf does not keep track of this to send another update command to the device.
Any ideas on how the above challenges could be improved?
Just to add, I have found that if you delete the app from Applications, then reinstall from Self Service, it always grabs the latest version from the App Store, but that's hardly a user friendly experience, especially if your end users aren't admins. The macOS implementation of volume apps definitely needs work. In the actual App Store app, it never lists any available updates. Delete + Self Service seems to be the only way to get them to update by choice.
To get around this, until updating through Self Service is an option, I created a separate policy that shows only when the app is installed. This policy is just set to delete the app then relaunch Self Service. This means they can immediately reinstall the app with minimal downtime and no admin access is required.
I also want to tag this. VPP apps are not updating automatically. The force update button in the jamf cloud pro server does nothing. I verified that the computer management / app updates / menu settings are checked to auto update. As well as the individual apps under mac app store apps are set to update automatically. Am I missing a setting, or is this just broken?
Follow up tag to my post yesterday. During our Jamf Pro Jump Start we were recommeneded to use smart groups set up to evaluate if a computer has an app installed. Then to scope our application installation policies to only apply to computers that don't have the app installed. We applied this same scoping techinique to our vpp app installations and this was the reason that the vpp apps were no longer updating. We have since changed the scope on the vpp app installations to all computers all users, and now the vpp apps install newer version upgrades on computers with existing installations. In hind sight this makes perfect sense. Just wanted to share to review your scoping on the vpp app policies so that they continue to apply to computers even after the installation is complete.
Chiming in here as well. Our VPP apps are set to automatically check for updates and force update and we still see the apps staying on the same version. My latest experience with this has been Slack. Slack just updated to 4.4.0. Jamf shows the version as 4.4.0, yet most machines are still running 4.3.3 even after I clicked on Force Update.
Also having an issue where app updates are not consistent. I have Office apps deployed to a small test pool and my laptop in particular refuses to update Outlook even when using the force update button and verifying the app is not open. the App Store just forever shows 1 update. Other apps sometimes hang as well but it looks like the rest have cleared up. overall, doesn't appear to be very reliable, especially since the user is unable to simply click update due to the account not matching their own.
Having the same issue with VPP Apps. Had a support request open with JAMF since last year. We have some VPP apps scoped to all computers to install automatically and other to all computers but install via self service. The updating of these Apps isn't great. They very rarely update. On a few occasions they do but there doesn't seen to be a pattern to the updates as its never the same mac. Apps are closed. Force Updates clicked but nothing happens.
Has anyone found a way to fix this. JAMF think it is in relation to the VPP timeout issue that is currently with Apple.
Just to +1 boshea's findings above, we were originally scoping our App Store Apps to Smart Groups (ie: Does not have Word.app -> then install Word.app) and the issue was that once Word is installed, it drops out of that Smart Group and takes the VPP license with it (the App isn't removed though). So while that's a likely reason why Apps deployed through VPP won't update - we also have a job open as we've moved from Office Professional to the App Store and have found a lot of them aren't updating even still. So far I've found:
non-DEP -> Just remove the MDM Profile and re-add it, usually by deleting it from System Preferences -> Profiles then use your add_to_JamfCloud.pkg to re-enrol.
DEP -> Presuming you have 'make MDM Profile removable' unchecked in your PreStage Enrollment, re-installing the MDM Profile isn't that simple. We had some success using an API to send an unmanage command from the JSS, then deleting the AppleSetupDone file (rm /var/db/.AppleSetupDone) and restarting which then gets the "Accept Remote Management" screen which re-installs the MDM Profile.
With Catalina you have to boot to Internet Recovery to delete the file (link, however success on Remote Management being accepted depends on whether the JSS is happy to see an existing device record, the existing record has the correct PreStage Enrollment listed and the MDM Profile is happy to be overwritten. Thankfully in these instances you can select 'other network -> I don't want to connect to a network' to get around the Remote Management screen, then create a temp account, log out and back in with your original account and you don't lose any data (only days/weeks of your time).
We've dialled down to DEP Macs being set up via Migration Assistant or TimeMachine being a likely culprit of these issues, Jamf/Apple don't tell you to avoid doing this unfortunately.