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.