When you say a Zip file, do you mean an uncompressed archive that would be the same size as all the individual files? Or do you mean a compressed archive? Because right there, if you are talking about a compressed archive, you'd have a faster transfer, which strictly speaking would be better. Of course, if you take into account the amount of time it takes to make the archive, and how long it takes to extract the archive, then the specs of both machines come into play as to whether the archive is better than loose files.
Now, since you are talking about RDP (as opposed to VNC), the bandwidth usage of the remote connection is quite a bit. RDP is more responsive than VNC, the color depth is (by default) more than 256 colors (32 bit if you don't change it), the screen size will be the size of your desktop, etc... all of these factors affect how much bandwidth is being used just for the remote connection. If you drop things like... the size of the remote desktop, and color depth to 16 bit or less, make sure you aren't sharing sound, etc... this will use less bandwidth for the remote connection, so that when you are transferring files, the remote session should be more responsive.
In the end though, unless you can throttle the file transfer, the remote session is going to get sluggish no matter what you do while you are transferring files, since as much of the available bandwidth as possible is going to be used for the transfer between the remote machine and your machine.
EDIT
You are attempting to find a simple way to transfer files WITHOUT affecting the quality of the remote connection. It doesn't matter if they are large files or small files. At your end (the client machine) you are squirting small amounts of data up to the remote machine (server machine). You know... typing, mouse commands, etc. The server is sending large amounts of data to you all the time, in the form of the images that are making up what you see across the remote connection. So, before you transfer any files, you are ALREADY transferring a large amount of data in one direction. That's why I brought up the things you could do to reduce the amount of data you are transmitting.... namely use a smaller resolution for the remote machine on your desktop (as opposed to full screen).... reducing the number of colors from 32 bit to 16 bit or even 8 bit. Those two steps right there will drop the amount of data you are transmitting from the server (remote) to the client (you). It also means that when you start transferring files along the same connection and route, your remote connection will suffer less.
As I said... nothing you can do will make the connection stay crisp and responsive. Why? Because as soon as you start transferring files from the server to the client, this is going to suck up every bit of bandwidth that is available along that pipe.... and you are already using some of the bandwidth along that pipe for the remote connection itself.
First I tried to copy&paste before midnight when the transfer speed was limited by client computer ISP to 100 kB/s. So, it required a few hours and I was forced to cancel transfer since remote desktop became too unresponsive and sluggish (slow). So, I re-started it over midnight when my local transfer speed is over 4 GB/s
So when you first tried the transfer, you had a download connection of 100kb/s. You were moving 1.2gb of files as fast as possible, which would push to eat up as much of that 100kb/s as it could. Which would leave what room for the data supporting the remote desktop connection? So, of course it would be sluggish and unresponsive. The only thing you are not also taking into account, is the UPLOAD speed of the server. If the upload speed of the server is less than your download speed... and in this perfect hypothetical the route between the server and you allowed for this upload speed to remain constant, as soon as you start to transfer the files, just about all of that bandwidth is going to be eaten up by the file transfer, which will make the remote connection suffer.
Why?
Because there is nothing throttling the file transfer to a specific speed, or a percentage of available bandwidth, it is going to attempt to use every kb/s it can. By the nature of things, this will make the remote connection suffer.
Even transferring the files from the server to a third party (like an FTP server somewhere) would make the connection sluggish during that transfer, because again, as much of the available bandwidth as possible would be allocated to that transfer. Once that transfer was done however, you would be able to download it from the FTP server with no effect on the responsiveness of the remote connection... again because your incoming pipe after midnight is much larger than the server's outgoing pipe.
So, I would try reducing the quality of the remote connection.
i found the solution. It was at the same time both subtle, and obvious.
As mentioned in the question, when i was modifying the following Remote Desktop Connection Client Group Policy settings:
- Prompt for credentials on the client computer
- Do not allow passwords to be saved
i was checking them on the server:
i thought it would be the server that dictates what the client is allowed to do. Turns out that is completely wrong. It was @mpy's answer (while incorrect), which led me to the solution. i shouldn't be looking at the RDP client policy on the RDP server, i need to look at the RDP client policy on my RDP client machine:
On my client Windows 7 machine, the policy was:
- Do not allow passwords to be saved: Enabled
- Prompt for credentials on the client computer: Enabled
i do not know when these options were enabled (i did not enable them in recent memory). The confusing part is that even though
Do not allow passwords to be saved
is Enabled, the RDP client would still save password; but only for servers below Windows Server 2008.
The truth table of functioning:
Do not allow saved Prompt for creds Works for 2008+ servers Works for 2003 R2- servers
================== ================ ======================= ==========================
Enabled Enabled No Yes
Enabled Not Configured No No
Not Configured Enabled Yes Yes
Not Configured Not Configured Yes Yes
So there is the trick. The group policy settings under:
Computer Configuration\Policies\Administrative Templates\Windows Components\Terminal Services\Remote Desktop Connection Client
on the client machine need to be configured with:
- Do not allow passwords to be saved: Not Configured (critical)
- Prompt for credentials on the client computer: Not Configured
The other source of confusion is that while
- a domain Enabled policy cannot override a local Disabled
- a domain Disabled policy can be overridden by a local Enabled policy
Which again leads to a truth table:
Domain Policy Local Policy Effective Policy
============== ============== ==============================
Not Configured Not Configured Not configured (i.e. disabled)
Not Configured Disabled Disabled
Not Configured Enabled Enabled
Disabled Not Configured Disabled
Disabled Disabled Disabled
Disabled Enabled Disabled (client wins)
Enabled Not Configured Enabled
Enabled Disabled Enabled (domain wins)
Enabled Enabled Enabled
Best Answer
You can run the following commands on your remote machine one by one.
This is a temporary fix, alternately you can use an online copy paste tool.