Robert Piddocke mentions a popular managed property, “Content Type.” He notes that users who intent to use this managed property as a method of adding information to the search index will be disappointed. In fact this managed property is locked, and not configurable by the user. He demonstrates in this webinar how users can and should actually create a custom managed property to produce information about types of content that can be crawled, and, subsequently, added to the search index.
Of course a very important aspect of creating a custom managed property for the purpose of exposing information about types of content to the search crawler is to map the correct crawled properties to the new custom managed property. In the case of Josh’s example, he demonstrates in our webinar how to select the crawled properties specific to content for OWS, which are only specific to SharePoint, rather than any other option. Be sure to check the box that instructs the search engine to expose the mapped crawled properties in query results, or else the exercise will not produce the intended outcome.
Robert notes that “any property mappings that you do, or any refinement type additions that you do, require that you do a full crawl before they are available”. In fact, as he goes onto note, “if you add a custom property you will have to do 2 full crawls, one to go and pick up the new properties and the second one to get that property in the index.”
In response to a question from Asif Rehmani on the topic of why information in SharePoint cannot be searched by, for example, “create date,” Joshua Noble notes that, by default, a number of the default properties in SharePoint can not be exposed to search via mapping crawl properties to managed properties. The “create date” is specifically one of these properties. Therefore, users should plan on creating custom managed properties for columns like “create date”, which can then be mapped to targeted crawl properties. Joshua Noble notes that the video set on search includes a comprehensive list of these managed properties that cannot be mapped to crawl properties.
It is useful to keep in mind that any work on mapping managed and crawled properties has to be done at the level of central administration for a farm. Robert notes that all of this work is “done in the search service application.” On the other hand, SharePoint Administrators can certainly choose where they want to expose mapped properties, in other words, on a department by department basis. Robert notes that, for example, a search center with a special set of refiners can certainly be built at the department level. Certainly, different search applications at the farm level can be set up to support different search centers, but the applications, themselves, must be managed at the farm level.
This concludes Robert Piddocke’s presentation of selected observations on the back end of the SharePoint 2010 Search service. IN the next post of this blog we will start to comment on Joshua Noble’s presentation on the front end of the same application.
© Rehmani Consulting, Inc. & Ira Michael Blonder, 2013 All Rights Reserved