Hello, It blends well for us & is a great feature in Self Service but there are some issues that I've encountered.

I have been transitioning my environment (like most people) from a monolithic pre-jamf imaging process to an all Jamf DEP Deployment Provisioning process. During this transition I've encountered some corkyness with the VPP rollout of applications.

For Example, MacOS NativeOEM & our Monolothic Image had Keynote, Pages & Numbers pre installed on the computer - not associated with a VPP account. Deploying updates to these applications via JAMF & VPP proved futile - futile because if an end user had the ability to associate an AppleID with the application it prevents VPP from bringing down the new application - if an AppleID is not associated I believe it works just fine. This is a problem as there is no way to automate it - you have to literally delete the application and then install it via VPP.

I made this feature request for adding a script before or after a VPP Deployed Application to add some flexibility to VPP deployments - https://www.jamf.com/jamf-nation/feature-requests/8213/add-script-option-to-vpp-deployment-macos

@donmontalvo blends well for us as well (14K devices under management). I would add one caution/caveat: if you are utilizing two MAS entries, one for push and one for Self Service, you want to assign your licenses under only one of those entries and not both.

For example, if you are pushing Keynote and you also want to have Keynote in Self Service for the same scope of machines, you should assign the licenses under the entry that has the largest scope, most likely your Self Service entry, and not assign it under the push. So you would have "Assign VPP Content" box on the VPP tab checked on the Self Service entry and not the push entry. Otherwise you are essentially assigning the license twice to the same machine and this will cause licensing errors in your logs.

As far as apps that are either pre-installed, installed manually, or installed using a user's AppleID, you can just run a script to delete the app and it will come down from VPP. That is how we are handling it in our environment.

@donmontalvo

@Hugonaut and @stevewood have already mentioned the big caveats as I see them. So, after those, I'm going to say that it's all good. Instead of scripting a solution, I tend to rely on smart groups to avoid sending VPP apps when one is already installed out of the MAS by the end user. If they're running it with their AppleID that's ok by us. Just so long as they have it.

The biggest issue for me is that having a VPP app in scope on Self Service already uses up the license. You can't manage a flexible pool of licenses like this.

Ideally, Jamf would see the request for a license, check if a license is still available and assign it to the Mac in real time. Unfortunately, that's not how it works currently.

Edit: I've raised a feature request, if you're interested in seeing this fixed/improved.