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.
Solved! Go to Solution.
@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.
@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.
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...
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 22.214.171.124 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!
I would suggest anyone that is experiencing this issue contact Jamf and open a support case. There is an open PI (PI-007435) that they are tracking this against. Yes SSL inspection is one of the issues that helps this, so does verifying that you have access to *.mzstatic.com available. However that is not always the issue.
Contact Jamf and get your company attached to that PI so they know the impact.
I would also suggest opening an AppleCare case if you have ACE or Alliance.
We are starting to get a bunch of tickets about this issue. Again.
Opening tickets to both Apple and Jamf, so we can toss them into the Octagon to work this out.
We opened these tickets, in case you guys want to open your own and reference:
• AppleCare ticket (100911339478)
• Jamf ticket (JAMF-0784229)
Jamf provided their tickets as well, also for reference:
• AppleCare ticket (100893229861)
• Jamf Product Issue (PI-007435)
It's a pain but found we can do a
sudo jamf recon
3 times on the effected macOS 10.14.6 Macs and then we could install VPP apps without the "vpp redownload call timed out <mdmclienterror:72>" error. Not a fix but maybe a "get me by for now". It was mentioned about SSL Inspection however we tried SSL bypassed and that didn't help. Doing the recon multiple times on the effected machines has worked "so far". Found this suggestion in the thread above "Posted: 3/5/19 at 10:06 AM by pbowden". YMMV
Update: We have had more MacBooks effected since posting and this solution worked on those as well.
Update #2 11/1/2019: Appears it has gotten worse. When in a crunch we are copying the Apple Apps to flash drives (That were pulled down from Jamf to a machine not experiencing the VPP issue) and putting them in Applications on the machines that we can not "jiggle the handle" and get them to pull down via self service, lol.
I am also seeing this on some Macs on 10.14.6 (18G95):
Having seen something similar on iOS in the past I hit cancel all commands, ran through the Auto Installs for VPP Apps and did Edit then Save, did a software update on the Mac in question and the Apps began to install, in my experience with iOS VPP Apps jamming the Software update (to 18G103 Supplemental Update 2) is likely irrelevant. But I have at least two others to check so let's see.
So it looks like a workaround if not a fix.
We are having the issue even with 10.14.6 and the supplemental update installed. I spoke to JAMF and to Apple. both are saying it is an Apple thing that appeared after one of the updates. We have also tried several fixes including update the token. it still is not downloading Mac Apps. Working with Apple and JAMF simultaneously.
hoping it will be resolved soon.
Just adding another confirmation to the idea there is something wrong at Apple's end here.
We have the same problem.
Existing devices receiving free software titles assigned to them by VPP from JAMF.
Newly enrolled Mojave devices failing to get free software assigned by VPP. MS Office and Slack
VPP redownload call timed out <MDMClientError:72> Is the reason given in jamf Pro.
I've tried on our network with carefully crafted SSL exceptions.
On our insecure wifi which has no TLS inspection
And on a mobile 4g hotspot we use to eliminate our own network entirely.
Behaviour is consistent. VPP software not assigned.
The only MDM failures are software assignments. Other MDM commands are completing.