The saga of the Bad Keyboard Layout (XenDesktop 5+ + DesktopAppliance) (CTX coming for that bug)

Hi everyone

Today I will post about a big bug. Seem a easy’s one, but it took 2 Tier 3 support technician from Citrix and 1 dev from Citrix to get a workaround 🙂 (Not to forget the support case with Wyse !)

I got a workaround, no fix !

WHAT WAS WORKING:

In XenDesktop 4 with a Desktop Appliance the Keyboard Layout in the Virtual Desktop is handled as (Server Default)’s always.

The setup;
– The user profile, with Citrix UPM (like a roaming profile) is configured with a French Canada’s profile.
– The default’s one in the Preload’s section is configured with French Canada too.
– The Wyse/Desktop Appliance/Endpoint Device with a Citrix Receiver got configured with any Keyboard Layout.

So the client connect from anywhere in the world, and the keyboard layout in it’s Virtual Desktop is the one from it’s profile.

BUG:

If you update the Virtual Desktop to install the Citrix VDA’s Agent and Core Service to version 5 and more, it now do a keyboard importation from the device.

Seem a easy’s one you will told me, but what if Wyse didn’t coded the right Keyboard Layout for like French Canada ?

Bug like that appear;

 

So you clearly see the bug, the French (Canada) got bypassed by that “Canadian Multilingual Standard”. So you will tell me, wait, you did put that setting in the Wyse, but no !

WORKAROUND…

The one I did myselft before contacting the support…;

A script in the start-up menu in the All Users: (I call the .bat that way to hide the windows)

Set oWshShell = CreateObject(“WScript.Shell”)
oWshShell.Run “c:Import.bat”, 0, True

Import.bat:

reg import c:kb.reg
rundll32.exe shell32,Control_RunDLL intl.cpl,,/f:”c:kb.txt”

-There the first line do import the correct Preload key
-Now the second line simulate a click in the control panel to change the setting

kb.reg:

Windows Registry Editor Version 5.00

[-HKEY_CURRENT_USERKeyboard LayoutIMEtoggle] [-HKEY_CURRENT_USERKeyboard LayoutPreload] [-HKEY_CURRENT_USERKeyboard LayoutSubstitutes] [-HKEY_CURRENT_USERKeyboard LayoutToggle]

[HKEY_CURRENT_USERKeyboard Layout]

[HKEY_CURRENT_USERKeyboard LayoutIMEtoggle]

[HKEY_CURRENT_USERKeyboard LayoutIMEtogglescancode]

[HKEY_CURRENT_USERKeyboard LayoutPreload] “1”=”00001009″

[HKEY_CURRENT_USERKeyboard LayoutSubstitutes]

[HKEY_CURRENT_USERKeyboard LayoutToggle] “Hotkey”=”3” “Language Hotkey”=”3” “Layout Hotkey”=”3”

[HKEY_CURRENT_USERControl PanelDesktop] “MultiUILangageId”=”00001009”

kb.txt:

[RegionalSettings]
LanguageGroup=1
InputLocale = 0c0c:00001009

OK, BUG#2 after that.  Because, if my workaround would had work at 100% I would had not call the support…

In the initial login the script work and that all ok, the users see nothing wrong. The bug come after a period, the VDA’s agent seem to refresh it’s settings.

So in the day, usually 3-4 hours after the bad keyboard come out again. The bug appear less, because some users works in TS session like from XenApp, so their keyboard is ok. Some users see the bug when they try to edit some local text or in some local app.

WORKAROUND #2

You erase the wrong keyboard layout folder from there;

HKEY_LOCAL_MACHINESYSTEMCURRENTCONTROLSETCONTROLKEYBOARD LAYOUTS

Seem to work, but WAIT, in the refresh period the bad keyboard layout come back agains ! ark.

So, in the final the correct workaround is to set the correct ACL for the folder, only domain admin read, every other including SYSTEM with DENY’s flag. (so you does not erase it)

Thanks everyone, I hope it will help other.

As clearly we CAN’T stop that importation with the new VDA,s agent 5 and more and that leave the Virtual Desktop easy to break by Receiver or Appliance that does not follow the correct key to use.

Advertisement