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 mydomain.com.au
- 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.