Nickname search in SharePoint 2013

NOTE: This info applies to the SharePoint Standard 2013 BETA and as such is subject to change between now and RTM! Do not rely on this information as being gospel until confirmed at release!

After posting my Nickname post this morning, I wondered what was happening with this in SharePoint 2013. As I just so happen to have a virtual machine with SharePoint Standard 2013 running on it, I thought I’d take a look at the SPEnterpriseSearchLanguageResourcePhrase applet and see what if anything has changed.

Straight away it failed on me, which prompted me to take a look at http://technet.microsoft.com/en-us/library/ff608109(v=office.15).aspx which talks about a required parameter of Search Owner that defines the scope of the object created.

Indeed, if we take a look inside SQL, you’ll see that TenantId, SiteId, WebId and SourceId columns have been added which suggests the targeting of the entries in this table has been made a lot more definable. I can certainly understand this for tenanted service applications, but I’ll be interested to see how and if this gets used in Enterprise organisations. (most of the organisations I visit don’t even realise that People search isn’t doing what it should out of the box!)

So, going back to my original post on this subject, what I’ve written still stands and it looks like we’ll need to do the same in any new SP2013 environments that we install for an EN-GB workforce. The LanguageResources.txt file still exists and still only includes entries for EN-US (1033) and a selection of other countries LCIDs (4,1031,1033,1041,1043,3082)

In order to change the powershell script slightly, we’ll need to grab a Search Object owner using the following cmdlet

$owner = get-spenterprisesearchowner -level ssa

This $owner object is then used in the GET-SPEnterpriseSearchLanguageResourcePhrase and the NEW-SPEnterpriseSearchLanguageResourcePhrase parts of the script.

The other available levels are SPWeb, SPSite and SPSiteSubscription but I haven’t been able to find out what if anything they do as yet.

I will be digging deeper and posting more here as I make sense of it!

##### Correction – 12 Oct 2012 #####

It wasn’t until I started playing further with the language resource files that i realised a change in my script was needed to extract the current resource entries. The Language column is now called the Culture column which more accurately reflects the information held in it. I’ve amended the script to also only extract the en-us entries that correspond to Nicknames.

Therefore to extract the items from SharePoint you should use:-

   1: get-spenterprisesearchlanguageresourcephrase –searchapplication <GUID of your search application> -owner $owner | ? {$_.culture -eq "en-US" -and $_.type -eq "Nickname" } | select phrase,type,mapping,culture 

And the new script to inject the items into SharePoint is:-

   1: $resourceentries = Import-Csv resourceentries.csv ## Replace this with your csv file

   2: $searchSvc = Get-SPEnterpriseSearchServiceApplication "Search Service Application" ## And this with your Service app name

   3: $owner = get-spenterprisesearchowner -level ssa

   4:  

   5: foreach ($resourceEntry in $resourceentries)

   6: {

   7:     $outputErrorVariable = $null

   8:     write-host $resourceEntry.Phrase " - " $resourceEntry.Mapping

   9:     New-SPEnterpriseSearchLanguageResourcePhrase -SearchApplication $searchSvc -owner $owner -Language $resourceEntry.Culture -Name $resourceEntry.Phrase -Mapping $resourceEntry.Mapping -Type Nickname -ErrorVariable outputErrorVariable -ErrorAction SilentlyContinue

  10:  

  11:     if ($outputErrorVariable)

  12:     {

  13:         write-host $outputErrorVariable[0].Exception.Message

  14:     }

  15:  

  16: }