Monthly Archives: April 2013

Trouble Installing SharePoint Language Packs

Call me unlucky, but every time I’ve had to install Language Packs, There has been some kind of failure or another….

The first failure was my own fault, I’ll share it here, because it may save you some embarrassment.

When you go to download the langage packs, be sure to notice the drop down for “Language” it defaults to your PC’s default Language (In my case English).

The download for language packs looks like the same Microsoft download screen you see for anything else. I think mentally, my mind just completely ignores the “English x64” dropdown, since it seems so familiar. So, yeah step one of downloading a langauge pack, is to pick the language you want to install.. Also be sure to put the downloaded file into a folder named after the language – the dang install file will be called “ServerLanguagePack.exe” no matter what language you pick… Confusing…

On now onto the “real” errors:

One failure I’ve seen more than once, cropped up when installing langage packs on a 5 node farm.

I installed the Language packs, and the service packs, and after each step, I say no to the SharePoint setup wizard offer, saving that for the very end.

Now it was time to run the SharePoint Product Configuration Wizard on each machine.

I started with the server hosting Central admin…

And got a nice error – it said one of the language packs was not installed on two of the 5 nodes.

Short answer: Start the SPtimer Service.

This was relatively easy to figure out – Much of SharePoint server to server communication doesn’t actually happen server to server, instead, timer jobs are created in the database, and timer service on each node will pick them up and run them. This is true for WSP deployments and
I figured it was probably the case here – I KNEW I had just installed the binaries on ALL nodes so there was no question there – So, the first thing I checked was the SPTimerV4 (Windows) service on the machines in question and sure enough, it wasn’t running – I started them, along with the SPAdminV4 service and gave it a few minutes, and sure enough the installer on the first node, recognized the other nodes now…

Another error I had on one farm occurred around step 9 or 10 of the setup wizard. The wizard failed as a result and the logs were not super obvious as to the cause…

This one was tricker to diagnose… I ended up with a Support call to MS.
They asked me to run SETH – that diagnostic tool they have for collecting your farm’s logs and configuration. I usually cringe when they ask this, most of the great support reps’ I’ve spoken to never ask for SETH and instead dive right in.

I’m happy to report, this was an exception and I appreciate SETH a little more now.

The support rep emailed back something very specific…
“Grant Full Control to WSS_ADMIN_WPG to your logs directory”
SharePoint is already using that directory just fine I thought to myself…
Next I looked at the permissoins: WSS_ADMIN_WPG already had read and write perms on the log directory!

I was convinced it wouldn’t work, but hey, nothing to loose by trying it.

It worked.

Oddly, the permissons on WSS_ADMIN_WPG after it worked?
Yep, Right back where we started, Read and write (no full control)

Not sure why this is, but I do know we moved logs to the D drive at one point – so maybe there is just a tiny glitch somewhere that comes across when the logs are not in the default location.

I was glad that was solved!

– Jack

PS, as a follow up, to use the new language, you must create a new site collection.
In powershell, you would use something like this:

new-spsite -language 3082 #3082=Spanish

There is a full list of Language ID’s at

Some of the languages have several variants, It’s a good idea to check C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE and look for a folder with the number you think you are trying to use, just to confirm you actually have that Language Pack installed. (If you recently installed it, the language folder should have the date of the install, which might help)
In my case I installed “Simple Chinese” which turned out to be 2052 And “Spanish” which turned out to be 3082.

A nice article on configuring the people picker

Nitzan Raz has a great article on some lesser known people picker settings over at

There are two people picker tweaks I am aware of – one of which is set on the site collection object (with set-spsite -UserAccountDirectoryPath, which seems to limit the people picker to a single OU in AD, but only for the given site collection)

The other tweaks are discussed in Nitzan’s article, and involve the web application level (for those who can’t keep the terminology straight, this is the highest level, I often think of this as the IIS site.

Grabbing the SP Site object with get-SPWebApplication lets us look at the PeoplePickerSettings

$wa= get-spwebapplication

Update July 11 2013:
I had an issue today where users in a trusted domain weren’t showing up in the people picker in a stage environment, but they worked fine in production.
The difference was $webapplication.PeoplePickersettings.ActiveDirectoryCustomFilter which was empty in the working environment, but had a value in the non-working environment.

The fix was like this:

# remove the filter
$wa = get-SPWebApplication
$backup = $wa.PeoplePickersettings.ActiveDirectoryCustomFilter
$wa.PeoplePickersettings.ActiveDirectoryCustomFilter = $null
$backup | out-file originalpeoplepickercustomfiltervalue.txt