No do-overs or mulligans in International!

by Michael S. Kaplan, published on 2012/08/17 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2012/08/17/10340803.aspx

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?

Unfortunately, no.

It doesn't store any previous settings.

And there is no mulligan....

So, to fix, one would have to:

Create a new XML file that sets everything back to English and does include the CopySettingsToSystemAcct="true" piece, and then
Run the original XML file that makes the desired per-user changes and does not include the CopySettingsToSystemAcct="true" piece.

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!

no comments

Please consider a donation to keep this archive running, maintained and free of advertising.
Donate €20 or more to receive an offline copy of the whole archive including all images.

go to newer or older post, or back to index or month or day