I am seeing a lot of our systems having the "vpp redownload call timed out <mdmclienterror:72>" error when cliets try to install VPP apps via Self Service on MacOS (most clients are 10.14.2).
I have tried clearing the failed commands, reconning, re-enrolling etc with no luck.
I am hesitant to revoke all apps as I have seen suggested because I am concerned about the number of people who will experience iTunes notifications about apps not being assigned (the staff at this school are fragile...).
Any advice would be appreciated.
Best answer by pbowden
@mjames@whitebeer The issue with storedownloadd crashing during MAS installs is fixed in 10.14.4 Beta 4 (18E205e). This is RADAR 47685116. Let me know if you still see problems after the update. For clarity, typical symptoms of this bug: - Larger MAS apps like Xcode and Office fail to install and leave behind an .appdownload stub - Needing to run multiple jamf recon commands to coerce apps to install - MDMClientError:72 failed command seen in JSS
I've updated https://macadmins.software/mas with the latest info. The largest outstanding issue that I'm still tracking is the inability to update MAS apps through MDM when the user has the app perpetually open.
Update #3 11/04/2019 Apple has replied to my AC ticket: "Your issue matches a behavior we are currently investigating". He encouraged everyone having this issue to please put in a ticket and also give quantities of devices effected in your environment so they they can prioritize for enterprise customers. I also shared this threads URL in the ticket and the Jamf ticket #'s below (as mentioned earlier in this thread):
I'm curious what everyone else is doing? Are you just effectively stopping using VPP and going back to traditional packaging/redeployment? It really sucks to have to re-package 7+GB Xcode installers (for example) but for us, VPP is now 100% un-reliable.
We have flash drives with GarageBand, Pages, Keynote & Numbers we can quickly deploy to students/teachers that need if initially it fails in Self Service (These were pulled from a MacBook that had the apps deployed properly via Self Service). Luckily a lot of students had already downloaded these before the issue hit us harder. Still a pain and a good number effected that did not initially download at the first of the school year (or students that just now are taking classes that require GarageBand) or with freshly erased/provisioned MacBooks. We had a method that seemed to work for us and got us by which was clearing the VPP error logs and running a recon multiple times. This work around doesn't appear to work as well currently as it did in mid October.
Seriously though, what's taking so long to find and fix this issue - an issue that's extremely high-impact to a multitude of organizations? I can't count on two hands how many tickets i've raised for this issue - tickets dating back to March 2019 - and I've been met with absolutely no response from Apple.
So the only annoying thing is that Apple do not comment about their internal investigations. We all get the standard reply of “we’ve identified the fault and are working on a solution”
I opened a ticket with support on this just the other day and they sent me a list which is to renew VPP token and check network for anything that may be blocking communication with Apple (I doubt it's the latter). I am hopeful to work on this today.
@markl If you read this entire post which I know is a-lot, this is part of long list of things that may or may not work and believe me theres a-lot of things to try it's all Intermittent
I guess we aren't the only ones running into this. Question: if we create packages for Xcode, etc. with composer and push that way, can they be silently upgraded? That is the main reason we are switching any apps in the App Store to managed.
Just filed for this using the @donmontalvo listed AppleCare ticket and Jamf numbers. My SE from apple said Engineering is working on a fix and they are quite aware of the issue.
This is affecting us nearly 90% of the time. Cancelling the failed commands, sending blank push, run sudo jamf recon MIGHT fix it, but usually fails multiple times before it completes. This is will all apps, even something small like Trello. Extremely frustrating when attempting to deploy ~150 laptops.
The hands off benefit is completely lost with this issue. It requires us to babysit each and every unit and repeat the same steps multiple times to hopefully get it to succeed. This seems to be a repeating issue and I've read that its both Apple and JAMF's problem since earlier this year. We are new semi-new to JAMF but this is really helping me prove its cost to upper management.
Please prioritize this so we can use the product as intended and sold to us.
So I don’t believe this is an Jamf issue, Jamf has sent the MDM command to APNS. That is the end of Jamf‘s responsibility so it becomes an Apple problem
I don't know if this is just coincidence, but I just added a couple more free licenses to one of the apps in VPP and now all the VPP apps are working again.
I think I just had a breakthrough! I've had the "vpp redownload call timed out <mdmclienterror:72>" on macOS devices for months now across various versions of the JSS.
Our master is in the DMZ. The Console is always off. “Computer Access only”
Turning it on to “Full Access” has resolved this for me on the first few tests today. Including a macOS device that was failing over and over for weeks no matter what I did.
I’ve only tested with free MS Office via VPP. So far so good.
