Status: Download Failed

I’m deploying an Action that will begin in a few days with the “The action’s downloads will be started before action constraints are satisfied.” setting enabled.

I have about 0.5% of the endpoints with a status of Download Failed. All have more than enough space and report to various relays. Any troubleshooting advise?

At 17:19:54 +0530 - opsite10 (http://bfx.fqdn.com:52311/cgi-bin/bfgather.exe/opsite10)
   Relevant - Upgrade - Kaspersky Endpoint Security (10.3.0.6294) (fixlet:72538)
At 17:21:07 +0530 - 
   Report posted successfully
At 17:21:12 +0530 - 
   DownloadPing command received (ID=72538)
At 17:21:15 +0530 - 
   ActionLogMessage: (action:72538) Action signature verified for Downloads
   DownloadsAvailable: checking for 'http://indbanbfx1.fqdn.com:52311/bfmirror/downloads/72538/0'
   DownloadsAvailable: true (action id 72538)
   ActionLogMessage: (action:72538) Non-Distributed - DownloadsAvailable
   ActionLogMessage: (action:72538) Submitting download request
   ActionLogMessage: (action:72538) Download url: 'SWDProtocol://127.0.0.1:52311/Uploads/D64C8268BC74DDBD71FF6F0C1932E8B5B1137065/bases.cab.bfswd'
   ActionLogMessage: (action:72538) Download url: 'SWDProtocol://127.0.0.1:52311/Uploads/1CD7B1DAB9BDA5812C47CF172B688BC2D13C47FE/Kes10win.msi.bfswd'
   ActionLogMessage: (action:72538) Download url: 'SWDProtocol://127.0.0.1:52311/Uploads/259D425BCBDDB0937F12720022E8ECBCA7E981CF/ksn_en.txt.bfswd'
   ActionLogMessage: (action:72538) Download url: 'SWDProtocol://127.0.0.1:52311/Uploads/1E8C0363533FDB6F4F978695416F9755589D2428/license.txt.bfswd'
At 17:22:57 +0530 - 
   ActionLogMessage: (action:72538) JobFailed - cancel and fail action
   ActionLogMessage: (action:72538) DownloadJobFailed
At 17:23:00 +0530 - 
   ActionLogMessage: (action:72538) ending action
1 Like

If you try it again on endpoints with the issue, does the same thing happen?

What are the cache settings on the clients with the issue? The default cache settings are very small. You may want to increase the prestage cache limit a bit.

The job is set to retry after failed attempts after a reboot; so maybe this counts as a failure and will be retried.

My download settings should be good and if they were an issue, the status would be specific; “Download Limit” I think.

_BESClient_Download_DownloadsCacheLimitMB"="8192"
_BESClient_Download_MinimumDiskFreeMB"="2048"
_BESClient_Download_NormalStageDiskLimitMB"="16384"
_BESClient_Download_PreCacheStageDiskLimitMB"="8192"
_BESClient_Download_PreCacheStageEnabled"="1"

I have even checked the cache on one of the relays to see if the files are there and they are (not to mention other endpoints connected to the same relay receive the download).

It takes a lot of time to try and figure out the cause of some of these little oddities, but I guess that’s part of the course.

1 Like

I believe download failures are not attempted once the happen. I am not totally sure about this though.
Have you took a look at the rd site?

What would I be looking for if going to the Relay Diagnostics site for one of the relays or what process would I following with in the site? I’m not all familiar with the various options.

I’m not sure how the download fits in with the retries, but that could be. Even so, you could send the same action a second time just to some endpoints that had this failure and see what is reported. You could even remove everything from the actionscript except for the prefetch just to see if this was some sort of fluke.

Yes, you are right about that. Your settings are fine. I also think there is specific messaging if the hard drive is low on free space, but it isn’t a bad idea to double check that too.

I’m not sure I’ve ever used this setting. I’ll have to look into that.

That seems pretty definitive. I would just try it again and see what happens. Maybe the download was interrupted by a wifi disconnection or something like that.

I’ve sent just the prefetch to five of the systems and all returned a status of Failed (which would be expected with only prefetch statements I gather). But looking at the Action Info, they show competed so maybe that was successful. I see if I can reboot one of them to see if that retries the action.

Completed add prefetch item name=D64C8268BC74DDBD71FF6F0C1932E8B5B1137065 sha1=d64c8268bc74ddbd71ff6f0c1932e8b5b1137065 size=195999134 url=SWDProtocol://127.0.0.1:52311/Uploads/D64C8268BC74DDBD71FF6F0C1932E8B5B1137065/bases.cab.bfswd sha256=7d9784ffefe3d3bc2034f83e3486dbec86b8e94b73eb74d194359d7719451aba 
Completed add prefetch item name=1CD7B1DAB9BDA5812C47CF172B688BC2D13C47FE sha1=1cd7b1dab9bda5812c47cf172b688bc2d13c47fe size=67596288 url=SWDProtocol://127.0.0.1:52311/Uploads/1CD7B1DAB9BDA5812C47CF172B688BC2D13C47FE/Kes10win.msi.bfswd sha256=0e4f697cb1d359b48abde7d7a1b0ba24c1039d897382251419638a501aa88fc6 
Completed add prefetch item name=259D425BCBDDB0937F12720022E8ECBCA7E981CF sha1=259d425bcbddb0937f12720022e8ecbca7e981cf size=29660 url=SWDProtocol://127.0.0.1:52311/Uploads/259D425BCBDDB0937F12720022E8ECBCA7E981CF/ksn_en.txt.bfswd sha256=fd46bd15c9cc912b55506c2b4e092e99b7374f9b28308f6fee79aca7601e2522 
Completed add prefetch item name=1E8C0363533FDB6F4F978695416F9755589D2428 sha1=1e8c0363533fdb6f4f978695416f9755589d2428 size=40529 url=SWDProtocol://127.0.0.1:52311/Uploads/1E8C0363533FDB6F4F978695416F9755589D2428/license.txt.bfswd sha256=95c049da775ce5554eeff271d7f91c553cf16eeed9c3923fafdb81b5d6a99222 
Completed end prefetch block

Out of interest, Alexa, did you resolve this issue?

Were there any additional fault finding steps that helped you reach the root cause of the download issue on these troubled clients?

Kind Regards,

Ian

If I did I don’t recall; it was a long time ago. Sorry.

No problem, thanks for the speedy reply Alexa. :grinning: