Windows TCR module - Keyboard Layout

[dotjesper]

Module proposal: windowsTCR should include keyboard layout configuration

Windows gecko's windowsTCR module currently manages Time zone, Culture, and Regional settings. A natural question is whether keyboard layout configuration belongs in this module as well - after all, keyboard layout is closely related to culture and regional settings, and it would seem like a logical extension.

This discussion explores the idea, weighs the benefits against the concerns, and captures the current thinking on scope.

The case for including keyboard layout

There are legitimate scenarios where keyboard layout configuration could add value:

• Consistency with culture settings - when windowsTCR sets culture to da-DK, the expectation is often that the keyboard layout should also be Danish. Including keyboard layout would allow a complete regional configuration in a single module
• Multi-region deployments - organizations deploying devices across countries could define keyboard layout alongside time zone, culture, and home location in the same CID-based configuration profile
• Correcting mismatches - devices provisioned with a generic OS image may end up with a keyboard layout that does not match the intended regional profile, and windowsTCR could resolve this automatically

A conceptual extension to the existing configuration could look like this:

{
  "windowsTCR": {
    "enabled": true,
    "configurations": [
      {
        "CID": "DEN",
        "description": "Denmark - Danish culture, Copenhagen timezone",
        "culture": "da-DK",
        "homelocation": 61,
        "timezone": "Romance Standard Time",
        "keyboardLayout": "0406:00000406"
      },
      {
        "CID": "SWE",
        "description": "Sweden - Swedish culture, Stockholm timezone",
        "culture": "sv-SE",
        "homelocation": 221,
        "timezone": "W. Europe Standard Time",
        "keyboardLayout": "041D:0000041D"
      }
    ]
  }
}

PowerShell approaches for configuring keyboard layout

Keyboard layout can be managed through the LanguageList cmdlets in PowerShell 5.1.

# Get the current user language list (includes input methods / keyboard layouts)
Get-WinUserLanguageList

# Set the user language list with a specific input profile
$languageList = New-WinUserLanguageList -Language "da-DK"
Set-WinUserLanguageList -LanguageList $languageList -Force

# Add a specific keyboard layout to an existing language
$languageList = Get-WinUserLanguageList
$languageList[0].InputMethodTips.Add("0406:00000406")
Set-WinUserLanguageList -LanguageList $languageList -Force

# Verify the current keyboard layout
(Get-WinUserLanguageList).InputMethodTips

Related resources

• Default input profiles - Input locale and keyboard layout reference
• Available languages for Windows - Language packs reference

[dotjesper]

Concerns and challenges

Despite the surface-level appeal, several significant concerns make this feature problematic.

1. Keyboard layout is configured during OOBE

The Windows Out-of-Box Experience (OOBE) explicitly prompts the user to select their keyboard layout. This is one of the first choices a user makes during device setup - and it is intentional. The user selects the layout that matches their physical keyboard and personal preference.

If windowsTCR overrides this selection after OOBE, it would silently replace a deliberate user choice with a configuration-defined value. This creates a poor user experience, especially when the user's selection was correct for their specific situation.

2. Keyboard layout is personal, not organizational

Unlike time zone, culture, and home location - which are typically determined by the device's geographic deployment location - keyboard layout is a personal preference tied to the physical keyboard hardware and the user's typing habits. Consider these scenarios:

• A user in Denmark with a US-layout keyboard (common among developers) would have their working keyboard layout replaced with Danish
• A bilingual user who deliberately added multiple keyboard layouts during OOBE would have their selections overwritten
• A user with accessibility-specific keyboard configurations would lose their setup

Time zone, culture, and home location are safe to enforce because they are location-based facts. Keyboard layout is a user preference - and overriding user preferences without consent is a different category of action.

3. Limited real-world usage

The practical usage of this feature would be very narrow. In most Windows Autopilot deployments:

• The OOBE keyboard selection handles the initial configuration correctly
• Users who selected the wrong layout during OOBE can change it themselves through Settings
• Organizations that need to enforce a specific keyboard layout can do so through Microsoft Intune device configuration profiles

The number of scenarios where Windows gecko needs to override a keyboard layout that was already set during OOBE is small, and the risk of overriding a correct selection outweighs the benefit of correcting an incorrect one.

4. Conflict with user-driven configuration

Windows gecko is a desired state configuration tool focused on device-level settings. Keyboard layout sits firmly in user-preference territory. Overriding it conflicts with the principle that users should control their own input experience - a principle that Windows itself reinforces by asking about keyboard layout during OOBE.

5. Microsoft Intune already provides this capability

For organizations that genuinely need to enforce keyboard layout, Microsoft Intune device configuration profiles support keyboard and input method configuration. Using the purpose-built management tool for this avoids the concerns above and provides proper policy-based management with compliance reporting.

Intermediate conclusion

After evaluating the benefits, concerns, and real-world applicability, the intermediate conclusion is that keyboard layout configuration is outside the scope of Windows gecko and the windowsTCR module.

The primary reasons are:

1. OOBE already handles it - keyboard layout is explicitly configured during the Windows Out-of-Box Experience, making post-OOBE override unnecessary in the vast majority of cases
2. User preference, not device configuration - unlike time zone, culture, and home location, keyboard layout is a personal choice tied to physical hardware and user habits. Overriding it silently creates a poor user experience
3. Risk of overriding correct selections - there is no reliable way to determine whether the current keyboard layout is "wrong" and needs correction, or whether the user intentionally selected it. The risk of breaking a correct configuration outweighs the benefit of fixing an incorrect one
4. Narrow applicability - the scenarios where this would genuinely help are too limited to justify the implementation complexity and the risk of unintended side effects
5. Existing alternatives - Microsoft Intune device configuration profiles already provide keyboard layout management for organizations that need policy-driven control

The windowsTCR module will continue to focus on Time zone, Culture, and Regional settings - settings that are location-based, device-scoped, and safe to enforce without conflicting with user preferences.

This discussion remains open. If there is meaningful community traction or if specific deployment scenarios surface where keyboard layout management through Windows gecko would provide clear value that cannot be achieved through Microsoft Intune, this decision can be revisited.

What are your thoughts? Have you encountered deployment scenarios where keyboard layout needed to be managed post-OOBE, and how did you handle it?