Windows 10 1703, Language Pack fun and games

I wanted to write a companion piece article to Damon Johns ‘Adding Language Packs in Windows 10 1703 – The OOBE Debarcle!’ blog post, based on some observations I’ve had attempting to apply language packs to the Windows 10 1703 build.

I’ve been having quite a few conversations with Damon Johns during the last couple of weeks in an attempt to understand why things weren’t happening for me when deploying a language pack and trying to set the default system language to match on the 1703 release.

Before you begin to read this I suggest you take a look at Damon’s fantastic write up of his experiences here and then loop back to pick up on this article.

OK, if you have read Damon’s blog post then I hope you have taken note of the following:

  • A screen asking if I wanted to join my work network in the form of
  • A screen asking what sort of display language I wanted to choose
  • Display language not being set correctly – AGAIN!

I suffered from all these woes along the journey but I can also add the following to the list, a couple of things that Damon didn’t get:

  • Win 10 hanging on the the ‘Just a moment’ screen indefinitely after a build
  • An error message ‘Oops something went wrong’ after the build had completed, which I was then allowed to skip past.

Note that the above two errors can be rectified by reintroducing the deprecated SKIPMACHINEOOBE and SKIPUSEROOBE tags in your unattend file. These settings are not recommended for production devices, however we have little choice but to use them on the current 1703 media. More on how to add those later.

The real reason that I am writing this blog post is that, whilst Damon’s solution worked for him. I was able to implement a completely different solution to get language packs working for me in the build and we didn’t have consistency in our log files.

So it may be a case of finding the method of implementing language packs that work best for you in your OSD. I’ve presented this alternative, in the hope that it speeds up the time it takes you to implement what should be a simple task.

Offline Language Packs or DISM

You have a choice of using the MDT Offline Language Packs, if you are MDT integrated, or executing a DISM command when injecting the language pack in your OSD. Both work well and will achieve the same result for you. Some things to note when using these options:

  • Windows 10 language pack are version and architecture specific. Make sure you have downloaded the correct ones before attempting to deploy. To make sure you have the correct ones, I suggest installing them manually on a Win 10 device using the command lpksetup.exe and browsing to the .cab file. The install will tell you if the lp is incorrect.
  • When using the MDT Offline Language packs make sure you use the correct file structure when creating your package in ConfigMgr. The .cab file MUST reside in a sub-folder and not the root of the package. If you fail to do this the install of the language pack will fail to happen, however your SMSTS.log will report a success. You’ll then be scratching your head wondering why the language does not appear in your Windows 10 build.
  • When using the MDT Offline Language packs the Task Sequence step must be executed in the WinPE phase of your build.
  • When using a DISM command the Task Sequence step must be executed in the full OS phase of the build, any time after Setup Windows and ConfigMgr
  • When using the DISM command ensure the following settings are in place:
    • Use a Run Command Line step
    • Use the command ‘cmd /c dism.exe /online /Add-Package /PackagePath:<path to cab>
    • Check Disable 64-bit file system redirection
    • Select the package containing the language pack.

Use an unattend.xml or another method to set locale?

During my testing, I had issues getting Windows 10 1703 to set the system display language correctly, all other settings were happy consumed from my unattend.xml file. Eventually I was able to find a solution that worked for me, but in the meantime I looked at alternative methods to achieve this.

Roger Zander has written an excellent article on how to leverage an xml file and the control.exe intl.cpl command to change all the region and locale settings. Here’s a link to his blog post. This script works very well, the only downside to it is that you will have to create an XML per country, whereas with an unattend.xml you can enter variables and pass these through so that only one file is required along with a bit of Task Sequence engineering. Although please correct me if I am wrong and you can use variables with Roger’s script.

The Unattend.xml file, what works?

If you take a look at Damon’s article you’ll note that he’s had to flip the settings for UILanguage on their head to get them to work for him. What do I mean by this? Well to successfully implement a change in UILanguage to Dutch, for example, Damon had to set UILanguage en-US, the same as the media, in both the specialize and OOBE passes of the unattend. All his other settings, systemlocale, userlocale and inputlocale were set for Dutch. This really doesn’t make any sense whatsoever but it works for him.

If you take a look at the setupact.log file, located in the c:\windows\panther\unattendgc folder, that is generated when Damon attempts this you’ll notice the following

Everything is fine in the specialize pass


but things aren’t looking so sweet in the OOBE phase with the errors ‘Unattended setting could not be found. error:(2). Ignoring’ being generated for UILanguage, UILanguageFallback, UserLocale and InputLocale. In fact, only the SystemLocale was being successfully applied on this pass.


When I attempted this, the result was that the systems settings were all in the language I required, Danish in my case, but the system display settings were in en-US. Not the result I wanted.

Looking at my setupact.log you’ll note, however, that the UILanguage was applied successfully in both the specialize and OOBE passes and no other failures occurred in the OOBE pass.



To get the end result that I wanted, language pack applied and the default system language to match, I had to revert to the more traditional approach of setting the UILanguage to the same as the language pack. So UILanguage was da-DK for Danish.

The settings were successfully applied in the specialize


and OOBE pass, with no errors,


and this particular method worked for me.

But to throw a curveball, on my last set of tests, neither of the successful methods, Damon or mine, would work in my test lab using the Windows 10 1703 evaluation ISO downloaded from Microsoft. At present, I am unable to set the system display language to match the language pack. I will spend some time over the next week re-testing but on the last set of tests I noticed that the OOBE passes was completely failing to be applied in my setupact.log, with the same errors as Damon observed, and I was presented with a prompt to choose which language to apply at the completion of the build.

So no real consistency at all with regards to getting the end result you want it seems.

Oops Something Went Wrong

As I mentioned at the start of the article, after a successful build I am presented with an error message of ‘Oops Something Went Wrong’. There is a workaround for now, but note that to further the inconsistent behaviour being experienced, Damon did not get this error.

To get rid of the error, edit your unattend file and enter


in the <OOBE> section of the XML file.

So there you have it. Let me know how you have got on with apply language packs and setting the default system display language on your Windows 10 1703 builds.





  1. Firstly thanks to you, Damon and Roger for giving me some direction on this language mess.
    I kinda made it work but still need more testing with various permutations and combinations but below are few comments:
    1. You can use DISM to apply the language pack online or offline
    2. Even i was getting the same error “UILanguage cound not be found” until i installed the language pack using the DISM command something like below “before” setup Windows and configmgr step. MDT Install Languagepack Offline step also may work but it failed intially may be when i didnt know how this worked.
    cmd.exe /c X:\windows\system32\dism.exe /ScratchDir:%OSDisk%\Windows\Temp /Image:%OSDisk%\ /Add-Package /
    3. Looks like UILanguage can only be changed/set if the respective language is already installed in the WIM or the offline image (image is offline before Setup Windows and confignmgr step”)
    4. Based on the blogs and few other people telling me that setting the UILanguage to specific language means that the OS has to be of the same language during in-place upgrade scenarios.
    5. When i executed an en-US setup.exe on a es-ES version of W10 (UILanguage = es-ES) manually, then setup gave an error and asked if we want to change the display language.
    It was trying but i screwed up the installation in between for some reason. So i wont say it is not possible to use a differet OS during upgrades but the “Servicing” may not work is what i am guessing but a Upgrade TS with custom steps may work.
    6. I was also told that you need language specfic software updates to downloaded (or the metadata) when using a non en-US version but i was able to deploy software updates (within the OS and using Install Software Updates step in the TS) on a Spanish (es-ES) version without doing any extra changes to software updates.
    7. Considering the 4th and 5th point, i decided to use en-US OS (ISO) but somehow change the actual dispaly language to something else
    which means UILanguage = en-US but Dispaly language is Spanish for example.
    5. I used Roger’s method to achieve it by using
    cmd.exe /c control intl.cpl,, /f:”RegionalSettings_%OSLanguagePack%.xml”
    6. You mentioned that you found a solution for this (pt 5), do you mind sharing it? I tried DISM /set-intl but didnt change the Display lanague
    7. I have tweaked the XML file to only change the display language not locations or input languages.
    8. I am using TSGUI (pretty cool and useful tool) for taking input and setting the UserLocale, KeyboardLocale and TimeZoneName hence i didnt want Roger’r method to change/update these.
    As other values are being set correct, i just wanted the Display language to change to the selected language in the TSGUI wizard.
    9. Also i was setting the KeyboardLocale to values like 0c09:00000409, 1009:00000409 etc but now i changed them to en-AU, en-CA, es-CL etc and it works (easier to read and manage)
    10. I also wanted additional keyboards to appear in addition to what is selected so i am setting a variable like this in the TS. I may add this to TSGUI xml file instead of this though.

  2. Hi there,

    Just wondering why you’re not installing the language pack in the ref image? What’s the benefit to doing it in ConfigMgr?
    We thankfully only have to deal with one LP (english base OS) and apply it in MDT, no issues on neither 1607 nor 1703. (Well, that is, we had an issue with the 1607.1 ISO after removing Appx packages, but that’s another story.)
    I’m simply adding the LP as a package in MDT, create a selection profile for it, copy the GUID and in CustomSettings.ini alter the GUID after LanguagePacks001=””.
    In addition there’s a step in the TS under Preinstall for Install Updates Offline with the selection profile.

      1. Also I prefer to only install the lp required for that particular build rather than installing x amount of languages. There are benefits to doing it either way. Choice is yours

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s