If like me, you find yourself working for a client using a profile/user environment management tool such as Liquidwares ProfileUnity, you may come up against the problem whereby user defined keyboard layouts repeatedly refuse to persist between sessions when using Windows 7 or Windows 2008.
To put it into context, a user logs on and decides to change their keyboard layout from English (UK) to French (FR) or German (DE) and happily works for the duration of their session. The next day, having previously logged off their non-persistent desktop/RDSH, they logon again only to find that their Keyboard layout has reverted to English (UK). This goes on for a few days before the users get irate and find themselves experiencing Groundhog Day.
In my case, the client had implemented ProfileUnity having migrated away from VMware Persona (which is a slightly glorified version of MS roaming profiles) where the problem didn’t previously exist and logons reliably retained keyboard layout preferences. It’s a hard sell to tell a user when you introduce a new product that it has a load of new features but that it falls short on core features that were previously taken for granted.
Having spent quite a few hours hunting around for solutions and also testing numerous configurations unsuccessfully, I logged a ticket with support who were really helpful but between us, we came to the conclusion that it was a limitation based upon the way the OS behaves and handles keyboard layouts when associated with profile management tools. I was now at the point of giving up. From a sequencing perspective and understanding what was happening, despite ProfileUnity successfully retaining and restoring the required personalised keyboard layouts, because the restoration of the required registry keys was happening too late (as Windows sets the keyboard prior to the hand off to ProfileUnity) the keyboard layout injected by ProfileUnity just wasn’t being honoured, despite its best intentions to do so.
At that time I only had a few options left:
1) use GPOs configured with registry preferences that force the users keyboard layout to a specific language based upon item level targeting driven by users AD group membership (GPO’s are processed in sufficient time for the OS to honour the values)
2) configure multiple mandatory profiles each pre-configured with the required keyboard layouts that are delivered to users, again based upon ad group membership with item level targeting.
3) implement ProfileUnity Profiledisk. This would keep the entire ntuser.dat file on a VHD that would be mounted on logon. This would certainly overcome the problem, but unfortunately would introduce a number of limitations that Portability overcomes (Portability is the method used by ProfileUnity to selectively save and restore certain aspects of the profile)
As I’d discounted option 3, in the case of 1 and 2, this would mean that a user would lose their ability to retain and selectively choose their keyboard layouts and require administrative input to ensure they are placed in the right AD group. Not ideal by any stretch, but a compromise on at least providing a user with a consistent keyboard layout.
Before throwing in the towel, I finally stumbled across the following command from Microsoft:
control.exe intl.cpl,, /f:”C:\keyboard.xml”
Having read the documentation, when the command is combined with an appropriately configured XML file, it looks to be able to change the keyboard layout dynamically.
Excellent I thought! So I created an XML file (called keyboard.xml) with the following content in an attempt to flip the language to Swedish and ran the command above from Start –> Run:
<gs:GlobalizationServices xmlns:gs="urn:longhornGlobalizationUnattend"> <!-- user list --> <gs:UserList> <gs:User UserID="Current"/> </gs:UserList> <!-- input preferences --> <gs:InputPreferences> <gs:InputLanguageID Action="add" ID="041d:0000041d" Default="true"/> </gs:InputPreferences> </gs:GlobalizationServices>
Immediately, it didn’t appear to do anything. so I clicked Start –> Run again, only to find that in the context of the Run command, I was in Swedish! Great result, but I was only in Swedish for the one specific Window. If I clicked any other Window, it would revert to English (UK).
I suddenly had a brainwave and figured that if I ran the same command during the logon process, using the “Application Launcher” mechanism within ProfileUnity (to let me run this when I want) it could force the correct application of the required keyboard layout before the Windows Shell is invoked.