vpp redownload call timed out <mdmclienterror:72>

mjames
Contributor

Hi,

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.

1 ACCEPTED SOLUTION

pbowden
Contributor III

@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.

View solution in original post

404 REPLIES 404

RLR
Valued Contributor

@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.

jorrig
New Contributor III

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...

ChrisLawrenz
New Contributor II

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....

sirsir
Contributor

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.

a_stonham
Contributor II

Seeing this also.

Cayde-6
Valued Contributor

Raise them as Apple fault tickets. The more tickets should help prioritise their DEV team

Hedley
New Contributor

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).

ajfunk
Contributor

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.

tdclark
Contributor

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!

ajfunk
Contributor

This issue "resolved itself" for me yesterday morning... I did absolutely nothing.

Cayde-6
Valued Contributor

So I know that Apple and Jamf are collaborating together on this

ajfunk
Contributor

....aaaaand the issue is back. It was working just fine at around 10:30am EST today.

discounteggroll
New Contributor III

I'm getting this error on pretty small MAS apps as well, so I don't think size is a factor

ajfunk
Contributor

I'm not having any issues pushing VPP apps to any iOS devices - seems to just be macOS devices.

JarvisUno
Contributor II

I am getting this error 10.14.6 as well.

vpp redownload call timed out <mdmclienterror:72>

Anyone have any insight on how to fix this at all?

Cayde-6
Valued Contributor

Wait for Apple to fix out, they’ve acknowledged it and working with Jamf on the solution

RLR
Valued Contributor
Anyone have any insight on how to fix this at all?

I think there might be a few different things that are causing it as people have mentioned different fixes. Our fix was to remove SSL inspection on the MACs.

JarvisUno
Contributor II

@RLR

I think there might be a few different things that are causing it as people have mentioned different fixes. Our fix was to remove SSL inspection on the MACs.

Can you please specify? As these were clean installs I don't believe we have any SSL stuff enabled at this time.

Cayde-6
Valued Contributor

Basically Apple do not like anything that breaks the TLS encryption between their servers and the EUD, is detected they break the link so the download starts again. SSL inspection, packet sniffing etc.

JarvisUno
Contributor II

@Cayde-6 So how can I check this on my side?

Cayde-6
Valued Contributor

@JarvisUno depends who deals with networking with your organisation

RLR
Valued Contributor

@JarvisUno You will need to ask anyone who controls the network. More so the firewall as the SSL Inspection is usually done at fire wall level.

JarvisUno
Contributor II

@Cayde-6 That would be our SAS Operations team but any changes to the network have to go through proper change management and I am part of the committee. As far as I know there has been no changes, but can put one in to fix this issue if need be.

Cayde-6
Valued Contributor

@JarvisUno Apple make changes all the time but do not “always” notify the enterprise users.

Basically anything that breaks TLS cannot be Trusted.

stevewood
Honored Contributor II

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.

ajfunk
Contributor

I've been out sick all week - have Apple updated us on this issue?

Cayde-6
Valued Contributor

@ajfunk nope Apple still actively investigating with Jamf

donmontalvo
Esteemed Contributor II

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.

Update:

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)

--
https://donmontalvo.com

MikeT
New Contributor III

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.

JarvisUno
Contributor II

@MikeT Thanks for the update.

Initialised
Contributor

I am also seeing this on some Macs on 10.14.6 (18G95):

0cd3950fb7ae4e149967e67026e25d19

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.

ajfunk
Contributor

I was setting up a Mac yesterday at around 1:30PM EST and VPP apps started deploying to it after a few minutes. About an hour later, I was setting up a Mac and got the error 72. Tried cancelling the app installs in the Management tab 5 times, but with no success..

jimnorrisiv
New Contributor II

Had this issue today and was able to finally resolve it by downloading and re-uploading my VPP cert.

rustino
New Contributor

Was having this issue then tried @jimnorrisiv idea and it worked for me as well.

rhooper
Contributor III

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.

maxhewett
New Contributor II

This is still an issue for us on 10.15 - has anyone else had a chance to test on Catalina?

mgshepherd
Contributor

@maxhewett Just stumbled across this post because I started with a fresh install of Catalina today and I'm having the same issue.

maxhewett
New Contributor II

@mgshepherd Same boat as me - I've tried refreshing the .vpptoken and that hasn't helped. I'm going to open a support ticket with Jamf.

mpout
New Contributor II

Still getting this issue. Thankfully defered the role out of Catalina but this is happening during testing any updates on this from JAMF would be appreciated!!!

EDIT: Further tests, presenting on both Catalina AND Mojave, on all networks. Driving me nuts!

psmeltzer
New Contributor

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.