Updated: Based on a reader comment about a local drive connection not being required for copying and pasting text, I have updated this post. I previously was able to resolve text copy and paste issues by adding a local drive connection, but apparently that should not be required. Sometimes I have been able to restore text copy and paste by reconnecting to the RDP session, but many times that doesn't work.
Here is a post on the Terminal Server team blog that describes the problem in great detail, and actually points out that there are two different versions of the issue. If you can't copy from the server to your local computer, that is potentially a different problem than not being able to copy from your local computer to the server. In the latter case, disconnecting and reconnecting may resolve the problem. But in the former case, you may need to kill the rdpclip.exe process, then restart it.
If you work alot on remote client servers using Remote Desktop Connection, you have likely encountered a situation where you couldn't copy and paste between your computer and the remote machine. Sometimes copying files does not work, and sometimes copying text doesn't work either.
Many years ago, this was sometimes due to the "rdpclip" utility not being properly installed. But with newer versions of Windows, installing rdpclip should not be required.
So, if you can't get copy and paste to work with your RDP session, here are two things to check.
Open the RDP connection properties.
Select the Local Resources tab
Make sure that Clipboard is checked
Even though Clipboard is checked, copy and paste may still not work properly.
If that is the case, click on the More button at the bottom of the Local Resources tab.
Try checking the box next to one of your local drives. In some cases, this has resolved problems I have had copying text. And it appears that a local drive connection is required to copy and paste files to and from the RDP session.
If you are still unable to copy and paste, you can try terminating the rdpclip.exe process on the server and restarting it.
If you have verified both the settings on your RDP connection and tried to restart rdpclip, then it could be that the server has disabled clipboard mapping or drive mapping in the Terminal Services Configuration utility.
In that case, you can try and inquire with the system administrator to see if you can have those options enabled.
I'm guessing there are probably a few other reasons why copy and paste will not work, but these are the ones I've run into most frequently.
Hi Steve:
ReplyDeleteActually, you don't need access to local drives in order to share your clipboard between your computer and the host (I follow a standard where I never share a local drive over RDP, for security purposes).
From what I'd been able to gather, the rdclip service is still to blame (assuming everything else is set up correctly), but can somehow lose its connection with the server (I find if you leave the session a while, or open multiple RDP sessions at once, this can happen).
I've found simply disconnecting and reconnecting the session fixes the problem.
Thanks for the comment!
ReplyDeleteI did more testing and research, and found an article by the Terminal Services team that describes the problem.
I have updated my post with the link to the TS team blog and added some info on restarting rdpclip.
Restarting worked for me as well. I went all the way out and restarted GP from my desktop. My excel had been affected as well and it solved for that also.
ReplyDeleteThanks for the help!
Just came across my own comment from over a year and a half ago. Weird!
ReplyDeleteCame across it because I had the same issue again. This time the reboot didn't help.
It wasn't until I corrected the "error" in excel and converted all to numbers, that I was able to paste in GP.
daft key, "open multiple RDP sessions at once" - that solution fixed the problem. When i opened multiple RDP sesstion, i received an error with this rdpclick.exe, after that everything is perfect right now. Thanks a lot, man. Greetings from Bulgaria.
ReplyDelete