“I am known by many names, Mr Quatermain” – Nickname Search

When SharePoint 2010 first released, there was a lot of excitement about the ability to perform Phonetic and Nickname searches.

One of the most common English names in the UK is Michael, which obviously has many variants and nicknames associated with it. Luckily with People search in SharePoint, searching by variant isn’t an issue… or is it?

In my demo site, I have a full compliment of employees in my Active Directory. There’s Mike Reid in the Production department, Michael Fish and his boss Michael Fox in Marketing.

Because there’s two Michaels in marketing, everyone calls the boss Mike, and the junior Michael, although the janitors like to call Michael Mickey, just to wind him up.

Then in IT we have Bernice who reports into the IT Director and Bernard in marketing, both affectionately known as Bernie.

Straight away you can see the benefit that either phonetic (Jon, Juan) or nickname searching could be to a large organisation. So lets take a look at our demo site and see what’s happening.

In our People search page, let’s pop the name Mike into the search box.


As you can see, we only get a single response, with a direct match of Mike. That’s not exactly what we wanted, so let’s try Michael.


In this case, we get our Michaels, but not Mike this time.. Why?

The answer lies in the fact that we’re not American. When Microsoft built the Search service applications, they preloaded the Language resources with only a select number of languages and EN-GB wasn’t one of them! If you were to switch your browser locale to match en-US with an LCID of 1033, this would work perfectly, straight out of the box!

To see exactly what has been installed, you can take a look in the Microsoft Office Servers install location (Note: not the 14 root!,) typically this is C:\Program Files\Microsoft Office Servers\14.0\Bin and find a file called languageresources.txt

I’ll warn you now, if you open it in notepad it takes a while as this file is HUGE! If you do open it, you’ll see a nicely structured file with various languages detailed within it. The ones that we’re interested in are the ones with the Language ID of en-US and an LCID of 1033.

When the Search service application is first provisioned, this file is used to build the MSSLanguageResources table of the Search Service application database. If you take a look in SQL (On a dev farm of course!), you’ll see this table is pretty much an exact match of this file.

The other way to view these resource entries is to drop into powershell and enter get-spenterprisesearchlanguageresourcephrase -searchapplication <GUID OF YOUR SEARCH APP> -language en-us

This list will go on for a while!

So luckily, we don’t need to hack SQL, or change the resource files to add new ones, powershell also gives us a nice quick way to populate this table with additional entries, and that’s with the just as niftily named new-spenterprisesearchlanguageresourcephrase and it’s sister command remove-spenterprisesearchlanguageresourcephrase.

But, there’s 14391 entries in this text file! You really don’t want to type those out by hand! (Although you should perhaps question do you need to? Is there value in just doing common ones for the staff in your company? In my opinion, that depends on the size of your company!)

So, if we want to automate this process slightly, the first thing we need to do is get the US entries out into a file that we can amend. To do this, use the command that follows:

Get-spenterprisesearchlanguageresourcephrase -searchapplication <GUIDOFYOURSEARCHAPP> -language en-us | select phrase,mapping,language > resourceentries.txt

This dumps the en-us entries only into a new text file that we can pull into Excel to create a new CSV file.


Quick find and replace on en-US to en-GB (14391 replaced!) , and remove the spacer line that PowerShell inserted.


And then save that out as a CSV file and pop it back onto the SharePoint server.

Use the following powershell script to add all of these into the database.

$resourceentries = Import-Csv shorttest.csv
$searchSvc = Get-SPEnterpriseSearchServiceApplication "Temp Search Service App" #Put the name of your Search service app here.. "get-spserviceapplication | select name" to find it.

foreach ($resourceEntry in $resourceentries)
    New-SPEnterpriseSearchLanguageResourcePhrase -SearchApplication $searchSvc -Language $resourceEntry.Culture -Name $resourceEntry.Phrase -Mapping $resourceEntry.Mapping -Type "Nickname" -ErrorVariable outputErrorVariable -ErrorAction SilentlyContinue
    #error handling isn't working properly
        if ($outputErrorVariable[0].exception.number -eq 2601)
            Write-Host $resourceEntry.Phrase "/" $resourceEntry.Mapping "already exists as a mapping."

        Write-Host "Added" $resourceEntry.phrase


Adjust that powershell to suit your CSV filename etc and then run it. On my demonstration VM (Dual CPU i7 with 8Gb memory) it took around thirty minutes to complete. I’m putting that down to the speed of the powershell loop as the CPU’s didn’t really get above 30%.

Once the script completes, stop and restart the SharePoint Server search service.

Now if we go back and search for Mike, you should find that we get all of our expected results!


I’ve also updated some information for this issue on SharePoint 2013.

Leave a Reply

Your email address will not be published.


This site uses Akismet to reduce spam. Learn how your comment data is processed.