File transfers stop at 50% when using pull option

Comments

7 comments

  • Jprater

    Here's my post with what looks like the same problem: http://support.adminarsenal.com/entries/20414493-speed-decreases-gradually-when-deploying

    0
    Comment actions Permalink
  • Jprater

    I managed to get it to work, but not the way I wanted to. Because I was on a time crunch, I ended up installing PDQ Deploy on the new server, creating a new installer, and deploying it to the local machines. Not the way I wanted to do it. I meant to test it using the pull method, but I had left it the default of the push method.

    0
    Comment actions Permalink
  • Adam Ruth

    Yes, I remember this happening before, we weren't able to determine the cause.   The copy speed is just a running average, so if one file freezes the copy then the speed will slowly aproach zero.

    Unfortunately the probem appears to be that the Windows API call to copy a file simply never returns.

    What I'm going to do is put some additional logging in the copy process that will create a file on the target which will tell us exactly where the copy is stopping.  I can send you a special build with the logging, or you can wait until our next update in a couple of weeks, whichever you prefer. 

    0
    Comment actions Permalink
  • Jprater

    I'll wait until the next update. Thanks again for looking into this!

    0
    Comment actions Permalink
  • Adam Ruth

    The changes have been made and will be in the next update.  If you see it happen again, look on the target computer for the following two files:

    C:\Windows\PDQDeployRunner\1\files.ini
    C:\Windows\PDQDeployRunner\1\filecopy.log

    The "1" may be a different number.  Send those files to support@adminarsenal.com and I'll review them.

    0
    Comment actions Permalink
  • Jprater

    Awesome! I can't wait for it so I can test it out. I tried it again last night and got the same error.

    0
    Comment actions Permalink
  • Shane Corellian

    Just to update this ticket. We experienced a similar issue which turned out to be a faulty NIC driver. Here is what we discovered, as logged by Adam.

    "We've finally been able to duplicate this issue here in our lab, or at least duplicate the symptom.  In our case the cause was an out-of-date NIC driver.  We were able to consistently get the copy to grind to a halt when the "Large Send Offload (IPv6)" option was turned on in the driver advanced settings.  When disabling this setting or disabling IPv6 the copy would return to normal.  Updating the driver to the current version cleared it up completely.

    This may not be the same cause for you, but it's something to look into."

    0
    Comment actions Permalink

Please sign in to leave a comment.