Windows MUI module

[dotjesper]

Module proposal: windowsMUI - Download, install, and activate MUI language packs

Windows gecko is a desired state configuration tool, and the idea of a windowsMUI module has been raised - a module that could download, install, and set a default Windows display language (MUI) as part of a Windows gecko configuration run.

The goal would be to ensure that devices provisioned through Windows Autopilot or Microsoft Intune end up with the correct display language, especially in multilingual environments where the base OS image ships with a single language (typically en-US) and additional languages need to be applied post-deployment.

Proposed functionality

The module would allow administrators to:

• Download one or more MUI language packs from Windows Update or a local/network source
• Install the language packs on the device
• Set a specific language as the default Windows display language
• Optionally remove installed language packs not listed in the configuration (desired state enforcement)
• Optionally configure language preferences for the Welcome Screen and new user accounts

A conceptual configuration could look something like this:

{
  "windowsMUI": {
    "enabled": true,
    "settings": {
      "defaultLanguage": "da-DK",
      "copyLanguageSettingsToSystem": true,
      "removeUnlistedLanguages": false
    },
    "dataset": [
      {
        "description": "Install Danish language pack",
        "language": "da-DK",
        "source": "WindowsUpdate",
        "setAsDefault": true
      },
      {
        "description": "Install Swedish language pack",
        "language": "sv-SE",
        "source": "WindowsUpdate",
        "setAsDefault": false
      },
      {
        "description": "Install German language pack from payload",
        "language": "de-DE",
        "source": "Local",
        "path": ".\\langpacks\\Microsoft-Windows-Client-Language-Pack_x64_de-de.cab",
        "setAsDefault": false
      }
    ]
  }
}

PowerShell approaches for installing MUI language packs

There are several ways to work with language packs from PowerShell. Below are examples of the most common approaches, along with notes on their limitations.

Approach 1: Install-Language cmdlet (Windows 11, PowerShell 5.1)

The Install-Language cmdlet was introduced with Windows 11 and is part of the LanguagePackManagement module. It downloads and installs language packs directly from Windows Update.

# Check if the LanguagePackManagement module is available
Get-Module -ListAvailable -Name "LanguagePackManagement"

# Install a language pack from Windows Update
Install-Language -Language "da-DK"

# Install a language pack and copy to the Welcome Screen and new user accounts
Install-Language -Language "da-DK" -CopyToSettings

# Get the list of installed languages
Get-InstalledLanguage

Note

Install-Language requires internet access to download the language pack from Windows Update. Download times vary significantly depending on the language and connection speed - a single language pack can be 200-400 MB.

Approach 2: Add-WindowsCapability (Features on Demand)

Language packs can also be installed as Features on Demand (FOD) capabilities using Add-WindowsCapability. This approach works on both Windows 10 and Windows 11.

# List available language-related capabilities
Get-WindowsCapability -Online | Where-Object { $_.Name -like "Language.*da-DK*" }

# Install a specific language capability (basic language pack)
Add-WindowsCapability -Online -Name "Language.Basic~~~da-DK~0.0.1.0"

# Install handwriting, OCR, speech, and text-to-speech capabilities
Add-WindowsCapability -Online -Name "Language.Handwriting~~~da-DK~0.0.1.0"
Add-WindowsCapability -Online -Name "Language.OCR~~~da-DK~0.0.1.0"
Add-WindowsCapability -Online -Name "Language.Speech~~~da-DK~0.0.1.0"
Add-WindowsCapability -Online -Name "Language.TextToSpeech~~~da-DK~0.0.1.0"

Note

Features on Demand capabilities are downloaded individually from Windows Update. Installing a complete language experience (basic, handwriting, OCR, speech, TTS) requires multiple separate downloads, compounding the time issue.

Approach 3: lpksetup.exe (legacy approach)

The lpksetup.exe utility can install .cab language pack files that are bundled as payload or downloaded beforehand.

# Install a language pack from a .cab file (silent, unattended)
Start-Process -FilePath "lpksetup.exe" -ArgumentList "/i", "da-DK", "/p", ".\langpacks\Microsoft-Windows-Client-Language-Pack_x64_da-dk.cab", "/s" -Wait -NoNewWindow

# Verify installation
Get-WinUserLanguageList

Note

This approach requires the .cab file to be included in the payload package or downloaded separately. Language pack .cab files are 50-200 MB each, which significantly increases Win32 app package size.

Removing unlisted language packs

To enforce desired state, language packs installed on the device but not listed in the configuration could be removed.

# Get currently installed languages
$installedLanguages = Get-InstalledLanguage

# Define the desired language list from configuration
$desiredLanguages = @("en-US", "da-DK", "sv-SE", "de-DE")

# Remove languages not in the desired list
foreach ($lang in $installedLanguages) {
    if ($desiredLanguages -notcontains $lang.LanguageId) {
        Uninstall-Language -Language $lang.LanguageId
        Write-Host "Removed language pack: $($lang.LanguageId)"
    }
}

Note

Uninstall-Language is part of the LanguagePackManagement module (Windows 11 only). The active display language cannot be removed - it must be changed before removal. Removing a language pack that was deployed by Microsoft Intune could cause Microsoft Intune to re-install it on the next sync, creating a removal/reinstall loop.

Setting the default display language

After installing a language pack, the default display language can be set using the Set-WinUILanguageOverride and Set-WinUserLanguageList cmdlets.

# Set the Windows display language override
Set-WinUILanguageOverride -Language "da-DK"

# Set the user language list with the preferred language first
$languageList = New-WinUserLanguageList -Language "da-DK"
$languageList.Add("en-US")
Set-WinUserLanguageList -LanguageList $languageList -Force

# Copy settings to the Welcome Screen and new user accounts
Copy-UserInternationalSettingsToSystem -WelcomeScreen $true -NewUser $true

Note

Setting the display language typically requires a sign-out or restart to take full effect. The Set-WinUILanguageOverride cmdlet sets the override for the current user - it does not change the system default language.

Related resources

• Add Windows 10/11 languages to devices
• Available languages for Windows
• LanguagePackManagement module
• Add-WindowsCapability

[dotjesper]

Concerns and challenges

Several significant challenges have been identified during evaluation of this module.

1. Download time and unpredictable execution duration

Language packs downloaded from Windows Update can be 200-400 MB each. If a configuration requests multiple language packs, the total download time can easily exceed 15-30 minutes depending on connection speed and Windows Update service responsiveness.

This is a fundamental problem for Windows gecko, which is designed to execute as a Win32 app during Autopilot provisioning. Long execution times can:

• Cause the Intune Management Extension (IME) to consider the script as hung or timed out
• Delay the Autopilot enrollment status page (ESP) and degrade the end-user experience
• Create unpredictable execution times that are difficult to plan around, since download speed and Windows Update availability are outside the administrator's control

2. Payload bloat for offline installation

Bundling language pack .cab files as part of the Win32 app payload avoids the download time issue during execution, but introduces a different problem: package size. A single language pack .cab file is 50-200 MB. Including two or three languages would push the Win32 app package well beyond reasonable size limits, increasing download time from Microsoft Intune and storage requirements.

3. Conflict with Microsoft Intune language pack management

Microsoft Intune already has a mechanism for deploying language packs to devices. If both Windows gecko and Microsoft Intune attempt to install or configure language packs, this could lead to:

• Race conditions where both processes attempt to download or install the same language pack simultaneously
• Conflicting language settings if Microsoft Intune and Windows gecko disagree on the default display language
• Unexpected behavior from the Windows language subsystem during concurrent operations

It is worth noting that while Microsoft Intune can deploy language packs to devices, it is the understanding that Microsoft Intune currently cannot set a language pack as the default display language - it only installs the pack. This gap is one of the motivations for considering a Windows gecko module.

For more details on the Microsoft Intune language pack deployment capabilities, see Add Windows 10/11 languages to devices.

4. Timing and execution context

The windowsMUI module would likely need to run in the SYSTEM context to install language packs, but setting the default display language (Set-WinUILanguageOverride) applies to the current user context. This creates a split-context challenge:

• Language pack installation: requires SYSTEM context (administrative privileges)
• Default language activation: requires USER context (per-user setting)

This would require either running the module in two passes (SYSTEM for install, USER for activation) or implementing user-context logic within the SYSTEM execution - both of which add complexity and fragility.

5. Constrained Language Mode compatibility

The Install-Language cmdlet and COM-based approaches may behave differently - or fail entirely - under PowerShell Constrained Language Mode (CLM), which is a requirement for Windows gecko in AppLocker/WDAC environments. This needs thorough testing before any implementation could proceed.

Intermediate conclusion

After evaluating the technical approaches, dependencies, and risks, the windowsMUI module is currently considered outside the scope of Windows gecko.

The primary reasons are:

1. Unpredictable execution time - language pack downloads from Windows Update introduce uncontrollable delays that conflict with Windows gecko's design as a fast, deterministic configuration tool
2. Payload size trade-off - bundling language packs avoids download delays but creates unacceptably large Win32 app packages
3. Overlap with Microsoft Intune - language pack installation is a capability that Microsoft Intune already provides, and duplicating this functionality in Windows gecko creates risk of conflicts
4. Split-context complexity - the requirement for both SYSTEM (installation) and USER (activation) contexts adds implementation complexity not present in other Windows gecko modules
5. Scope alignment - Windows gecko is a desired state configuration tool focused on settings, registry, features, and services. Language pack management is closer to software deployment, which is better handled by dedicated deployment tools

Recommended alternative approach

For organizations that need automated MUI configuration, the recommended approach is:

• Language pack installation - use Microsoft Intune's built-in language pack deployment, or deploy language packs through a dedicated Win32 app separate from the Windows gecko configuration package
• Default language activation - use the windowsRegistry and windowsRun modules in Windows gecko to set the display language override and user language list after Intune has installed the language pack

This keeps language pack delivery in the deployment layer (Microsoft Intune) and language activation in the configuration layer (Windows gecko), respecting the separation of concerns.

This discussion remains open for community input. If there are scenarios where the above approach does not work, or if Microsoft introduces new APIs that address the download time and context challenges, this decision can be revisited.