Thursday, 27 July 2017 14:08

Mastering Windows 10 Language Packs

Written by
Rate this item
(2 votes)

image

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 25893 times Last modified on Friday, 25 August 2017 06:44
  1. Comments (6)

  2. Add yours
This comment was minimized by the moderator on the site

Hello!

Great article! Do you have new information as to how LXP packs (apparently user-side language packs in appx format, also available from the store?) are te be deployed (or if it is even possible to do so) with MDT?

Windows 1803 introduced...

Hello!

Great article! Do you have new information as to how LXP packs (apparently user-side language packs in appx format, also available from the store?) are te be deployed (or if it is even possible to do so) with MDT?

Windows 1803 introduced them along the traditionnal LPs in cab format, but Win10 1903 ditches the cab format for language packs...

Thanks for your answer if you have any experience with this new Windows version.

Read More
Dennis
This comment was minimized by the moderator on the site

Great question. Personally - I don't have any hands-on experience, so take this answer with a grain of salt. There are actually several answers.


  1. Microsoft still makes legacy language packs available for Windows 10, version 1903. I downloaded a...

Great question. Personally - I don't have any hands-on experience, so take this answer with a grain of salt. There are actually several answers.


  1. Microsoft still makes legacy language packs available for Windows 10, version 1903. I downloaded a 1903 LP ISO just yesterday.
  2. Microsoft is on the journey to replace lp.cab with LXPs. Starting in 1809, for all LIP languages lp.cab has been retired and LXP is the only way to install them. For SKU languages or full languages such as Japanese, you still need lp.cab. Therefore the ISO contains LXPs for LIP and lp.cab for SKU languages. So in 1903 you can continue using lp.cab for SKU languages that are provided with the ISO.
  3. For LXPs you will need to use the Add-ProvisionedAppXPackage cmdlet to add a Local Experience Pack to your Windows 10 image.
  4. MDT currently does not support LXPs. You will need to write a PowerShell wrapper to automate the process. I've been told, that Microsoft is working on a MDT update to address this change.

Hope this helps.

Read More
Comment was last edited about 5 months ago by Anton Romanyuk Anton Romanyuk
This comment was minimized by the moderator on the site

Hi, I'm a technician at our local school and wanted to install the new 1903 on our systems, the problem is that all machines need to have the welsh interface pack, unable to install before image as sysprep fails and unable to install after...

Hi, I'm a technician at our local school and wanted to install the new 1903 on our systems, the problem is that all machines need to have the welsh interface pack, unable to install before image as sysprep fails and unable to install after joining network due to GPO settings and windows update restrictions (WSUS) Is there a way around this at all?

Thanks

Read More
Andrew
This comment was minimized by the moderator on the site

You are most probably referring to the new LXPs? Have you tried adding the welsh one as provisioned appx package? It should be available as part of the language packs ISO from VLSC.

Anton Romanyuk
This comment was minimized by the moderator on the site

How to do it in SCCM ? can I use the same command and scripts ?

Abdul Jalil
This comment was minimized by the moderator on the site

To set the system language after the fact? Yes. Dealing with unattend.xml is somewhat different in ConfigMgr. I do not think you need to jump through that many hoops to achieve the same result since usually ConfigMgr installs are not user-driven.

Anton Romanyuk
There are no comments posted here yet

Leave your comments

  1. Posting comment as a guest.
0 Characters
Attachments (0 / 3)
Share Your Location

Recent Posts

  • 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 Corrupted Store Apps
    A few days ago I began experiencing issues with built-in Windows apps where various apps would flash open and close…
    Written on Wednesday, 14 August 2019 13:36
  • 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
  • Windows 10 1903: Useful Resources for IT Professionals
    Windows 10, version 1903 is now available via Windows Update for Business, Windows Server Update Services (WSUS) and the Volume…
    Written on Friday, 07 June 2019 11:21
  • Windows 10 1903 Built-In Apps: What to Keep
    The development of the Windows 10, version 1903 is finished and the update is now available for download from Visual…
    Written on Monday, 03 June 2019 06:59