Thursday, 27 July 2017 14:08

Mastering Windows 10 Language Packs

Written by
Rate this item
(4 votes)


In order to deploy and service Windows 10 successfully, you need to carefully consider how you apply language packs. In today’s blog post I will discuss the approach that I use to deploy and service Windows 10 in a multi language environment using Microsoft MDT and one base Windows 10 image.

Let's go back a couple of months: In late 2016 I advised two of my customers, who just started transitioning to Windows 10, to get an early start with Windows as a Service. First of all, Windows as a Service, as demo-ed at Ignite, works fantastic – as long as you don't have any language packs installed.

Now, assume following scenario:

  • Each customer has over 10.000+ seats all around the world.
  • Base image is English (en-US) and then at least one language pack is applied during the deployment.
  • One of the customers is using ZenWorks for OSD while the other one relies heavily on Microsoft Deployment Toolkit.

During initial on site testing I ran into the following error message: C1900204, "MigChoice: Selected install choice is not available.".

Running the setup.exe manually showed that the upgrade option is greyed out.

Digging into the setupact.log I found following two lines:

2016-11-08 15:24:23, Info CONX ConX::Compatibility::CSystemAbstraction::TargetLanguageIsCompatibleForUpgrade: Target language en-US is not compatible with the host language (lang.ini path: C:\$WINDOWS.~BT\Sources\lang.ini).
2016-11-08 15:24:23, Info CONX CMismatchedLanguageChecker: checked MismatchedLanguage, found HardBlock.

It appears that when you apply a language pack as well as regional settings before operating system is fully online, your target language becomes your default language.

The requirement for the Windows Setup is that the system UI language of the INSTALL.WIM being used for upgrade must match the system UI language of the running OS. Adding additional language packs isn’t enough.

This has following implication:

  • In feature upgrade scenarios, if you are upgrading or migrating an operating system with multiple language packs installed, you can upgrade or migrate only to the system default UI language. For example, if German is the default, you can upgrade from Windows 1511 German to Windows 1607 German. You can’t use English install media. The more languages you have to support, the most install media you will need.
  • I have seen suggestions on the forums to change your UI language and then apply English upgrade. However, this won’t cut it, because if - for example - German language is selected during the initial installation it becomes the default system language. You will still run into the language mismatch error, even if you changed Windows' UI language post-setup.

Note: In SCCM I’ve noticed that if you try to update an English image with a German language pack via Servicing feature, it will download and install German upgrade package.

Even Microsoft IT is using language specific releases for their upgrade sequence: 

"To support five languages, Microsoft IT had to create 10 packages for doing the deployment on x86 and x64 devices. Microsoft IT chose not to pre-cache all 10 packages on the devices, and instead focused on pre-caching just the English US 64 bit, because that represented the largest population of users."

So, the described behavior is „by design“. Injecting a language pack while layering down an image and setting UILanguage property in Unattend.xml will effectively localize your Windows installation. In my case, this approach was a no-go due to the amount of data (~15 Windows 10 images) required to service all possible upgrade scenarios. So I came up with the following workaround: the main culprit appears to be the UILanguage setting in CustomSettings.ini / Unattend.xml. Setting this variable to the DVD language (in my case en-US) and injecting language packs during the offline phase results in the desired behavior.

Now, obviously there are some drawbacks:

  • First of all, you will end up with the UI language being set to the Media's language, so an additional step is required to adjust Windows MUI settings. The most straight forward approach is detailed here.
  • Additionally, you will need to update installed language packs as well as Features on Demand language capabilities during feature upgrade scenarios.

Note: This approach with MDT, SCCM or any other deployment solution you are using.

Also, if you are already in the process of deploying Windows 10 and need to change the system language in order to use English update media, there is a simple workaround:

It is possible to use DISM to change the system UI language in the existing OS offline (e.g. change the running OS to en-us as long as it has an en-us language pack, so it matches en-us upgrade media). You will need to boot to Windows PE, change the system UI language using DISM, then do the upgrade. Here is a command example:

Dism /image:E:\ /Set-UILang:en-US

How to do this in MDT:

  1. Grab GetMuiSettings.ps1 and SetMuiSettings.ps1 scripts from my GitHub repository. You will also need ZTIFlushVariables.wsf script. Created by Johan Arwidmark, this script is needed as a workaround for a bug in MDT 2013 where variables set in a PowerShell script are not flushed to the Variables.dat file on disk.
  2. Place all files in the Scripts folder.
  3. Open your CustomSettings.ini and add UILanguageTMP custom property. For example: Properties=UILanguageTMP
  4. Open your task sequence:
    • In the Preinstall phase add following two steps:
      Step Name Command
      Run PowerShell Script Get MUI Settings %DEPLOYROOT%\Scripts\GetMuiSettings.ps1
      Run Command line Flush Variables to Variables.dat cscript.exe %DEPLOYROOT%\Scripts\FlushVariables.wsf
    • In the State Restore phase add a Run PowerShell script step:
      Step Name Command
      Run PowerShell Script Configure - Set MUI Language %DEPLOYROOT%\Scripts\SetMuiLanguage.ps1

The GetMuiSettings.ps1 script will grab the value of the UILanguage variable and store it in the UILanguageTMP custom property. The SetMuiSettings.ps1 script will read the language value from the UILanguageTMP variable and create an xml file with the required settings and save it as a file at C:\temp\MUI.xml. It will then run following command line to apply the answer file settings: control.exe intl.cpl,,/f:"C:\temp\MUI.xml"

Note: Make sure that the temp folder exists prior to running the SetMuiSettings.ps1 script. Additionally, if your base image is not a US media, you will need to adjust all occurencies of the en-US value to match your install.wim. Additionally, depending on your implementation you may need to modify %DeployRoot%\Scripts\ZTIGather.xml. Locate UILanguage property definition and replace overwrite="false" with overwrite="true":

<property description="Default Locale used for OS before user is logged in, en-US format (default is OS Default)" overwrite="true" type="string" id="UILanguage"/>
Read 55530 times Last modified on Friday, 25 August 2017 06:44

Recent Posts

  • Windows 10 21H2 Built-In Apps: What to Keep
    The development of the Windows 10, version 21H2 is finished and the update will soon be available for download from…
    Written on Wednesday, 20 October 2021 11:41
  • Group Policy Changes in Windows 10 21H2
    As Windows 10, version 21H2 update development winds down, Microsoft is now preparing for the final release of the Windows…
    Written on Wednesday, 20 October 2021 07:20
  • Group Policy Changes in Windows 10 20H1 Preview
    As Windows 10 Vibranium Update (20H1) development winds down, Microsoft is now beginning the phase of checking in the final…
    Written on Tuesday, 14 January 2020 04:51
  • An alternative ESU MAK Activation Solution
    This blog post was shared with me by a colleague of mine, Daniel Dorner, a Microsoft Premier Field Engineer. It’s…
    Written on Wednesday, 04 December 2019 21:04
  • The Case of Missing UE-V Templates
    My customers often deal with unexpected Windows behavior and this case is no different. This particular one is especially interesting…
    Written on Tuesday, 03 September 2019 12:20
  • The Case of Changing Default Printer
    While I sometimes long for the day when I no longer have to deal with unexpected Windows 10 behavior, there’s…
    Written on Wednesday, 14 August 2019 20:36