Copying compressed files from Server 2008 R2 network share to XP client via VPN fails

Question

At the first sight the question looks similar to this one.
I have experienced an odd behavior while trying to copy a certain file from Windows Server 2008 R2 network share to Windows XP Professional client via VPN. The VPN was set up using RRAS on the server machine. I will try to provide as much informations as possible in order to make the issue more clear.

When trying to copy the compressed file sized ~2.5 MB (via Explorer or CMD, doesn't matter), the process stalls after some 20%, producing an error message after few seconds:

Cannot copy filename: The specified network name is no longer available.

If i start the command ping -t 192.168.2.1 (where the IP address specified belongs to the server) side by side with the copy command, I can clearly see that the ping command times out for few seconds as the copy process stalls. When this happens all network activities are frozen. After a few seconds, the network recovers, ping continues to run normally, however the copy process stands still before it displays the above error message.

Copying other files (I tried 4-5 files), of which some are larger and some are smaller, succeeds. Seems to me that I can copy all uncompressed files. As soon as I try to copy an archive, the process freezes. Even a 707 KB large archive can't be copied.

I can only reproduce this behavior on 2 machines, both Windows XP Professional, one is w/ SP2 and the other w/ SP3. Other XP clients don't have this problem, neither do Windows 7 clients.

If I connect to the server using Remote Desktop Connection without using VPN from either of these 2 machines (using the same user account), I can copy anything I want normally, even these "problematic" files.

Does anyone have any clue about what could possibly be going on?

Answer 1

Windows networking file transfer is very prone to this type of error for large files.

I would recommend using robocopy with the /Z (copy in restartable mode) option. This will allow the client to automatically resume from the point it left off instead of constantly starting over.

The condition can be caused by network load, server load, client load, or several other things. If it's always one specific file, though, I'd consider defragmenting the server and running a chkdsk on it, if possible. You may also want to check the disk load; you might need to take action to improve performance by adding more fileservers or changing the RAID type and controller or using physically faster drives.

Many VPN systems compress data as well as encrypting it (this often improves security and definitely improves bandwidth utilization), but this adds overhead that may contribute to latency. More specifically, the compressed file probably can't be compressed much more, so the network has a lot more work to do when transferring this file as compared to transferring the same file size of uncompressed data.