Tag: Search Service Application

New-SPEnterpriseSearchIndexComponent could not find part of the path error

When attempting to reorganize your SharePoint 2013 topology you may also want to specify a new path for your search Index. The reason for this might be that you want to have a dedicated drive for a large or busy search index. You can find the general technique for modifying the topology here: http://mmman.itgroove.net/2013/03/changing-the-sharepoint-2013-search-topology/

Looking up the involved New-SPEnterpriseSearchIndexComponent at http://technet.microsoft.com/en-us/library/ff607766(v=office.14).aspx we can see the new file path is designated by the -IndexLocation switch. An example would be:

$NewIndexPath = "E:SharePointIndex"
New-SPEnterpriseSearchIndexComponent -SearchTopology $newTopology -SearchServiceInstance $serv -RootDirectory $NewIndexPath

But wait- if the destination path does not exist on the source server, it will error out with “Could not find part of the path”. At first I thought it was permissions, but having checked that the new destination folder had appropriate permissions (WSS_WPG with modify permissions), I was still scratching my head. It became clear this was a bug, as described on http://office.microsoft.com/en-ca/help/sharepoint-server-2013-known-issues-HA102919021.aspx :

“New-SPEnterpriseSearchIndexComponent checks the existence of RootDirectory in the wrong server

You want to add a new index component to the search topology, and want to specify a non-default root directory for the index files. For example:

**Keith Note: Do not use this PowerShell, it has typos quoted as-is from TechNet. Provided for reference only:

New-SPEnterpriseSearchIndexComponent -SearchTopology $t -SearchServiceInstance $ssi -IndexPartition 1 -RootDirectory ""d:index4"

The cmdlet might fail with the following error message because it incorrectly checks if the indicated root directory exists on the server the cmdlet is run on:

Cannot bind parameter ‘RootDirectory’ to the target. Exception setting “”RootDirectory””: “”Could not find a part of the path ‘d:index4’.”

Workaround You can create the new index component using the following procedure instead:”

$host02 = (Get-SPServer "<Name of server>").Name
$ssa = Get-SPEnterpriseSearchserviceApplication
$t = $ssa.ActiveTopology.Clone()
$ic = (New-Object Microsoft.Office.Server.Search.Administration.Topology.IndexComponent $host02,1);
$ic.RootDirectory ="d:index4"

Note: In the code snippet on the MS bug report, there are three typos (fixed in the PowerShell shown above)

1. missing space between SP-GetServerName and parameter
$host02 = (Get-SPServer””).Name
should be
$host02 = (Get-SPServer “”).Name

2. double quotes in beginning of the path declaration:
$ic.RootDirectory =””d:index4″
should be:
$ic.RootDirectory =”d:index4″

3. extra quote at the end:
should be:

Note 2: You must permit TCP port 808 through your Windows Firewall on the source and destination servers or the topology move in general won’t work!

Synonyms not working in SharePoint Search

The custom thesaurus functionality of SharePoint search should be old hat to those of us experienced with MS Full Text Search, which is a mature technology that’s been around for years. What may trip you up in trying to get custom synonyms working with SharePoint’s implementation is the nuances of the file paths and deployment across multiple physical servers in a farm.

A basic example of the thesaurus format is as follows. This one would match instances of “it” to “information technology”

<XML ID="Microsoft Search Thesaurus">
    <thesaurus xmlns="x-schema:tsSchema.xml">
            <sub>information technology</sub>

First, does your thesaurus file validate as proper XML? Sometimes a forgotten –> closing tag etc. can be a showstopper.

Thesaurus files are stored in several locations on a SharePoint Server:

  Program Files  Microsoft Office Servers  14.0  Data  Config  

Updates to the thesaurus files here will ensure that any new Search Service Applications that you create will have the updated thesaurus definitions when they spin up.

  Program Files  Microsoft Office Servers  14.0  Data  Applications  Config  

GUID is the guid of your Search Service Application, which you can get by using Get-SPServiceApplication. That powershell command will list your service applications and their corresponding GUID’s.

When you’ve verified your updated tsneu.xml files are in those locations, you’ll need to restart the search service with these commands:

net stop osearch
net start osearch

Once the service is restarted, go to your search center and plug in one of the newly added expansion/replacement terms to see your results.

If you’re running search on multiple servers, you will need to perform these steps on each server running search. If there are multiple search applications running, you have to copy your thesaurus files to each config directory under the GUID folder for each search service application.

You can run into the following situation when trying to get a custom thesaurus to kick in for the SharePoint search service:

1. You set up the thesaurus file(s), in our example we’ll use the basic tsneu.xml, which is the language-neutral default thesauraus.
2. You try putting the thesaurus XML file into

%ProgramFiles%  Microsoft Office Servers  14.0  Data  Applications  Config 

and in

%ProgramFiles%  Microsoft Office Servers  14.0  Data  office servers  applications  data  

but with no luck – you don’t see the search results.
3. You try creating a folder on each query/crawl server with the GUID of the search application.
4. Restart the services.

Still no synonyms? It may be that you have partitioned the index, in which case the path changes, and it´s not the default one but the one you set up into the Central Administration > Manage search topology.

Chang the files there, restart the search service and voila!