Hi
First of all, many thanks for the marvellous job you have done : what a useful tool you create !
We are using MUI pack to change the display languages on our Windows 7 x64 Machines and version 3.6.0 worked well with these (EN-GE-FR)… But since version 3.6.2 and 3.6.3 (3.6.1 not tested) The language stays on English only even though the displayed language is otherwise !
The weird thing is the displayed language is well detected in log file :
<![LOG[[Initialization] :: Current Culture is [fr-CH] and UI language is [FR]]LOG]!><time=“11:02:02.522120” date=“04-30-2015” component=“PSAppDeployToolkit” context=“XXXXX\Administrator” type=“1” thread=“2688” file=“AppDeployToolkitMain.ps1”>
But below in the same log file, there entries that do not exit in the 3.6.0 log :
<![LOG[[Initialization] :: The active logged on user [XXXXX\Administrator] has a primary UI language of [EN].]LOG]!><time=“11:02:03.567120” date=“04-30-2015” component=“PSAppDeployToolkit” context=“XXXXX\Administrator” type=“1” thread=“2688” file=“AppDeployToolkitMain.ps1”>
<![LOG[[Initialization] :: The following UI messages were imported from the config XML file: [UI_Messages_EN].]LOG]!><time=“11:02:03.567120” date=“04-30-2015” component=“PSAppDeployToolkit” context=“XXXXX\Administrator” type=“1” thread=“2688” file=“AppDeployToolkitMain.ps1”>
These entries pretty much explain “why” it stays on the EN language but it’s not the expected behaviour to us obviously
Can you explain how to overcome that are go back to 360 behaviour which worked like a charm and was perfect ?
Final word : The tools are 100% identical to the downloaded packages. They have been left unchanged
Many thanks once again the tools
Marin
Please do not post the raw contents of the log file as it is very difficult to read. Please open the log file in CMTrace and copy/paste the properly formatted log contents from there.
At the start of the log file, the toolkit detects the UI of the system account executing the toolkit. This is most likely the UI of the SYSTEM account. This UI can be different then the primary UI of the logged in user. That is why the toolkit has switched to determining the UI of the logged in user. The user that was logged into the above system where you found the log entries probably had English as their primary UI. You can look at the logic in the toolkit.
Also, please use 3.6.3, the latest version of the toolkit, as there may have been some bugs around the detection in earlier versions of the toolkit.
HI
Thanks to the quick answer and sory for the log format. I already tested version 3.6.3 and I have the same behaviour. I forgot to mention that I’ve done the test manually (not using SCCM 2012 at that time), so the logged user is not using the SYSTEM account or the SCCM service acount if It has been defined. On my env it’s very easy tot test as long as you ahve couple of MUI pack on the PC : Just copy the two versions of the toolkit, switch a another language thab EN and launch manually deployapplication.exe and hopefully you will see the different behaviour immediately
BTW what to you mean by “Primary UI” ? With MUI pack the user can change the display with control panel, log of abd voila : new display language. So where Can i change / check the “primary UI” ?
BTW it could be very very very usefull to use a parameter in the deployapplication.exe command line instead of using the config.xml file because in SCCM using a simple parameter we just have to create on program (sccm terminology) instead of basicaly 3 packages or application… and we are done : no more detection problem … even thought when the detection is working it’s very very very perfect (just like in version 3.6.0)
One more time thanks a lot, for this amazing Toolkit
Marin
So if you have more than one MUI pack installed or a MUI pack installs more than one language, the primary UI language will be the one that the user selected.
Look at the toolkit starting at line 250. The registry keys listed here are what the toolkit uses to determine what the user’s primary UI language is. If the information the toolkit is looking for is not found in one key, it goes on to the next (you can ignore the comments about which key is for what version of Windows).
Take a look at these keys to determine why the toolkit thinks the UI language is English. If there is a mistake here, then let me know. Also, share the values you see for these registry keys on your machine.
One other thing to note is make sure that you are not overriding the detected UI language with English in the config XML. To make sure of this, the value for this property in the config XML should be empty like this: <InstallationUI_LanguageOverride></InstallationUI_LanguageOverride>
Hi Everyone
Ok I finally make some progress on the topic. First of all even though there is definitely a different behavior between 3.6.0 and 3.6.3 regarding how it detects / manage the languages we decided to go forward and test WITH SCCM since it, is after, the target
The findings : In 3.6.3 the detection of the language uses with MUI packs, the following registry key All for Windows 7 x64 :
HKEY_CURRENT_USER\Control Panel\Desktop\muicached\PreferredUILanguages
Which is strange since it is not the one used when a user changes its display language. The actual one is
HKEY_CURRENT_USER\Control Panel\Desktop\PreferredUILanguages
In a managed environment and therefore where the languages are controlled by GPO, the registry keys involved are totally différent So, obviously the detection fails because the registry keys, as you know, are not the same
For a User GPO the registry key to be used is :
HKEY_CURRENT_USER\Software\Policies\Control Panel\Desktop\PreferredUILanguages
For a Computer GPO the registry key to be used is :
HKEY_Local_Machine\Software\Policies\Control Panel\Desktop\PreferredUILanguages
So to make it totally work as expected taking into consideration MUI and GPOs the way it’s expected, the algorithm should be :
If MUI pack is defined in Computer GPO : Use This Setting (stored in
HKEY_Local_Machine\Software\Policies\Control Panel\Desktop\PreferredUILanguages)
Else
If MUI pack is defined in User GPO : Use This Setting (stored in
HKEY_CURRENT_USER\Software\Policies\Control Panel\Desktop\PreferredUILanguages)
Else
Use user Setting (Stored in : HKEY_CURRENT_USER\Control Panel\Desktop\PreferredUILanguages)
I Think it should be useful form everyone to include this to a incomming version
Best regards to all
Marin
Hu Back Again
I Think I get the point and the corresponding code for version 3.6.3:
In the AppDeployToolKitMain.Ps1 - [scriptblock]$xmlLoadLocalizedUIMessages
1/ There is a Typo : The code looks for “PrefferedUILanguages” instead of “PreferredUILanguages” (Actual of the value name in registry
2/ None of the 2 possible GPO settings Have been considered. These should be considered first since the should have precedence. The block for windows 7 / Vista machines should looks like something like :
# Read language for Win Vista/Win 7 machines
If (-not $HKULanguages) {
[string[]]$HKULanguages = Get-RegistryKey -Key 'HKLM\Software\Policies\Control Panel\Desktop' -Value 'PreferedUILanguages' -SID $RunAsActiveUser.SID
}
If (-not $HKULanguages) {
[string[]]$HKULanguages = Get-RegistryKey -Key 'HKCU\Software\Polices\Control Panel\Desktop' -Value 'PreferedUILanguages' -SID $RunAsActiveUser.SID
}
If (-not $HKULanguages) {
[string[]]$HKULanguages = Get-RegistryKey -Key 'HKCU\Control Panel\Desktop' -Value 'PrefferedUILanguages' -SID $RunAsActiveUser.SID
}
If (-not $HKULanguages) {
[string[]]$HKULanguages = Get-RegistryKey -Key 'HKCU\Control Panel\Desktop\MuiCached' -Value 'MachinePreferredUILanguages' -SID $RunAsActiveUser.SID
}
If (-not $HKULanguages) {
[string[]]$HKULanguages = Get-RegistryKey -Key 'HKCU\Control Panel\International' -Value 'LocaleName' -SID $RunAsActiveUser.SID
}
# Read language for Win XP machines
The GPO registry should of course being used for Windows 8 (and may be XP)
What do you think ?
Best regards
M.
Thanks for your troubleshooting. You’ve definitely discovered a bug we should fix in the next release of the toolkit. Please create an issue for this problem on GitHub and I will make sure to address this problem for our next release: https://github.com/PSAppDeployToolkit/PSAppDeployToolkit/issues