My advice: Just remove 'em all, then later only add the ones you actually need

by Michael S. Kaplan, published on 2011/09/06 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2011/09/06/10206558.aspx


You may remember when I wrote Lack of confidence in a feature can keep me from installing it. Oh yeah, a BSOD can, too.

And the other day, I saw the problem come home to roost, when the following question came in:

A customer installed every single Language Pack (LP) on W2K8 R2 RTM.
Now when he tries to install SP1 they are running into delays/failures.

So the recommendation was to uninstall the un-used LP’s but the customer wants to find which ones are not being used.

What’s the easiest way of accomplishing this?

I was thinking of going thru the user profile hive and see what the end-users were using.  But trying to see if there is a better method.

You can glean a few facts from the question:

  1. They didn't fix the windows 7 bug in Server 2008 R2 -- this is not surprising, since it is an architectural setup issue and it's hard to expect different results when two products share the same setup architecture;
  2. Some folks were able to glean the advice from the various references out there, to uninstall unused language packs;
  3. They hit a brick wall trying to discern which language packs were actually not in use.

In the end, there really isn't a good way to do this.

You can look at every user hive on the machine and pick up the most recently used UI language when the hive info is available.

Also, under HKCU\Control Panel\Desktop\MuiCached,MachinePreferredUILanguages there is some promising info. Though without info on what it means it may not be the "list of UI languages" this user has logged in with that its name perhaps suggests.

Semi-cryptic registry info being what it usually tends to be and all....

I suppose that's basically the answer for the foreseeable future. That, or do what I did (the advice in the title). Probably easier to manage in the long run.


Joel C on 6 Sep 2011 12:12 PM:

Well, going through the link you linked from that other page, apparently there is now a kernel update that fixes the problem for "good": support.microsoft.com/.../2534366 . (It was supposedly caused by 16-bit-era Registry handle limits in the kernel.) But you still have to use system restore to uninstall SP1.

So I guess there is a third, and much better, answer here...

Simon Buchan on 6 Sep 2011 4:19 PM:

Wow - I'm not at all surprised that someone thought "There's no way someone will open 64k subkeys with the same name, that's crazy!". I would very easily write this bug :(. I do wonder how that many handles are open at once, though - are they something like "Value" or "Translation"?

Rich Prescott on 6 Sep 2011 7:15 PM:

Here is a Powershell script that can pull the information he requested.  Copy/paste it into notepad and save it as a .ps1 file.

$users = get-childitem 'c:\users' | ?{$_.psiscontainer -AND $_.Name -ne $Env:Username -AND $_.Name -ne 'Public'}

$users | %{

$userDAT = Join-Path $_.fullname "ntuser.dat"

reg load HKLM\TempHive $userDAT  | Out-Null

Start-Sleep -Seconds 1

$info = ((reg query 'HKEY_CURRENT_USER\Control Panel\Desktop\MuiCached' /v MachinePreferredUILanguages) -split '\s+\b')[-2]

New-Object PSObject -Property @{

   User = $_.Name

   MUI = $Info

   }

Start-Sleep -Seconds 1

Reg unload HKLM\TempHive | Out-Null

$info = ""

}

Michael S. Kaplan on 7 Sep 2011 8:19 AM:

Joel, I'm not 100% convinced that everything is fixed here, but it is a step in the right direction....


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