I'm also getting this error when trying to automatically install or prompt user to install VPP apps. Looking for any info if anyone has run into this before
Just got this error today? Anyone resolve this issue?
Thanks!
Im currently getting this error also. Anyone find anything on it?
@mh314 I just had this issue as well the fix I got from jamf is to revoke all licenses this WIL NOT uninstall any apps. Go into your VPP settings and click the revoke all button at the bottom of the screen. it may take 3-5 minutes to complete. Then clear any failed pushes.
Thanks, @RogerH!
I've been meaning to come back and update this. This is essentially what I ended up doing as well. I also ended up downloading a new token for the VPP account, just to be sure.
Just had to do this and everyone in our orginization got mutiple notification from the iTunes Store saying that Apps were no longer assigned to them. Even thogh the apps were still on the devices.
This is scary. Will all the iOS apps reinstall? That would not be good.
For anyone still seeing this, I found a possible situation that may have been resulting in the MDMClient Error:72. Needs further testing.
I've had two instances of each VPP App, one for imaging deployment with scoped users, one for Self-Serve available to all computers. Some of our apps we'd prefer not to automatically update for stability purposes, some we do, so I didn't have the global
Gear>App Updates>"Schedule Jamf Pro to automatically check iTunes for app updates"
checked. I was controlling that on an App by App basis, with the Self-Serve items always being on the latest version but the deployment ones being a version or so behind.
In hindsight, I think the ones that had conflicting versions, then eventually all of them started giving the 72 error. I've now checked the global setting and once the versions matched across the board the apps appear to be dropping consistently.
This is just a theory based on possible coincidence, but if anyone is in a similar position perhaps they can test.
It may simply be that once the app is updated in the AppStore, previous versions are not available to be installed and, unless you have the global setting checked or every individual application set to auto update, the installation will fail to install once an update is released.
This issue (Product Issue-007435 ) is supposed to be resolved in Jamf Pro 10.27. However, we are still seeing the problem with various Apple MAS/VPP apps such as macOS Big Sur installer, Keynote, etc.
Can anyone else verify this?
I just got the same error pushing out Microsoft Word. Running Jamf 10.28.0-t1615386406. Pushing out to Catalina computer that was just wiped and OS installed. THis has been fine. I have pushed this for months. I will just cancel and hope ot works. I'd hate to revoke and people lose apps.
From what I was told by JAMF about the MDMClient Error:72 error in December was this is a known issue between JAMF and Apple. They had a ticket open for it but I dont have the number handy. What I remember of the situation is it has something to do with network latency and timing out the connection.
If I remember correctly JAMF said unchecking "Require admin password to install or update apps" in the restrictions payload the configuration profile enforcing it was a work around.
@djp I recommend creating a new thread, this one is 4 years old. You may get more attention with a new post rather than bumping an old one.
@AJPinto We have never enabled "Require admin password to install or update apps".
I have made Jamf Support aware of this thread (and related posts). You are correct, this appears to be an old issue.
The Jamf PI (PI-007435) is linked to AppleCare ticket #100893229861.
My Apple Enterprise rep mentioned that he thinks its fixed in macOS 11.3 (due in April), but that doesn't help us - we would like older Catalina Mac users to pull the VPP Big Sur installer from Jamf Self Service.
@dstranathan
When we had our ticket in December the JAMF Rep told us Apple "fixed" it with MacOS 10.15.7, and it would not effect Big Sur. Seems like its an issue they still don't have a handle over.