Shift and Control keys out of sync with normal keys over RDP

Question

I spend quite a lot of time working on various machines via RDP (usually RDPing to one machine and from there RDPing to other computers outside our lan) and have an issue where the modifiers keys (ie Ctrl,Alt, Shift and Win) sometimes don't take affect as quickly as standard keystrokes.

For example, if I am trying to type "", I could end up getting 2" because the remote machine gets the first press of the 2 key before it get the shift modifier. This causes particular problems with password protected fields both (as they often require mixed case letters and the fact that you can not see what is typed) and with Ctrl-C (where the highlighted section is deleted and replaced with a C).

(And before anyone asks, this is not just bad typing otherwise the problem would not be restricted to RDP sessions).

This does not appear to be a hardware issue as it happens on my desktop (running 64-bit Windows 7) and on my laptop (32-bit XP) and on various Remote computers running various operating systems (from XP to Windows 2008 Server)

There are times when the problems is more pronounced and it may be related to a slow Internet/VPN connection.

Has anyone seen this problem and (other than always typing very very slowly, ie about 1 character per second), are there any solutions to this issue?

Answer 1

It is the way the RDP client responds to control keys. To resolve, try going into the options for the Remote Desktop Connection, Local Resources, Keyboard - change to "On This Computer".

Be aware that alt-Tab and similar commands will now run on the local system.

Answer 2

It's not "free" but some gamepads let you map buttons to key combinations...think out there mouse or numpad with wrist pivots(i think asus makes one). this MIGHT solve you problem....not 100%, but if it sends a combination it could. the slowing down of modifier keys could also be a cheap attempt at not passing on control sequences(if this turns out to be the case i would look in to VNC server/client as it's a busted solution)

Answer 3

I've found the solution to this where one is using nested instances of Microsoft's Remote Desktop client. Imagine the following situation. You're sitting in front of an OS X machine, and you remote desktop into a Windows 7 laptop. From the Windows laptop you want to remote desktop into another Windows machine (in my case a work box over VPN). The solution to your keyboard mapping woes is: on the Windows laptop, i.e. the destination of the first jump, change the remote desktop hardware settings for the 2nd jump to use the local keyboard, not the connecting one.