TS/RDP Mixed keyboard layouts

  • Thread starter Thread starter Lucvdv
  • Start date Start date
L

Lucvdv

I just found something that might be an issue in XP Pro too, I don't know.

An XPe target with Terminal Services is using one keyboard layout, an RDP
client with another layout connects to it.

The keyboard layout for the RDP logon screen is always correct at the
client.

If nobody was logged on locally to the device, the client gets a new logon
session with the correct keyboard layout as well.

But if the client logs into an existing session that was started locally at
the device, it switches to that session's keyboard layout (i.e. it gets the
device's local keyboard layout instead of its own).


Maybe that's not perfectly clear, so I'll explain how it happened here:
- device has AZERTY layout
- client has QWERTY layout
- the RDP logon screen at the client is always QWERTY (as it should be)
- if it's a new logon, the client remains at QWERTY after logging on
- if someone was logged on at the device, the client switches to AZERTY
after logging on.
 
Lucvdv,

I never tested the problem on XP/XPe.
However, I may suspect that the issue is RDP related on all Windows problems.
Anyway, check out this article http://support.microsoft.com/default.aspx?scid=kb;en-us;260333. Add the reg.settings to your client
machine and see if it helps (let us know if it is). More details info (CE based but it does not matter):
http://msdn.microsoft.com/library/d...html/wce50conremotedesktopprotocolsupport.asp


Also, this pretty old KB article may be helpful to you too: http://support.microsoft.com/default.aspx?scid=kb;en-us;322042. It is
Win2K, not XP. But we all know that may bugs came to XP from 2K :-)
Please note that [HKCU\Software\Microsoft\Terminal Server Client],"Keyboard Layout" value is also there on Windows 2000. That tells
us that it is likely supported on XP too.

I am not sure if the [HKLM\SYSTEM\CurrentControlSet\Control\Keyboard Layout],"IgnoreRemoteKeyboardLayout" value is supported by XP
TS but it does not hurt to give it a try.

Let us know if it helps.
 

Doesn't work

This sets a layout on the device, so if it works, it would affect all
clients regardless of their local keyboard layout.

Doesn't work either.

I rebooted after adding the setting because it's in the CurrentControlSet
key, the value from 260333 still existed too, still didn't work.
 
Lucvdv,

Sorry, I am out of ideas now. Perhaps it is too late here.
Unless you want to create a PSS request where they would be able to debug the problem with sources, you will only have a workaround
to always log off from a RDP session on disconnect to have noone logged in on next connect.

KM
 
Lucvdv,

Sorry, I am out of ideas now. Perhaps it is too late here.
Unless you want to create a PSS request where they would be able to debug the problem with sources, you will only have a workaround
to always log off from a RDP session on disconnect to have noone logged in on next connect.

KM

Thanks for all your help.

I just tried it on a Win2000 server, connecting from two different Win2000
clients: exactly the same problem.

A session set up from one machine, disconnected, then picked up at the
other retains the first machine's keyboard layout.

I can't try XP Pro right now because I don't have access to enough machines
to test it, but I think I should have tried that first, instead of
bothering this newsgroup with a problem that isn't related to XPe :/
 
Lucvdv,
Thanks for all your help.

I just tried it on a Win2000 server, connecting from two different Win2000
clients: exactly the same problem.

I think one of the links I sent earlier was about the same problem on Win2K server. That is why I thought it might still apply to
XP/XPe. But you said it did not.
A session set up from one machine, disconnected, then picked up at the
other retains the first machine's keyboard layout.

I can't try XP Pro right now because I don't have access to enough machines
to test it, but I think I should have tried that first, instead of
bothering this newsgroup with a problem that isn't related to XPe :/

Yup. Probably something like microsoft.public.windows.terminal_services may serve better.
But first you do want to repro the problem on XP Pro. Otherwise they will tell you to do so first anyway :-)
 
Back
Top