/build/static/layout/Breadcrumb_cap_w.png

Client drop file not replicating to replication shares [K1000]

Hello good people of IT Ninja, This is my first post but I have been browsing the site extensively, and it has been a great help to me and my colleagues since we started implementing K1000 in our organization.

I have recently started configuring replication shares on our K1000 and up to now it all worked really smooth. However, since the day I had to upload a file to the client drop share in order to assign it to a managed installation i began having issues.
To put things into perspective I had to upload a 3.7 GB zip file to the client drop share in order to create a managed installation for Visual Studio 2015. I assigned the file to the software item and then the software to the managed installation and It all worked ok, however, the big issue is that the file is not replicating to our replication shares.
The item appears on the RS as software item to be replicated but despite that and the fact that the window is open for sync, the file is not being copied to the repository. I have allowed a full day in case it was just taking its time but that was not the issue.

Since I am a beginner with this, I might be missing some kind of configuration, so if any of you have any insight in this issue, any input will be greatly appreciated.

PS: We are running version 6.3.113399

Thank you all in advance.

Regards.

2 Comments   [ + ] Show comments
  • Assuming the replication shares are not local, what is the download bandwidth of the replication shares and what is the upload bandwidth of the K1? You could enable debug on one of the replication shares, force inventory and take a look at the KAgent.log. You should find logging when it attempts to download the file. The easiest way to enable logging is by running “amptools.exe debug=true” https://support.software.dell.com/k1000-systems-management-appliance/kb/112035 - farley 9 years ago
  • Hi Farley and thank you very much for your suggestion, it was the kick start I needed to answer my own question.

    As far as I could see, the problem was that the zip file was named Visual Studio 2015.zip (note the spaces). Apparently, the spaces were filled with a %20 automatically by Kace and that caused the issue.

    Here is an extract of the log:

    [2015-10-07.10:43:49][pluginWeb:DownloadUsingCurl ] DownloadFile: Download C:\Repository\repl2\software\9480\Visual Studio 2015.zip.2eb6ef69e7eeebe2e532b2996a8431c1 from https://k1000.corp.globant.com/packages/9480/Visual%20Studio%202015.zip did not complete
    [2015-10-07.10:43:49][pluginWeb:FileChecksumMatch ] Local hash of file doesn't match expected: C:\Repository\repl2\software\9480\Visual Studio 2015.zip.2eb6ef69e7eeebe2e532b2996a8431c1.part: 2eb6ef69e7eeebe2e532b2996a8431c1 (expected) !=edd9f741a5cd3093ce94ece6ba71ec30 (found)
    [2015-10-07.10:43:49][pluginWeb:ReplicateFile ] ReplicateFile: download failed and part file C:\Repository\repl2\software\9480\Visual Studio 2015.zip.2eb6ef69e7eeebe2e532b2996a8431c1.part checksum didn't match
    [2015-10-07.10:43:49][pluginWeb:ReplicateFile ] ReplicateFile: download failed, if interrupted, keeping part file

    Notice how the file name is changed to Visual%20Studio%202015.zip

    After noticing this, I changed the file name to VisualStudio2015.zip and it replicated to the RS without issues.

    It is weird though since the MD5 check should be the same despite the name of the file, so I don't know if my logic is right and that was the actual issue, but I can possitively say that after removing those spaces the file replicated ok.

    Once again thank you very much for your input and I hope this will be useful for someone else. - Glaporte 9 years ago
    • Awesome! I remember having that bug with scripting. Glad you figured it out. - farley 9 years ago

Answers (1)

Answer Summary:
Posted by: Glaporte 9 years ago
Senior Yellow Belt
0

Top Answer

As far as I could see, the problem was that the zip file was named Visual Studio 2015.zip (note the spaces). Apparently, the spaces were filled with a %20 automatically by Kace and that caused the issue.

Here is an extract of the log:

[2015-10-07.10:43:49][pluginWeb:DownloadUsingCurl ] DownloadFile: Download C:\Repository\repl2\software\9480\Visual Studio 2015.zip.2eb6ef69e7eeebe2e532b2996a8431c1 from https://k1000.corp.globant.com/packages/9480/Visual%20Studio%202015.zip did not complete
[2015-10-07.10:43:49][pluginWeb:FileChecksumMatch ] Local hash of file doesn't match expected: C:\Repository\repl2\software\9480\Visual Studio 2015.zip.2eb6ef69e7eeebe2e532b2996a8431c1.part: 2eb6ef69e7eeebe2e532b2996a8431c1 (expected) !=edd9f741a5cd3093ce94ece6ba71ec30 (found)
[2015-10-07.10:43:49][pluginWeb:ReplicateFile ] ReplicateFile: download failed and part file C:\Repository\repl2\software\9480\Visual Studio 2015.zip.2eb6ef69e7eeebe2e532b2996a8431c1.part checksum didn't match
[2015-10-07.10:43:49][pluginWeb:ReplicateFile ] ReplicateFile: download failed, if interrupted, keeping part file

Notice how the file name is changed to Visual%20Studio%202015.zip

After noticing this, I changed the file name to VisualStudio2015.zip and it replicated to the RS without issues.

It is weird though since the MD5 check should be the same despite the name of the file, so I don't know if my logic is right and that was the actual issue, but I can possitively say that after removing those spaces the file replicated ok.

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login

Share

 
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