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

407 REPLIES 407

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.

cgolebio
New Contributor III

Just wanted to note, getting the same issue, on and off our network with none of our security software installed. Anyone determine if it is JAMF or Apple (or both)?

randyp
New Contributor

Just spent time with JAMF and Apple this morning on this issue. Apple is working on a solution.

Heavy_D
Contributor III

I think everyone is experiencing this Error I am unable to use it at all with any of my new hires.

So I am back to Manual installs. unless I create packages for all those softwares.

esv
New Contributor II

Same here! Created ticket with jamf waiting on response.

walt_bower
New Contributor II

I'm also seeing this issue with 10.14.6 and 10.15. I have an open ticket with Jamf as well and they have acknowledged this this is an issue. They recommended clearing the failed command and trying it again, but this hasn't worked for me. I also tried running a recon and reuploaded the VPP token with no luck.

erichughes
Contributor II

Jamf support pointed me to this, https://support.apple.com/en-us/HT201999 and to review my firewall settings. If the issue were firewall settings I would expect 100% failure. However that is not the case for us. Our work around currently when it fails to download VPP apps, which is about 75% failure for new installs, is to clear the failed commands and immediately do sudo Jamf recon on the machine in question. That works about half the time the first time, try and try again till it does work. Sometimes I just leave it sitting and the apps in question will just show up after a hour or so.

Cayde-6
Release Candidate Programs Tester

So I had an update from Apple, they are still working on the VPP issue

mistacabbage
Contributor

So I have randomly had this "vpp redownload call timed out <mdmclienterror:72>" happening to several people. It fails under the user account Self Service. If I login as my admin account, Self Service still fails. So it's not a user / user preference issue.

I deleted the folder /Users/Shared/adi/ which was empty and that magically fixed it. After the first app was installed there is now a new empty folder named /Users/Shared/SC Info/

Hope this helps someone.

easyedc
Valued Contributor II

Out of curiosity, what OS version are you experiencing this on? I started seeing this a few months ago, ~July, and in troubleshooting, I noticed that anything High Sierra or older wasn't impacted, but Mojave and the then Catalina beta (and now Catalina prod) do get this error.

mistacabbage
Contributor

Mojave

Cayde-6
Release Candidate Programs Tester

Mojave and Catalina

c_kay
New Contributor III

I'm seeing this issue with macOS 10.15 now. I'm not seeing it with macOS 10.14 anymore.

stevewood
Honored Contributor II
Honored Contributor II

If you’re seeing this error, open a case with Jamf and with Apple. There are case numbers above, so reference them. The only way they understand the impact of this is if we file cases. This is affecting a lot of us and it needs to be fixed.

Dschurrat
New Contributor II

Any Ideas ? Or Informations ? I have the Issue VPP redownload call timed out <MDMClientError:72> @ macOS 10.15. But ist my first MacBook in my Company :-(

abuehler
New Contributor III

Same issue here... I'll create a ticket then.

stevewood
Honored Contributor II
Honored Contributor II

I'm curious, are folks only seeing this issue when deploying via Self Service, or do you see this with both Self Service and a push install?

I've had issues getting Numbers onto my machine via Self Service. I created a push of the app and it worked fine.

Just curious.

Cayde-6
Release Candidate Programs Tester

@stevewood Both for me

abuehler
New Contributor III
I'm curious, are folks only seeing this issue when deploying via Self Service, or do you see this with both Self Service and a push install?

Both. It does not make any difference if the app is pushed or installed via Self Service.

KyleEricson
Valued Contributor II

I have a ticket opened with Apple Enterprise Support. Apple says that this is fixed in macOS Catalina 10.15. I'm not going to update to find out need this fixed for macOS Mojave.

Read My Blog: https://www.ericsontech.com

Cayde-6
Release Candidate Programs Tester

@kericson Nope this is still an issue, I'm on 10.15.1 beta and still occurs

mistacabbage
Contributor

New day, new issue.

Deleting the folder /Users/Shared/adi/ did not work this time. No app store installs were working for the standard account end user.

The error in the JSS was "vpp redownload call timed out" and not "vpp redownload call timed out <mdmclienterror:72>"

I logged in as an admin user on the Mac and no user in Self Service and the first Mac App Store app worked.
Then I was able to login as the standard account end user and continue installing the rest of their Mac App Store apps.

I restored their ~/Library/ folder from Crashplan so I suspect it is something in there this time.

totalyscrewedup
New Contributor III

Same issue (VPP redownload call timed out <MDMClientError:72>), running 'sudo jamf recon' isn't doing much, submitted the case to Jamf.
They should really concentrate on resolving all open cases before worrying about features and other gimmicks. Get it to be a solid platform, working reliably and have the features that are already there working first before adding more. The 'Download and Install updates' command hasn't worked in years, for just one example from trillion of open cases. Or how about getting Jamf remote to work as designed.

KyleEricson
Valued Contributor II

@totalyscrewedup This is not a Jamf issue, but a Apple issue. Jamf opened the case with Apple.

Read My Blog: https://www.ericsontech.com

Cayde-6
Release Candidate Programs Tester

Agree it’s an Apple issue, Jamf has sent the APNS command to Apple

rahern
New Contributor III

I'm seeing this with Pages and Numbers right now. Weirdly enough, Microsoft Word worked fine yesterday. Anyone get a response from Apple yet?

Heavy_D
Contributor III

Nope and just did a fresh install of my Catalina TESTER today with the Supplemental Update installed as well and still getting the the 72 message from hell!

VPP redownload call timed out <MDMClientError:72>

Heavy_D
Contributor III

This thing is wonkey, after trying everything on here several times doing @jbosma method worked after x5 times of trying I think it comes down to timing:

  1. Go under the management tab on the device in question, cancel all the failed <MDMClientError:72> command and then send a blank push.
  2. On the machine in question quickly run a :sudo jamf recon.

After doing this several times it eventually went through. But without question still an issue.

MikeR11
New Contributor II

same issues here with most clients on the latest version of 10.14 and open ticket with JAMF and Apple.

I have tried a bunch of the solutions above but the semi consistent fix is what JarvisUno stated

  1. Go under the management tab on the device in question, cancel all the failed <MDMClientError:72> command and then send a blank push.
  2. On the machine in question quickly run a :sudo jamf recon.
  3. Walk away - Wait

Dschurrat
New Contributor II

Now it works again with MacOS Mojave. Please try it again

hhorn
New Contributor III

Just updated to JAMF Pro 10.16.0 and Java openJDK 11.0.5. I was hoping the combination would solve the misconfigured TLS1.3 settings from Apple, however we are still seeing VPP errors however this did solve some of our DEP issues.

Dylan_YYC
Contributor III

Still seeing this on 10.14.6 and 10.15. Currently running JSS 10.15.1
I talked with a JAMF support specialist yesterday and he said: "If we've verified this is not a network related issue, or the Volume Purchasing token is not assigned to another MDM Server, I would encourage you to open a ticket with AppleCare Enterprise Support (ACES) and reference the Apple Radar #100893229861."

Heavy_D
Contributor III

@Dylan_YYC Yep seems to be the Automated response everyone else is getting. The must be getting tired of hearing about it as we are at seeing it.

Heavy_D
Contributor III

So here is another suggestion you can try, after doing my previous studies for like x20 times and noticing I was not going any where I did the following:

  1. Updated my VPP token (again)
  2. Cleared <MDMClientError:72> then a blank pushed.
  3. Ran a: sudo jamf recon on the machine in question.

And the App I been testing with FINALLY installed through self service.

Dylan_YYC
Contributor III

Ive tried that too. Its just a matter of the stars lining up or something to get apps to install.

stevewood
Honored Contributor II
Honored Contributor II

The strange thing about this, at least in our environment, any VPP app that is pushed during enrollment works with no issues. We have Keynote set to install on all computers as a push. I can enroll a computer in Jamf (DEP or using enrollment URL) and Keynote shows up on the device.

KyleEricson
Valued Contributor II

Has anyone seen that once the apps do install that they won't update? I get notifications to update via the Mac App store, but unable to do so. I have tried the force update button via Jamf.

Read My Blog: https://www.ericsontech.com

benducklow
Contributor III

@kerickson Someone correct me if I am wrong, but I believe there is a PI for this 'update' ability...

PI-006120 - Jamf Pro fails to update Mac App Store apps that are made available in Self Service and configured to automatically update.

The notes I have on this - The button simply says 'Open" instead of "Update" within Self Service Mac App Store App assignement policy. We are forced to create an 'uninstall' Policy and have Users' run this before re-running the install to get the updated version.

Heavy_D
Contributor III

@kerickson Same here, putting in a ticket to add me to that PI now as well.

Thanks Guys.

KyleEricson
Valued Contributor II

@benducklow Thanks yup I'll be putting in a ticket for this PI now as well @JarvisUno

Read My Blog: https://www.ericsontech.com