Jump to content
  • 0

Keyboard Layout change when screen is locked


Roberto Pereira

Question

Posted

We have a brand new XenDesktop 7.6 environement. We published the shared Desktop landing on Windows Server 2012 R2 Servers (Installation in German).  The Windows Servers are streamed with PVS to VMWare Sphere Hosts.

Now we have some users with following problem:

- When they lock the screen, the language changes automatically from German-Switzerland to German-Germany
- Now the signs like $ or @ don’t match the keyboard keys

But anywhere in Desktop the default language is German-Switzerland, as it should be.

Strange is that not all users are affected.

What we tried until now:
- Delete all unnecessary keyboard layouts on the Master Image (there is only German-Swiss and French-Swiss Layout installed) = Problem still persist.
- Delete all unnecessary keyboard layouts on the local machne of the affected users and connect again = Problem still persist.
- Created a GPO that deletes all unnecessary keyboard layouts, in the .Default and Current User = Problem still persist.
- An affected user connected over a client (PC or Notebook) from another user that don’t have this problem = As soon the screen is loked the language change anyway.
- A user who don’t have this problem connected over a client machine from an affected user = the locked screen shows the correct language.
- We made a new local and a new roaming profile (we use Citrix Profile Management) for an affected user = Problem still persist.
- We made a new roaming profile for an user who don’t have this problem = the locked screen shows the correct language.
- We tried different Citrix Receiver versions like 4.1, 4.2 and 4.3 = Problem still persist.

Registry keys we deleted on the machines and with the GPO:
-    Software\Microsoft\CTF\SortOrder\Language (every language codes except German – Switzerland 00000807)
-    Keyboard Layout\Preload (every language codes except German – Switzerland 00000807)

If an affected user starts the Dekstop over RDP, the locked screen showes the correct keyboard language. Only ICA sessions are affected.

Some has an idea what could cause this problem?

Recommended Posts

  • 0
Posted

Hey Loic,

Unfortunately we dont have a solution until now. But we have an open case with Citrix. As soon we find the solution, I will write it here.

The solution that you will find over Google is this one:
 

HKLM\SOFTWARE\Citrix\ICA Client\Engine\Lockdown Profiles\All Regions\Lockdown\Virtual Channels\Keyboard\KeyboardSendLocale

Edit [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout] registry key on the XenApp server to add the new entry
    b.Add the following entry:
       Value name: IgnoreRemoteKeyboardLayout
       Data type: REG_DWORD
       Value data: 1
 

 

You can try if that help. Otherwise I will write it here.

  • 0
Posted

Hi Roberto,

 

we had some issues with keyboard layout from devices other than windows client and maybe the issue could be the same. We had the problem that our language changed everytime we connected from iOS, MAC, Linux devices we have got english as layout instead of german.

 

The problem for us was that the default user keyboard preload value was set to "German (Austria)". Somehow there might be a issue so we have changed the default layout to "German (Germany)" and then the problem was fixed. This key does not mean that you have to use German (Germany) as layout but you have to know that there is some "translation list" for the keyboard layout and so this is just the entry point and it will still use the remote keyboard layout.

 

Give it a try, maybe it will solve your issue.

 

Here is the key:

 

HKEY_USERS\.DEFAULT\Keyboard Layout\Preload

 

REG_SZ: 1

Value: 00000407

 

After changing the key, reboot your server.

  • 0
Posted

Hi all,

 

I had the same behavior : the keybaordlayout users (swiss french) changed to the default System Layout (English UK)when users switched between apps (word, Outlook, notepad).

 

All User are not impacted.

 

W2k12r2

MCS

xendesktp 7.6

 

No news about this issue?

 

Br,

Brahim

  • 0
Posted

This issue is really astonishing me. I have 2 accounts that are almost identical (same group memberships, some polices, no cached profiles, etc). 1 account has the problem the other does not.

 

When I use the account with the problem and lock the screen, at that specific moment a see a number of keyboard layouts being added to HKU\.DEFAULT\Keyboard Layout\Preload.

 

When I use the account that does not have the issue then that key does not change and stays on 1 key with 00000409.

 

Ofcourse there still must be a difference somewhere, but still failing to see it.

 

One thing I noticed is that when the user disconnects/reconnects the keyboard is discovered correctly when the screen locks. Do you see the same Loic?

  • 0
Posted

Discovered something....

 

In HKLM\Software\Microsoft\Windows\CurrentVersion\SystemProtectedUserData\<USER SID> keyboard layout settings are stored. What I noticed is that these settings are set the first time you logon and does not change anymore. So if I start with a user account that gets certain keyboard layouts pushed with GPO's then those settings are stored in that path. Then if I change the GPO settings later, then they do not have an effect anymore. That explains that I thought I had 2 identical accounts (same group memberships, some polices, no cached profiles, etc), but still had different behavior.

 

Also we use roaming profiles, but local profiles are removed at logoff. But these settings remain. So on a large farm with many users this key can become very large.

 

So very close to a solution, but still need to figure out how to manage these keys effectively. Looking for GPO's that can do that...

  • 0
Posted

I think, this is a known issue.

We've it in our own environment and some partner has it too.

After some testing they saw the issue within a RDS environment.
After this I think, the source of this issue will be found in the dark deep of the Microsoft codes...

 

Has anyone opened a case at Microsoft support?

  • 0
Posted

I guess you have to create a script that overwrites this key:

 

HKLM\Software\Microsoft\Windows\CurrentVersion\SystemProtectedUserData\<USER SID>

 

 

Or did anyone found a more elegant solution to the problem?

 

In our case we were able to get rid of the problem by not setting additional keyboard layouts.

  • 0
Posted

We could never solve this problem. We have also servers with only one langauge installed and it change anyway to another language???

 

But we have following workaround:

 

- The user press and hold "Alt" und then press "Shift" (with alt+shift you can change to the next language)

- Introduce password. If it works the correct langauge is selected

- Make a logoff to save the settings

 

Hope that helps.

  • 0
Posted

A colleague of mine found the solution for this problem, which I attempted to post a few weeks back. Apparently this wasn't appropriate to do, because I was informed my posting went to the Microsoft moderators and I can see it hasn't been released.

  • Like 1
  • 0
Posted

Thanks to Claus I got my issue resolved.

 

In Windows 2012R2/2016 there are some new keys under:

 

HKU\.DEFAULT\Control Panel\International:

 

User Profile

User Profile System Backup.

 

Deleting these keys seem to resolve the problem and now the lock screen keyboard layout is the same as my session. These keys don't exist in 2008 R2.

 

I also have another issue in 2016 where the OnScreenKeyboard pops up when you lock the screen. This is solved by disabling the touch keyboard service.

  • 0
Posted

Hi Guys, 

 

We also have the same issue with Windows 2012 R2 + XenApp 7.6 up to latest hotfixes + Citrix Profile Management 5.6.

 

There are few users affected and for those does not matter if you set via registry to ignore the client keyboard or if you set via GPP registry keys in .DEFAULT user or in CURRENT USER the Keyboard preload to be only to en-US ( 00000419) and to delete all the rest of the keyboard and if you delete the Keyboard Layout\Substitutes the result will be the same. 

 

Inside ICA session the keyboard layout is correct ( US international), but when their session is locked they will have Azerty keyboard. 

 

I am thinking that this can be caused by the fact that the template VMs  are installed in Dutch BE and somehow somewhere there is still something that still bring the initial Keyboard.

 

Now we found some leftovers of the template installation in :

HKEY_CURRENT_USER\Software\Microsoft\CTF\SortOrder\AssemblyItem\  and here it was found also the Dutch BE keyboard.

 

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\NIs\Locale\

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Control\NIs\Locale\

 

 

Here there are 2 REG_SZ keys : Default and Standard - Make sure both are having the same value. 

 

Till now the testing looks ok, but I am not 100% sure that the issue will not appear again.

 

 

Thank you,

John.

  • 0
Posted

My environment: XA 7.11, VDA 7.13, Receiver 4.7, 2012 R2.

 

Users had selected Dutch (Belgium) locally, so AZERTY. When they log in everything is AZERTY. Then they lock their published desktop. Suddenly it is English (International), but they can select Dutch (Belgium) in that screen. Then when they unlock their desktop, their already running apps were Dutch (Belgium). However every new app that started was English (International). When they toggled their local keyboard layout it got synced on the published desktop. When they then locked their desktop again it remain Dutch (Belgium) all the way.

 

The way I fixed it was by removing:

- the 'languages' key in HKEY_Users\.Default\Control Panel\International\User Profile

- Any key below HKEY_Users\.Default\Control Panel\International\User Profile

- the 'languages' key in HKEY_Users\.Default\Control Panel\International\User Profile System Backup

- Any key below HKEY_Users\.Default\Control Panel\International\User Profile SYstem Backup

 

Thanks Martijn for posting the details!

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...