/build/static/layout/Breadcrumb_cap_w.png

WARNING: KACE SMA - File Synchronisation Resume Download: Standby- / Shutdown-Issue

Hello everybody,

this is not a blog-post in general, it´ s rather a warning for using the feature file synchronisation (with large files - for ex. 3 GB).

We´ ve got installation files which have to be seeded to clients all over the world where no replication share is available. - Best example: Home-Office Users

We recognized that when clients start to synchronise the zip-file and the client does a stand-by or a shutdown, and comes back again, the temporary download file gets deleted and you can see log entries in kagent.log like this:


2023-10-25.11:08:22][KDeploy:KWeb::DownloadUsingCurl ] DOWNLOADFILE: CURL DEBUG INFO --->>> END <<<---
[2023-10-25.11:08:22][KDeploy:KWeb::DownloadUsingCurl ] DownloadFile: 'xxx.zip' error occurred: 'transfer closed with 5156163837 bytes remaining to read' Error Code (18:Transferred a partial file), url: http://127.0.0.1:49699/packages/377/xxx.zip
[2023-10-25.11:08:22][KDeploy:KWeb::DownloadUsingCurl ] DownloadFile: Download C:\ProgramData\Quest\KACE\downloads\377\xxx.zip from http://127.0.0.1:49699/packages/377/xxx.zip did not complete
[2023-10-25.11:08:22][KDeploy:KWeb::DownloadUsingCurl ] DownloadFile: Something went wrong, local part file can't be trusted. Going to delete: C:\ProgramData\Quest\KACE\downloads\377\xxx.zip.part
[2023-10-25.11:08:22][KDeploy:KWeb::KCopyFile         ] Error (cURL) copying files from 'http://127.0.0.1:49699/packages/377/xxx.zip' to 'C:\ProgramData\Quest\KACE\downloads\377\xxx.zip': (18) Transferred a partial file


We recognized that the download starts again and again especially for our mobile workers, which use a LTE-Connection.

The mobile data volume was eaten up quickly and the users were not able to work. - Additional data volume had to be bought.


There is no "resume-functionality" to resume a partial download at all... - This is a big issue!


I raised a Ticket at Quest to address this issue, but as expected I got no support. This was the final answer:


Hello,

Thank you for your update. Please note that the issue reported here cannot be categorized as a product defect as the SMA design does not include the ability to continue on disconnected downloads. If an implementation was in place that was failing, then I could get R&D involved to fix it. However, as the SMA is working as designed, the only viable option is to put in a feature request.

Unfortunately, there is no option for me to close this ticket with a status that would express the dissatisfaction that you might have in regard to this scenario. However, in the Resolution field, it is included in addition to the detailed internal notes.

Resolution field: "There is currently no implementation of continuing disconnected file downloads. The customer worked around the limitation by using BITS."


Yes, the SMA seems to work as designed, but this is not an expected behaviour. This is a product issue.

As you can see in the last sentence of the reply, I came over in a complex workaround to use Microsoft BITS Transfer Service to Seed files to clients.

BITS can handle interruptions like Standby and Restarts.


Hope this information helps anyone not running in the same issue.


Comments

  • so did you put a feature request? If yes, where so anyone can vote?
    if not? why not? - Nico_K 3 months ago
  • I also put a request in the "ideas" section in ideas.labs.quest.com.

    Here the link: https://ideas.labs.quest.com/ideas/KSMA-I-780

    But I think that you will not be able to visit this page, because the access has been limited. I can see the hint
    "Only visible to the idea creator and our employees "

    I also updated the incident an the "idea" with the follwing hint:

    Hello again,

    I investigated a little bit further.
    KACE uses the tool curl for transferring the files.
    I had a look at the tool and could see that there is also a parameter for resuming download when they were aborted.

    for example:
    curl -C - https://xyz.com

    The parameter -C tells to resume, the "-" after the "-C" tells to resume automatically at the "end" where the transfer ended...

    Could you please forward this to the development-team for discussion?
    I think with that parameter we could overcome this issue and reduce the compexity to "invent" a new download-mechanism... - jimbeam128 3 months ago
  • Quest discussed this issue in their developer-board and decided not to solve this issue... - as expected.

    Therefore I went on for using BITS as file Synchronisation solution and I can say it works pretty well... - jimbeam128 1 month ago
This post is locked
 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ