SharePoint 2013 Searching for a URL
My colleague Igor Veytskin and I have run into a few issues when trying to search for a document in SharePoint 2013 based on its URL. If you take a look at the Managed Properties returned in search results, you'll see where the URL is stored. It is stored in the 'Path' managed property. The Search Query Tool is very useful see the values of managed properties that may not be displayed or returned for your results page. Here is a search for 'team' that shows the Path managed property.
If you search on an exact url within Path, then you will find the document with that URL
The problems arise when you would like to search for just a part of the URL within 'Path' or search for part of the URL in the full text index. This does not work in the out of the box setup.
This is because Path is set as "Complete Matching"
The reasoning for this configuration is mentioned here: Changes from SharePoint 2010 to SharePoint 2013
URL Query syntax
Description: In FAST Search Server 2010 for SharePoint, the URL-related managed properties (such as site, or path) are tokenized as a text string, and you can query any subpart of the URL. This includes In SharePoint 2013, the entire URL is tokenized as one word. This includes special characters such as “
Reason for change: The implementation in SharePoint 2013 is aligned with SharePoint Server 2010 search. The FAST Search Server 2010 for SharePoint implementation has a very high query performance cost, especially when you search for the full URL or a leading subset of the URL. Migration path: The following table provides details on how to change FAST Search Server 2010 for SharePoint query expressions to match the SharePoint 2013 URL query syntax.
|
Many customers are willing to trade off some additional space in the index and tokenization processing to be able to search on parts of the URL. This is how you set it up. First off, it is a good policy never to change the default managed properties if you can avoid it. So, we'll create a new Managed Property called 'newpath'. You can create the property as normal using the GUI, but we'll need to handle mapping crawled properties in PowerShell. We want to use the exact same crawled property mapping that Path uses. First create the new managed property.
We will leave Complete Matching unchecked
We will also add Searchable, so we can search against the full text index.
Leave the crawled property mapping empty.
Next is the crawled property mapping. Start by getting the Path managed property and displaying the mapping.
$ssa=Get-SPEnterpriseSearchServiceApplication $pathmp= Get-SPEnterpriseSearchMetadataManagedProperty -SearchApplication $ssa -Identity "Path" $pathmp.GetMappedCrawledProperties(10) |
Now create the same mapping for newpath. We use PowerShell since that allows us to easily select the exact same propset and name that Path is mapped to.
$newpathmp= Get-SPEnterpriseSearchMetadataManagedProperty -SearchApplication $ssa -Identity "newpath" $pathmp.GetMappedCrawledProperties(10) | ForEach-Object { $cp = Get-SPEnterpriseSearchMetadataCrawledProperty -SearchApplication $ssa -Name $_.Name -Propset $_.propset New-SPEnterpriseSearchMetadataMapping -SearchApplication $ssa -ManagedProperty $newpathmp -CrawledProperty $cp} $newpathmp.Update() |
Now you'll see the mapping in the GUI
After a full crawl of your content source. Testing searching on the newpath managed property:
Testing against the default full text index with a subset of the URL. This will not work out of the box
Searching for the same subset of the url against path. This is what you'll get with an out of the box full text search.
Comments
- Anonymous
October 14, 2017
Nice :)