Hi @mjames ,

I've got the exact same problem with the VPP apps - especially with larger apps like XCode and Microsoft Office. For me a 'recon' pushed the download a step further but only some apps ended on the client, the others were still downloadstubs I've tested with our corporate network (proxy+firewall in place), our hotspot (only firewall) and my private WLAN - but none of them was working. Most of our Macs are 10.14.3.

@whitebeer it is much the same for us - larger apps like Xcode, Fusion 360 etc - and most of our macs are 10.14.2...

@mjames @whitebeer check your crash logs (Console > System Reports) and see if storedownloadd is crashing during app install. See https://macadmins.software/mas for more info and the RADAR that’s tracking this issue.

Ive seen this as well. The issue we saw was is apple changed the app store communication protocol and we have to upgrade our proxy to resolve. once systems went outside of the proxy network the VPP apps worked as designed.

@pbowden

Thanks for the tip - we are seeing errors in the download in the console - but not the same one in the link

default 09:10:30.379644 +0800 storedownloadd sending status (Xcode): 76.559287% (835.138401)
default 09:10:31.964963 +0800 storedownloadd sending status (Xcode): 76.928800% (833.639385)
default 09:10:33.558941 +0800 storedownloadd sending status (Xcode): 77.360559% (831.393047)
default 09:10:35.159762 +0800 storedownloadd sending status (Xcode): 77.795357% (828.850088)
default 09:10:36.753070 +0800 storedownloadd sending status (Xcode): 78.261495% (826.747507)
default 09:10:38.343536 +0800 storedownloadd sending status (Xcode): 78.714579% (824.785034)
default 09:10:39.944908 +0800 storedownloadd sending status (Xcode): 79.147202% (822.968359)
default 09:10:41.527408 +0800 storedownloadd sending status (Xcode): 79.578090% (821.198435)
default 09:10:43.127732 +0800 storedownloadd sending status (Xcode): 79.999822% (819.534362)
default 09:10:44.727223 +0800 storedownloadd sending status (Xcode): 80.447251% (817.769275)
default 09:10:45.518932 +0800 storedownloadd Task <A6246E20-48A1-4666-AD63-1F483C9C76CD>.<0> response ended
default 09:10:45.519214 +0800 storedownloadd Task <A6246E20-48A1-4666-AD63-1F483C9C76CD>.<0> done using Connection 1
default 09:10:45.625997 +0800 powerd Process storedownloadd.18112 Released PreventUserIdleSystemSleep "URLConnection in progress" age:00:05:50 id:4295009410 [System: PrevIdle DeclUser kDisp]
default 09:10:45.626675 +0800 storedownloadd sending status (Xcode): 80.645162% (817.000000)
default 09:10:45.628294 +0800 storedownloadd sending status (Xcode): 80.645162% (817.000000)
error 09:10:45.634849 +0800 storedownloadd NSURLConnection finished with error - code -1100
error 09:10:46.773129 +0800 storedownloadd NSURLConnection finished with error - code -1100
default 09:10:46.838382 +0800 storedownloadd setPrimaryAppPath "(null)" forProductIdentifier "com.apple.dt.Xcode"
default 09:10:47.170217 +0800 kernel process storedownloadd[18112] crossed memory high watermark (30 MB); EXC_RESOURCE supressed due to audio playback.
default 09:10:47.170233 +0800 kernel EXC_RESOURCE -> storedownloadd[18112] exceeded mem limit: ActiveSoft 30 MB (non-fatal)

I've done a little looking about but haven't found anything much about "NSURLConnection finished with error - code -1100" - it looks like it is related to App Transport Security - I am wondering if it has anything to do with our network filtering/monitoring software now.

EDIT
After a few minutes - the logs reported this.

default 09:13:35.775064 +0800 storedownloadd estimatedTimeRemaining 1408.4295
default 09:13:35.775224 +0800 storedownloadd sending status (Xcode): 81.290323% (1411.429500)
default 09:13:36.273213 +0800 storedownloadd installClient:currentState:package:progress 4.979308682338265:timeRemaining 1408.4295:state 3
default 09:13:36.273383 +0800 storedownloadd estimatedTimeRemaining 1408.4295
default 09:13:36.273592 +0800 storedownloadd sending status (Xcode): 81.290323% (1411.429500)
default 09:13:36.285357 +0800 com.apple.CommerceKit.TransactionService ISServiceProxy: Connection to com.apple.storedownloadd.daemon was interrupted - removing connection from pool
default 09:13:36.286628 +0800 com.apple.CommerceKit.TransactionService ISServiceProxy: Error from com.apple.storedownloadd.daemon - Error Domain=NSCocoaErrorDomain Code=4097 "connection to service named com.apple.storedownloadd.daemon" UserInfo={NSDebugDescription=connection to service named com.apple.storedownloadd.daemon}
default 09:13:36.300127 +0800 loginwindow -[PersistentAppsSupport applicationQuit:] | for app:storedownloadd, _appTrackingState = 2
default 09:13:59.927878 +0800 ReportCrash Saved crash report for storedownloadd[18112] version 1.0 (1) to storedownloadd_2019-02-19-091359_SCT16324.crash

@mjames good info. That very last line indicates that storedownloadd crashed. Take a look at the crash report in Console > System Reports to see if it’s the same as what I reported.

@pbowden

It does indeed

Process: storedownloadd [75894]
Path: /System/Library/PrivateFrameworks/CommerceKit.framework/Versions/A/Resources/storedownloadd
Identifier: storedownloadd
Version: 1.0 (1)
Code Type: X86-64 (Native)
Parent Process: launchd [1]
Responsible: storedownloadd [75894]
User ID: 0

Date/Time: 2019-02-15 08:47:44.245 +0800
OS Version: Mac OS X 10.14.3 (18D109)
Report Version: 12
Anonymous UUID: 828A396E-DB42-F5FF-7B0C-676921102424

Sleep/Wake UUID: A5383D56-FAA5-487F-AB70-8105C9E23B5E

Time Awake Since Boot: 300000 seconds
Time Since Wake: 170000 seconds

System Integrity Protection: enabled

Crashed Thread: 6

Exception Type: EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes: 0x0000000000000001, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY

Termination Signal: Illegal instruction: 4
Termination Reason: Namespace SIGNAL, Code 0x4
Terminating Process: exc handler [75894]

Application Specific Information:
dyld3 mode
API MISUSE: Resurrection of an object

@mjames at least you’re hitting the well-known bug that Apple is looking at.

@pbowden any chance we can get the ticket number so we can open a similar ticket with AppleCare Enterprise Support?

@donmontalvo take a look at https://macadmins.software/mas as it lists the RADAR bug numbers

Awesome good to go thanks!

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

Thanks @pbowden - that is what I was hoping for.

@pbowden wow, didn't notice, but yea, test computer hasn't had any issues yet downloading VPP stuff. #knocksOnParticleBoardDesk

EDIT: It looks like it's because I'm trying to download an app that's had a newer version released as a separate app, no longer offering the older one. Confirmed I cannot download the older version on any computer, so it seems like this is the true issue.

My next thought is to change the download parameters, and make it download automatically to see if the issue persists.

@pbowden

We are still seeing this issue on 10.14.5, is there anything else to look into?

Yea seeing a very similar issue now also displaying on 10.14.6 Trying to get VPP Slack to deploy automatically to selected smart groups.

Install App - Slack VPP redownload call timed out <MDMClientError:72>

any more updates on this would love to hear them :)

i got this error yesterday and today on some machines. 10.14.5 and 10.14.6

We are also seeing this issue on most machines as they enroll from 10.14.4-10.14.6. Hoping to find a solution.

I'm also seeing this on 14.4-14.6. What I've found is if I go under the management tab on the device in question, cancel the failed command and then send a blank push, it seems to start the download. I know its far from ideal, but if you need it done, this seems to be working for me.

@jbosma - Yeah we do this already and it works only once we recon again on the device. I hate this workaround since we are a DEP house and most computers are setup at random times, in different time zones, by users who can't flush it all out of Jamf.

No idea where to even start. We are reopening our Apple ticket, since obviously this was not resolved with the 10.14.4 update.

If within your computer provisioning a script is used, you can use the jamf api to clear the failed commands and then run a Jamf recon. This article was helpful for me (https://aporlebeke.wordpress.com/2019/01/04/auto-clearing-failed-mdm-commands-for-macos-in-jamf-pro/).

Hi all, just opened a case about this. Seeing this one both High Sierra and Mojave, where roughly half the environment recieves the updated app and the other half gets the VPP redownload call timed out error (visible from the Computer Record). Any resolutions to this yet?

Case with Apple or Jamf?

OS 10.14.6 Happening on Multiple computers that were just enrolled and reconned. What a waste of time redoing something that should be working.