File transfers stop at 50% when using pull option
I'm using PDQ Deploy v1.5 release 2 in Pro Mode. I had a similar problem in a prior version. I'm attempting to deploy a software package over the WAN using pull mode--so the workstations at the branch site pull the software from the local server instead of our main one.
I've tried deploying a 600 MB directory and all of the transfers bombed out at 50%. The speed of the transfer simply dwindled down to below one. I PDQ Deploy set to only push 4 connections at a time.
Is this a possible bug? I am using PDQ Deploy on Server 2008 and pushing to Windows 7 clients. Thanks!
0
Comments
Here's my post with what looks like the same problem: http://support.adminarsenal.com/entries/20414493-speed-decreases-gradually-when-deploying
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.
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.
I'll wait until the next update. Thanks again for looking into this!
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:
The "1" may be a different number. Send those files to support@adminarsenal.com and I'll review them.
Awesome! I can't wait for it so I can test it out. I tried it again last night and got the same error.
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."