As you might have noticed from the title of this section, we are not heavily focused on the technicalities of search at this point; instead, we will lightly cover search architecture, choosing to focus on how search queries and results are “shaped” via the use of keywords, promoted results, and managed properties.
Core search components
Search can be broken down into six major components: Search Administration, Crawl, Content Processing, Analytics Processing, Indexing, and Query Processing.
The relationship between these components can be seen in Figure 1-6.
FIGURE 1-6 Search component relationships.
As you can see, the six components together accomplish two major tasks: crawls and queries. At one end of the process, content sources (such as file shares and SharePoint content) are crawled by the Crawl component; on the other end, the information has been broken down by search and is available for querying by users.
MORE INFO SEARCH IN SHAREPOINT SERVER 2013
For a detailed description of each search component and database, visit the TechNet article “Overview of Search in SharePoint Server 2013” at http://technet.microsoft.com/en-us/ library/jj219738.aspx.
The Search Administration component simply provides for the administration of the search components, also providing for the creation and initialization of new search components. Unlike the rest of the components, Search Administration does not provide any information transfer to or from any of the other components.
The Crawl component simply performs a crawl of the content available in the content sources; this is usually accomplished via the use of an indexing connector or protocol handler and depends on the type of file being crawled (Word, Excel, Acrobat, and so on).
After the content has been crawled, it is passed on from the Crawl component to the Content Processing component. Several operations are carried out within this step, one of which is the mapping of crawled properties to managed properties (which is discussed shortly). Additionally, items that have been crawled are turned into artifacts in this stage for inclusion within the search index. Link and URL information is stored in the link database and then processed and forwarded to the Analytics Processing component.
There are two major types of analysis present in the Analytics Processing component: search analytics and usage analytics.
■■ Search analytics focuses on the analysis of content being crawled and added to the search index. Items that are analyzed within search analytics improve search relevance and recall; these include metrics such as click distance, social tags and distance, and so on.
■■ Usage analytics focuses on user actions within search, providing a statistical analysis of usage counts (such as viewed or clicked items), recommendations (based on the user’s interactions within the site), and activity ranking (the tracking of usage events) to influence search relevancy.
After analytics processing is complete, search relevance for items such as links and URLs are returned back to the Content Processing component.
After content is received from the Content Processing component, the Index component writes this content to the search index. This component also receives requests for information contained in the search index and returns result sets to the Query Processing component.
The Query Processing component receives and analyzes incoming search queries, which improve the precision, recall, and relevance of the search result sets. The resulting queries are sent to the Index component, which returns a set of search results (that are also processed) for a particular query to the front-end server.
Search is a critical component of any SharePoint 2013 farm. a thorough understanding of each search component’s role within the farm helps determine which component(s) are assigned to a particular server.
Making search meaningful
Now that you have a basic understanding of the SharePoint 2013 search mechanisms, you see how everyday business users can improve search results for their particular section of a
SharePoint installation.
From a design perspective, it’s fairly straightforward to build a basic search engine—such a system can crawl, parse, and index content; it can also perform basic search ranking by the frequency with which a word or phrase occurs.
As content in this basic search engine grows, however, it becomes more and more difficult to find specific content within the growing search index. A high-value search result might be hard to locate when it is surrounded (and perhaps outranked) by other documents with similar search terms; for instance, a document displaying this year’s 401K plan should appear first in search but might instead be displayed after documents detailing previous years’ 401K
plans.
Fortunately, business users who generate SharePoint lists and documents can influence search results for the content they generate.
Keywords
Within a SharePoint 2013 site, descriptive metadata (words or phrases) can be directly assigned to any list item or document; these words and phrases are called keywords. These keywords are generated as a folksonomy, meaning that they are created by individual users on a site.
Although terms are stored within a series of term sets, enterprise keywords are stored within a single term set within the managed metadata service. This specialized term set is nonhierarchical and simply called the “keyword set.” As with the managed terms, enterprise keywords are stored in the term store database.
Adding keywords to a list item or document is fairly straightforward, but requires a bit of configuration prior to use.
The basic configuration process requires two steps:
- The MMS Connection must be configured to be the default storage location for keywords.
- The enterprise keywords site column can then be added to content types.
IMPORTANT MISSING DEFAULT TERM STORE
When you are adding new keywords, you might see this message: The Site Does Not Contain A Default Keywords Term Store. This occurs when you have not yet selected the default storage location for keywords within your SharePoint environment.
To configure the default storage location, follow these steps:
- Open Central Administration and select Application Management.
- Under Service Applications, select Manage Service Applications.
- Select the MMS Connection.
- From the ribbon, choose the Properties
- On the Edit Managed Metadata Service Connection page, select the check box for This Service Application Is The Default Storage Location For Keywords (see Figure
1-7).
Next, the enterprise keywords column must be added to a list or document library; this column allows for multiple values. After this column has been added, new keywords can be added to the list item (see Figure 1-8).
After keywords are added to a list item or document, they are automatically added to the Managed Metadata term store (see Figure 1-9).
FIGURE 1-9 Taxonomy term store.
All keywords are stored in the keyword set that is contained within the System group; none of the specialized term sets within the System group enables you to build any sort of hierarchy.
Keywords that are regularly used by business users in the organization can be reviewed and moved into term sets; doing so enables the keyword to become centrally managed as a term and moved into appropriate term sets.
To transform a keyword into a term, simply right-click it and select Move Keyword (see Figure 1-10).
A series of destinations appear; at this point, you can select a term set (see Figure 1-11). At this point, you can also decide whether this word can continue to be used as a distinct keyword outside of the new term set.
FIGURE 1-11 Choosing a destination term store.
Note that this conversion is one-way; after the keyword is changed into a term, it cannot be converted back to a keyword.
Promoted results
In previous versions of SharePoint, there was a concept known as a best bet, which was simply a search result that was promoted within the search results to be a preferred search result for a particular search topic. For instance, when a user would type in a search query that included a keyword such as “HR” or “Human Resources,” the search results could be configured to display a best bet at the top of the search results that would promote the URL of the Human Resources web site.
In SharePoint 2013, best bets have been replaced by promoted results. Although the two act in a very similar fashion, there is one distinct difference between the two—how they are triggered.
Best bets used a combination of keywords and synonyms to trigger the display of a preferred result for a search. If multiple keywords were to be specified (but they were not synonyms of one another), multiple keyword entries were required. Additionally, a best bet could itself be triggered to have start, end, and review.
Promoted results improves on this concept specifically based on how they are triggered. Instead of using keywords as triggers, promoted results are triggered by query rules. These rules can be configured for use at one of two levels:
■■ At the site collection level:
■■ Specified within Site Collection Administration → Site Query Rules
■■ Scoped to the entire site collection ■■ At the site level:
■■ Specified within Search → Query Rules
■■ Scoped to the particular site
After the new query rule has been added, the process of adding a new promoted result in SharePoint 2013 is almost identical to that of creating a new best bet in SharePoint 2010.
Adding a promoted result is shown in Figure 1-12.
As with best bets, a promoted result can display a message and a link to a location or item.
A new field has been added to the promoted result: Render The URL As A Banner Instead Of As A Hyperlink. It provides for the display of a banner about a topic instead of a normal text URL.
Building a new query rule to contain the promoted result requires three actions:
- Selecting an appropriate search context
- Specifying the query condition(s); choices include the following:
- Query Matches Keyword Exactly
- Query Contains Action Term
- Query Matches Dictionary Exactly
- Query Mode Common in Source
- Result Type Commonly Clicked
- Advanced Query Text Match
- Specifying the resulting action(s):
- Add a Promoted Result Above Search Results
- Add a Result Block Displaying A Specific Portion Of Search Results
- Change The Ranked Results By Changing The Query
IMPORTANT ALTERING EXISTING QUERY RULES
Simply stated, SharePoint 2013 does not enable you to alter any of the built-in query rules. If you want to build a query based on an existing rule, you must first copy it and then alter the copy; the original’s edit menu is always grayed out.
CREaTING a SaMPLE PROMOTED RESULT
Let’s go through the process of creating a simple promoted result. The requirements for this example are as follows:
■■ The Human Resources site (http://hr.boston.local) has to be displayed within search as a promoted result when users specify one of the following search phrases:
■■ 401K
■■ Benefits
■■ Vacation
■■ Hiring
■■ Termination
■■ Recruiting
■■ Leave
■■ To keep this simple, the accompanying query rule will require an exact match between the query and the keyword.
■■ You will not show the promoted result as a banner, merely displaying it instead as a URL for the users to click.
■■ The query will be scoped to your particular site, not the entire site collection.
First, you must build the query itself. To begin, do the following:
- In the upper-right corner of the screen, select Settings (gear icon).
- Scroll down and select Site Settings.
- On the Site Settings page, scroll to the Search section and select Query Rules.
If you want to instead build a query that affects the entire site collection, from Site Collection Administration, select Search Query Rules.
- On the Manage Query Rules page, select the Local SharePoint results (System) context (note that there are several other contexts in an OOB configuration).
- A series of queries appear beneath the query rule section; unless you have already built some queries, these rules are built in and cannot be edited.
- Select the New Query Rule selection beneath the context selection.
- On the Add Query Rule page, make the following selections:
- In the General Information section, choose the following:
■■ Rule Name: HR Promotion
- In the Query Conditions section, choose the following:
■■ Query Conditions: Query Matches Keyword Exactly
■■ Query Exactly Matches One Of These Phrases (Semi-Colon Separated): 401K; Benefits; Vacation; Hiring; Termination; Recruiting; Leave
Now that the context and query conditions have been set, it’s time to build the promoted result, as follows:
- In the Actions section, select Add Promoted Result.
- Note that although Add New Promoted Result is selected, you can also choose to select an existing promoted result and make changes.
- Add the following items:
- Title: Human Resources
- URL: http://hr.boston.local
- Render The URL As A Banner: Leave unselected
- Description: The HR Team Is Available To Assist With All Your Human Resources Requirements
- Click Save.
- Click the Publishing menu item (below the Actions section). In this section, you can do the following:
- Choose to activate/deactivate the rule (note that you are not activating/deactivating the promoted result)
- Set the following fields:
■■ Start Date
■■ End Date
■■ Review Date
■■ Contact for this Query Rule
After you click Save to complete the creation of the query rule, you should see the completed query rule on the Manage Query Rules page (see Figure 1-13).
At this point, you can return to the main page for your site and verify that your promoted results are working as expected. Type any of the following search terms and click the search icon (see Figure 1-14):
■■ 401K
■■ Benefits
■■ Vacation
■■ Hiring
■■ Termination
■■ Recruiting
■■ Leave
FIGURE 1-14 Successfully promoted result in search.
Managed properties
Items within a list or library have metadata that is stored in columns such as author, title, and subject. The metadata captured from populated columns (columns that have metadata assigned) is stored as crawled properties. This metadata is captured from both built-in columns and columns that are added by users.
To make these properties useful within search, they need to be converted to managed properties. Managed properties enable a user to search for list items or documents based on the columns that have been used in the list or library.
MORE INFO WORKING WITH MANAGED PROPERTIES IN SHAREPOINT SERVER 2013
For more information about adding, editing, and deleting managed properties, see the TechNet article “Manage the Search Schema in SharePoint Server 2013” at http://technet. microsoft.com/en-us/library/jj219667.aspx.
So, for instance, if you want to perform an advanced search based on documents in which the author of the item is Bob Ford, and the title contains the word “Equipment,” the crawled properties for each of these columns must first be mapped to a corresponding managed property.
In SharePoint 2010, the mapping between crawled properties and managed properties had to be created manually in the search service application. After the mapping was created, a full search had to complete before the managed properties could be used in a custom search results page (rendered via XSLT). For some environments, this might cause issues because a full crawl of the search corpus could take several days.
Thankfully, the creation of a managed property is quite a bit more streamlined within SharePoint 2013. The ability to create a managed property within Central Administration still exists, but it is also possible (and very likely, as you will see in a moment) to build a managed property at the site collection level. When a crawled property is created by search crawls of the list or library, a corresponding default mapping to a managed property is created at the site collection level.
Creating a managed property at the site collection level is pretty straightforward:
- Create a site column.
- Add the site column to the list or library.
- Add value(s) to an item using the new column (Phase, in this example), as shown in Figure 1-15.
- After a search crawl occurs:
- A crawled property is created from the site column.
- A managed property is created and mapped to the crawled property.
- To review the newly created properties:
- From Site Settings, Site Collection Administration, select Search Schema.
- On the page that follows, you can choose to see the crawled properties (see Figure 1-16).
FIGURE 1-16 Crawled properties (site collection level).
In the previous screen shot, you see both the crawled properties (ows_Phase and ows_q_CHCS_Phase) and the managed property (PhaseOWSCHCS). If you choose to see just the managed properties (by selecting its link and then entering the name of the managed property) you see only the managed property itself, along with the attributes for the property. The example property and its attributes are shown in Figure 1-17.
FIGURE 1-17 Managed properties (site collection level).
If you decide to create a new managed property at the site collection level, there are a few restrictions:
■■ They can be of the type Text or Yes/No (Boolean).
■■ They cannot be refinable, which means that they cannot be used as a refiner for search results.
■■ They cannot be sortable, which means that they cannot be used for sorting the result set.
If you want to change the refinable or sortable attributes of an automatically created managed property, you can do so after it is created. This change can be made within the search service application settings.
Unlike managed properties created at the site collection level, there are no limitations on managed properties created from within the search service application; otherwise, there are no differences between automatically generated managed properties and ones that are manually generated from the search service application.
To create a managed property from Central Administration, follow these steps:
- Open Central Administration and navigate to the Service Applications screen (from Application Management, select Manage Service Applications).
- Select the name of the Search Service Application and then select the Manage menu item from the ribbon.
- Under the Queries and Results navigation menu, select Search Schema.
At this point, configuration is identical to the menus found in the site collection administration. None of the attributes limitations exists for managed properties created in the search
service application.
Understand the limits placed on managed properties created at the site collection level (text/Boolean, neither sortable nor refinable) versus those created at the service application level.
