Also seeing this. I've had a ticket open for a few days now. A couple of things I've been asked to try is untick the VPP tab to refresh licenses. Transfer licenses to a new token and try. Both haven't worked. Now waiting for another reply.
Mac version 10.14.6
We've been seeing this for days.
We're impacted by this error on multiple Macs as well.
I’ve raised this with AppleCare Enterprise support, I suggest anyone else affected does the same.
@Cayde-6 my case was with Jamf. As it turns out my VPP redownload errors are now gone, but the apps still aren't updating, and for those that update a few end up with the new App and an App.appdownload in /Applications. There's PI-006764 basically saying that if a VPP app is open when an update occurrs it will fail, but that's not too workable. I may just stop using VPP so I can be sure that app updates happen when they should be. Easy for free apps, but for paid, who knows. @dugnl are you sure that you aren't having a network issue? Maybe try an external network to rule out security?
We have been seeing this at certain times of the day, around 1:00 - 4:pm CEST. I have written a script to cancel any failed MDM commands:
This is only a workaround until we find a solution...
https://github.com/hhorn76/JAMF/blob/master/API%20Scripts/clearAllFailedComputerMDMCommands.sh
We ran into the same issue today, tried all of the above suggestions. We had the user open the app store on the device and accept the privacy statement that accompanies opening the app store for the first time. Following accepting this the vpp downloads were successful.
Had exactly the same issue across several Jamf Cloud instances too. Affects Macs on 10.13.6 right up to 10.14.6.
I had an update from Apple,
It is being treated as an issue.
We resolved this issue yesterday. We figured out it was the firewall even though we had already added the corrects ports and whitelisted the apple ip range.
It came down to SSL inspection causing our MACS to get the "VPP redownload call timed out <MDMClientError:72>"
To allow MACS to install apps we have to turn off SSL inspection.
@RLR Did you disable it for just the Apple address block?
@RLR We ran into some issues with functionality that used to work then stopped due to "deep packet inspection" on traffic between managed clients and Apple's various servers. A good point to bring up.
@Ecco_Luke We tried that to begin with but it still didn't work. We then tried disabling SSL inspection on the Jamf Cloud IPs but that didn't work. We tried various domain addresses based on various firewall logs but still couldn't get it to work.
We where spending too much time on this and we only have a few MACS so we've just turned off SSL inspection to get the apps installed and then we will turn it on again. We don't push out apps very often.
@RLR Lordy, that doesn't sound ideal. Workable if you're an internal admin but probably not feasible if you're an MSP! I've raised a ticket with Jamf on this too, I wonder whose end the problem is on (theirs or Apple's?).
@Ecco_Luke I had a call open with Jamf about this and this is the response:
Yes indeed SSL inspection breaks APNS communication, but unfortunately that's gonna be the same conclusion, no SSL inspection on communication with the 17 network.
Apple does not provide any info on which domain or IP adresses. In practice you could try with trial and error on different Apple services, but that's subject to change as well.
Hence we only support Apple's recommendation not to do SSL inspection.
Hi everyone!
Just installed a new Macbook Air 2019 today and have seen this for Apples Apps Garageband, iMovie, Keynote, Numbers and Pages.
All of the above apps was assigned for install from Self Service, none of them worked, I got the "VPP redownload call timed out <MDMClientError:72>" error message in JSS.
What worked for me was the following:
I cleared the error messages for the machine in JSS. Sent out a "Send Blank Push" message.
Then I assigned Pages as a test, but not in self service, instead I had it to install automatically.
Ran the sudo jamf -recon command on the machine, and "whoa" Pages begins to install just like a charm...
Did the same with Keynote and Numbers. Now to the odd thing. Just to try Self Service again, I tried to install iMovie, and it worked. Real odd, the same thing with Garageband, both worked now, 10 minutes ago I got the "VPP redownload call timed out <MDMClientError:72>" error message from them...
Can someone else try this and maybe confirm if it works or not. I might just got lucky this time...
i installed my Test System in the morning several times without any issue. Since 01:30 pm i get the VPP Error.. it seams that the bug is not solved from Apple side....
We are having the same issue. We do not do SSL Inspection/Deep Packet Inspection.
JAMF had me renew the ASM token and cancel all failed/pending commands. We no longer get the "MDMClientError:72" error message, but the app never installs.
Raise them as Apple fault tickets. The more tickets should help prioritise their DEV team
Can anyone confirm if adding "smp-device-content.apple.com" to your web filter/firewall whitelist helps with this problem? I thought that was what resolved it on my end, but it is still working even after I remove that host from the whitelist.
I was getting that mdmclienterror:72 on a MacBook and I was able to get a WireShark capture of the event. I sifted through everything until I found one TCP stream that was timing out (after 60 seconds). It was a TLS port 443 connection to the host above, "smp-device-content.apple.com", which resolved to 23.52.45.48 at the time (an Akamai IP).
I'm having this issue as well this morning. After cancelling app delpoyments, sending blank pushes multiple times, refreshing app content in Settings > VPP Accounts - it seems to be working... kinda. PowerPoint and Word are installing but all the other VPP apps are showing MDM error 72.
I guess i'll rinse and repeat.
This started occurring within the last week here and today I decided to run WireShark and we were blocking traffic to some 17.x.x.x IP's. I'd advise maybe looking at that for those of you in a corporate setting. Apple changes up their IP's all the time, so our network engineers trying to be cute and only opening up a few IPs came back to bite us, but at least now I can "force" them to open the whole range. Wouldn't want them to look bad again!
This issue "resolved itself" for me yesterday morning... I did absolutely nothing.
So I know that Apple and Jamf are collaborating together on this
