Sorting it all Out Michael Kaplan's random stuff of dubious value Be sure to read the disclaimer here first!
It is well known that intl.cpl is a relentless beast that does what it is asked to with cunning nd ruthless efficiency.
If you know how to ask for it, at least. :-)
The question from the other day was simple enough:
After installing language pack on a English OS, the welcome screen language can't be changed back to English if it was changed to another language by running following command in system context.control intl.cpl,, /f:"settings.xml" setting.xml contains:
<gs:GlobalizationServices xmlns:gs="urn:longhornGlobalizationUnattend"> <gs:UserList> <gs:User UserID="Current" CopySettingsToSystemAcct="true" /> </gs:UserList> <gs:MUILanguagePreferences> <gs:MUILanguage Value="da-dk" /> <gs:MUIFallback Value="da-DK" /> </gs:MUILanguagePreferences> </gs:GlobalizationServices>
I don't know about you, but I like it when the answer is right there in the question!
Did you see it?
It is in the <gs:User UserID="Current" CopySettingsToSystemAcct="true" /> line.
Because by setting the user account and requesting that the setting be copied to system accounts, one has formally requested that the copy take place.
The user context/system context difference is simply whether the user running the script has permission to make the change!
Just like in this UI in Windows 7/Server 2008 R2/Windows 8/Server 2012 intl.cpl:
or this one in the Vista/Server 2008 intl.cpl:
The follow up question was:
Is there a way to revert this change on machines where this XML file was already used and the machines are in problem state?
It doesn't store any previous settings.
And there is no mulligan....
So, to fix, one would have to:
When this unattend feature was being created in Longhorn (which became Vista), this very scenario was discussed.
But the fact that the UI didn't support it made it less interesting, so the idea was dropped, especially since just running two files could get the desired effect.
Just like steps 1 and 2, above!