Components

SharePoint 2013 search consists of several components in the overarching search architecture. The search components associate with each Search Service Application (SSA) in the farm, and administrators may scale the components to multiple application servers to distribute load and provide redundancy. The following sections cover each of the search components at a high level.

Topology

Figure 15-3 shows an example search topology within a SharePoint 2013 farm. The topology assumes multiple application servers, web-front-end (WFE) servers, and databases. In this example, the hosts are physical servers and servers within each host exist as virtual machines.

Notice how none of the WFE servers host search components—this is advantageous and recommended in highly scalable and highly redundant scenarios, consisting of multiple SharePoint servers. Typically, you want to ensure that your WFE servers do what they do best, which is to server pages to users.

The application servers in Figure 15-3 are where all the search components reside. In this example, hosts C through F maintain replicated indexes, each index replica is a mirror image of another, and there are four replicas. Partitions consist of splitting the index across two web application servers. The replicas ensure redundancy—should one set of servers (host) fail, then the index resides on three other hosts. Partitioning the index replicas across two virtual servers ensures division of load when crawling and querying the index. In Figure 15-3 two query processing components exist (on hosts C and E) to split the job of responding to user search queries. In this case, hosts D and F provide redundancy for partition pairs. We could add additional query processing components on these hosts also, but providing two query processing components is enough coverage in the event that one physical host server fails.

Hosts G and H contain the remaining search components, including a crawl component on one virtual application server of each host. In this example, we have separated query from the rest of the search components because we should ensure query performs well, such that users see search results quickly. Hosts G and H take on the heavy lifting of crawling, indexing, content processing, and analytics. Since we do not need the search administration components all the time, these can also reside on hosts G and H.

Hosts I and J house the SQL databases and provide typical fault tolerance for data storage with SQL mirroring, clustering, or 2012 Always-On.

The topology represented in Figure 15-3 is only one example of distributing search components across multiple servers and hosts in the infrastructure. Depending on the availability of hardware and need for high availability and redundancy, the topology will change accordingly.

• 11.  Click the OK button the exit the dialog.
• 12.  Scroll down the list of managed service applications until you find the Search Service Application you just created.
• 13.  Click the application name and then press the Manage button on the ribbon to access the new Search Service Application settings.

Splitting Search Service Application Components Across Multiple Servers

Earlier in the chapter, I listed the various components of a Search Service Application and discussed the possibility of scaling these components to different servers. In the “Topology” section, I provided a sample scenario and diagram of the Search Service Application components spread across several hosts and virtual machines. Central Administration does not appear to offer users the capability to distribute Search Service Application components across different servers, so to achieve Search Service Application redundancy and load distribution of these components, use PowerShell.

The UI in Central Administration caters to typical topology situations. The scenario I described earlier in this chapter provides redundancy and load distribution for a large enterprise search solution. On the other hand, what you typically see in the majority of SharePoint deployments are SharePoint farms with dedicated servers for the entirety of a Search Service Application. It is likely for this reason, and to reduce complexity in the UI, that Central Administration provides the simplest creation of a complete Search Service Application.

Of course, you are reading this book so that you may understand how to distribute Search Service Application components for maximum benefit in your SharePoint farm deployments. Therefore, I will demonstrate the various PowerShell commands required to achieve Search Service Application component distribution. I shall assume you are familiar with PowerShell; if not, just flip back to Chapter 3 in this book.

Figure 15-6 shows a screen capture from my SharePoint development farm Search Service Application main administration page. The grid shows the status of the various Search Service Application components and server placement. Unfortunately, my development farm does not have enough capacity to host multiple SharePoint servers, but if it did, they would be listed in the grid. Nonetheless, I shall now cover the steps required to deploy the various Search Service Application components across different servers, using PowerShell. For the purposes of the following steps assume that I have two search servers: SEARCH1 and SEARCH2.

• 1.  Open SharePoint 2013 Management Shell (it is usually a good idea to run this elevated) on the application server in your farm.
• 2.  If you have already created a Search Service Application, skip to step #7.
• 3.  Create a new application pool for the Search Service Application and the administration.

  $SearchServiceApplicationPool = New-SPServiceApplicationPool -name "My Search Service Application App Pool" -account Account-Name
  $adminPool = New-SPServiceApplicationPool -name "My Search Service Application Admin App Pool" -account Account-Name

• 4.  Start the search service instances on each server.

  Start-SPEnterpriseSearchServiceInstance –identity "SERVER1"
  Start-SPEnterpriseSearchServiceInstance –identity "SERVER2"
  $srv1 = Get-SPEnterpriseSearchServiceInstance –identity "SERVER1"
  $srv2 = Get-SPEnterpriseSearchServiceInstance –identity "SERVER2"

• 5.  Create a new Search Service Application.

  $SearchServiceApplication = New-SPEnterpriseSearchServiceApplication
  -Name "My Search Service Application"
  -ApplicationPool $SearchServiceApplicationPool
  -DatabaseServer  "SERVERNAME"
  -DatabaseName  "DATABASE NAME"

• 6.  Create a new Search Service Application proxy.

  New-SPEnterpriseSearchServiceApplicationProxy -Name "My Search Service Application Proxy" -SearchApplication "My Search Service Application"

• 7.  The Search Service Application contains an existing topology, but you want to create your own.

  $origTop = $SearchServiceApplication | Get-SPEnterpriseSearchTopology –Active
  $newTop = $SearchServiceApplication | New-SPEnterpriseSearchTopology

• 8.  Now you get to decide where each component goes. For the purposes of demonstration, I shall put the crawl, content processing, and index components on SERVER1 and the administration, query processing, and analytics on SERVER2.

  New-SPEnterpriseSearchCrawlComponent -SearchTopology $newTop -SearchServiceInstance $srv1
  New-SPEnterpriseSearchContentProcessingComponent -SearchTopology $newTop -SearchServiceInstance $srv1
  New-SPEnterpriseSearchIndexComponent -SearchTopology $newTop -SearchServiceInstance $srv1 –RootDirectory Path-for-Index-Files
   
  New-SPEnterpriseSearchAdminComponent -SearchTopology $newTop -SearchServiceInstance $srv2
  $SearchServiceApplication | Get-SPEnterpriseSearchAdministrationComponent | Set-SPEnterpriseSearchAdministrationComponent -SearchServiceInstance $srv2
  $SearchServiceApplication | Get-SPEnterpriseSearchAdministrationComponent
   
  New-SPEnterpriseSearchQueryProcessingComponent -SearchTopology $newTop -SearchServiceInstance $srv2
  New-SPEnterpriseSearchAnalyticsProcessingComponent -SearchTopology $newTop -SearchServiceInstance $srv2

• 9.  Now replace the existing Search Service Application topology with the new.

  $newTop | Set-SPEnterpriseSearchTopology

• 10.  Finally, clean up the old topology.

  $SearchServiceApplication | Get-SPEnterpriseSearchTopology | Where {$_.State -eq "Inactive" }| Remove-SPEnterpriseSearchTopology -Confirm:$false

• 11.  After completing these steps, open the Search Service Application Administration page on SERVER2, and confirm the components are associated with the correct server.

Content SharePoint Sources

The Crawl Component will crawl over a number of content sources, available out of the box. The following is a list of the available content sources that SharePoint provides:

• SharePoint content
• SharePoint user profiles
• Web pages via HTTP
• File shares
• Exchange
• Lotus Notes

Of the previous content sources, the easiest to comprehend is SharePoint content. This content source is also the most popular; after all, you surely want the capability to search content stored in SharePoint, as well as other sources. The following set of steps demonstrates how to set up a new content source to crawl over SharePoint content. For this demonstration, I shall assume a default site collection on my server http://sp2013.

• 1.  Open Central Administration.
• 2.  Click the General Application Settings header.
• 3.  Click the Farm Search Administration link (under the Search heading).
• 4.  Click the relevant Search Service Application from the list.
• 5.  From herein, I shall generalize the preceding four steps as “Open the Search Service Application Administration page.”
• 6.  Figure 15-7 shows a view of my Search Service Application Administration page.

The administration page, shown in Figure 15-7, contains a number of interesting regions. On the left is the search administration navigation—most of the configuration options live here. The grid in the bottom half of the page is that which I discussed a few sections ago; it shows the status of the search components belonging to this Search Service Application and hosting server. The middle-top region of the page displays the system status of the Search Service Application, which includes the status of the crawler, crawler performance, default service account (more on this later), proxy server for federation, alert/log options, and the URL of the default Search Center.

The steps now resume to configure a content source for SharePoint content.

• 7.  Click the Content Sources link (under Crawling in the left navigation).
• 8.  You should see a page like that in Figure 15-8.

• 9.  Notice that your Search Service Application has a default content source already. The “Local SharePoint sites” is an all-encompassing content source for all site collections in the farm (at least at the time the Search Service Application was created).
• 10.  However the content source name, and then click the Edit option in the pop-up menu.
• 11.  Figure 15-9 shows the page for the content source settings.

• 12.  In this page, the start addresses are most important, because they tell the crawler component which SharePoint site collections to crawl.

   Note  You cannot include the same start address in multiple SharePoint content sources of the same Search Service Application.

• 13.  The SPS3://sp2013 is a special start address that references the people profiles in the farm. This address instructs the crawler component to crawl the user profiles and surface people in a People search.
• 14.  The default content source works fine for most purposes, but for demonstration purposes you will create a new SharePoint content source.
• 15.  Since you cannot crawl the same starting address twice within the same Search Service Application with multiple content sources, remove the main HTTP site collection (http://sp2013 in my case).
• 16.  Scroll to the bottom of the page and click the OK button.
• 17.  You should see the list of content sources again (Figure 15-8).
• 18.  Click the New Content Source link.
• 19.  You should see a page like that in Figure 15-9, but empty of settings.
• 20.  Provide a name for the content source.
• 21.  Leave the content source type as SharePoint.
• 22.  In the start addresses, add the URL you deleted in the previous default content source. If you forgot to remove it or have included the same URL in another content source, SharePoint will give you an error message when you try to save the content source.
• 23.  Under the crawl settings, decide if you want the crawl component to crawl over everything under the start host address, or remain inside the site collection. In my case, I have one site collection at the root of the domain and nothing else. If I had multiple site collections under the host name, the option to crawl everything would include these site collections also.
• 24.  New to SharePoint 2013 is the option to crawl continuously. Continuous crawls instruct SharePoint to crawl new content as it becomes available, such as in newsfeeds and blogs. This option avoids the issue of new content not showing up in search results until the incremental schedule kicks in.
• 25.  Finally, you have a crawling schedule and priority (if not using continuous crawling).
• 26.  Click the OK button to save the new content source.
• 27.  Microsoft dropped the option to start a full crawl in the Content Source Settings page, so to start a full crawl, click the new content source, then select the option to “Start a Full Crawl” from the pop-up menu.

Crawling External Web Sites

The steps in the preceding section are essentially all there is to setting up a content source, although different content source types provide different options. To demonstrate I shall now walk you through the steps to crawl a third-party web site.

• 1.  Open the Search Service Application Administration page.
• 2.  Click the Content Sources link in the left navigation.
• 3.  Click the link to create a new content source.
• 4.  Give the content source a name.
• 5.  Change the type to Web Sites.
• 6.  Provide the home page URL of the web site you intend to crawl.

• 7.  Set the crawl settings to crawl the start page—the crawl component will ignore links to other pages, stay within the server of the start address, or configure maximum server hops and page depth from the source.
• 8.  Set up the schedule and priority.
• 9.  Notice, there is no option to crawl continuously, because this is a feature of SharePoint content sources.
• 10.  Click OK, then start a full crawl of the new content source.
• 11.  If you have a Search Center configured for the web application associated with the Search Service Application, you can try searching for results against the web site you just crawled.

Other Content Sources

You might be wondering about the other content sources. Table 15-1 lists the details on all the out-of-the-box content source types (including those we already discussed) provided by SharePoint 2013.

Crawl Rules

Crawl rules define a set of rules such that the crawl processor can determine whether to process a piece of content for indexing. For example, earlier in the chapter I set up a content source to crawl over my blog site. If I want to exclude some pages or subsites of my blog, I can create crawl rules to restrict what the crawler considers content to index.

There is more to crawl rules than just inclusion or exclusion of entities in the search index. Crawl rules also allow users to instruct the crawler what authentication to apply to given content. By default, the crawler uses a Search Service account (defined when you installed SharePoint 2013) to access content. In the case of external content, you may need to apply alternate authentication methods to crawl the content.

From the Search Service Application Administration page, click the link for Crawl Rules to access a page where you can administer existing crawl rules and new rules. Figure 15-10 shows an example of the Crawl Rules page in my environment. Notice that I already have a crawl rule for the crawling of my blog—it is typically a good idea to create at least one crawl rule for any content source that crawls over external web site content.

At the top of the Crawl Rules page (Figure 15-10), SharePoint provides a test text box and button. This enables you to quickly check if a given URL of a content source matches any of the listed rules. For example, a user complains to you that some of the pages of a web site do not show up in search results. You confirmed that you created a content source for the web site and no errors or warnings surface in the log for the missing results. Entering the URL into the test box of the Crawl Rules page will immediately tell you if any rule exists prohibiting the crawl of the specified page.

The crawler is good at crawling over SharePoint, but when it comes to other sources, the crawler is only as good as the structure of the content. Web sites provide a good example: crawlers and spiders rely on HREF links to pages within web sites to discover new content. In some cases, a web site might contain a number of orphaned pages. Orphaned pages are those where no other parent page in the hierarchy or page within sibling sub trees points to the orphaned page. This can often happen when creating non-navigable subsites or pages in a site, which users access by knowing the direct URL. Since the SharePoint crawler has no way of getting to orphaned pages, the crawler must be instructed to include these locations when crawling. I shall demonstrate this configuration in the following steps:

• 1.  Click on the Crawl Rules link in the left navigation of your Search Service Application to access the Crawl Rules page.
• 2.  Click the link to add a new crawl rule.
• 3.  You should see a page like that in Figure 15-11.

• 4.  SharePoint might indicate at the top of the page that the page is unencrypted and to be careful passing credentials—you might see many warnings like this in your dealings with SharePoint 2013 when not using SSL.
• 5.  Provide the path to content for your crawl rule. You can use regular expressions by checking the check box. The path allows wildcard characters.
• 6.  The Crawl Configuration allows you to specify whether the crawler includes or excludes content matching the rule.
• 7.  Depending on whether you choose inclusion or exclusion, you have additional options to crawl complex URLs.
• 8.  Finally, the crawl rule allows you to specify the authentication. This part is slightly different from that in SharePoint 2010 in that there are additional options to authenticate via cookies, certificates, etc.
• 9.  Click the OK button to save the rule.
• 10.  You can test the rule using the text box and test button.

Server Name Mappings

Sometimes content sources are set up for crawling content on an internal domain name. A good example of this is in crawling over line of business (LOB) content, using BCS. The LOB system might reside on a local URI and the content configured as such. An issue arises when the search results, seen by end users, include the internal name locations instead of an addressable URI by the end users. Use server name mappings to solve this issue.

• 1.  Click the Server Name Mappings link in the Search Service Application left navigation.
• 2.  Click the link to add a new mapping (Figure 15-12).

  

  Figure 15-12. Mapping server names

• 3.  Provide the server name in use by the crawler (without a protocol prefix—HTTP/HTTPS).
• 4.  Provide the domain name for search results.
• 5.  Click the OK button to save the rule.

File Types

By default, SharePoint 2013 search will crawl and index only files of known type. Out of the box, SharePoint supports all the Office-type documents, e-mail files, ZIP files, and PDF documents.

Using the File Types page, you can add new files types for SharePoint to crawl. Simply click the link for File Types in the Search Service Application Administration page and then add a new extension. Adding an icon for your new extension requires some tinkering in the hive.

1. Navigate to the folder on each SharePoint server, as follows:

   C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions15TEMPLATEIMAGES

2. Add a new icon GIF file to this folder.
3. Navigate to the following XML folder on each SharePoint server:

   C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions14TEMPLATEXML

4. Open the DOCICON.XML file and add a new mapping node for the extension and GIF file.

Adding a new file extension and image file will instruct the crawler to consider files with this extension and to display the designated icon in the search results.

I must point out that adding the extension and icon of a new file type into the search settings for the Search Service Application will not guarantee that the crawler will search inside documents of this type, just that the crawler will not ignore the files to start and that search results will include a nice icon. The content processing component in your Search Service Application is responsible for processing the content of documents, and it accomplishes this with IFILTERs. An IFILTER is a compiled DLL that contains logic to open a designated file type and extract the content as text. Microsoft provides IFILTERs with SharePoint, to extract content from Microsoft Office documents. Prior to this version of SharePoint, the Adobe PDF IFILTER had to be installed to index inside PDF files (as well as adding a file extension and icon mapping). SharePoint 2013 includes support for PDF documents and ships with IFILTER to extract content inside PDF files.

Crawler Impact Rules

When crawling over content outside of SharePoint—especially web sites—you must observe the impact of searching these sources. Web site administrators are all too familiar with their web sites crashing because of too many concurrent user requests or high activity on their web servers. Search crawlers and spiders are often the culprits in causing slow web site performance. Most crawlers run multiple concurrent requests and queue up page requests until the crawler has covered all pages in a given web site. Typically, crawlers do not pose an issue for large-scale web sites, designed to handle high load, but this is not the case for all web sites. SharePoint incorporates throttling of the search crawler, using impact rules.

• 1.  Click the link for Crawler Impact Rules in the left navigation of Search Service Application Administration.
• 2.  Click the link to add a rule. You should see a page like that in Figure 15-13.

• 3.  Provide the domain name of the site, without the protocol (HTTP/HTTPS).
• 4.  Tweak the number of simultaneous requests or time between single requests.

In the case of a fragile web site, you should lower the number of concurrent requests or choose the option to request pages/documents one at a time with duration in between requests. Lessening the impact of crawling over a web site will cause SharePoint to take longer to crawl over the site, but ensure that the site does not fall over from too much traffic.

Authoritative Pages

SharePoint 2013 includes some sophisticated relevance-ranking algorithms, to determine order of search results, based on search criteria, provided by users. In certain cases, you may wish to help SharePoint search by influencing search results based on your own criteria of ranking, which is where Authoritative Pages come in.

Authoritative Pages are pages in SharePoint that you designate as requiring special mention in search results. Within the Authoritative Pages section of Search Service Application Administration, you can designate any number of pages as first-, second-, or third-level authority. SharePoint considers the level of these pages when rendering search results. Pages designated as top-most authority present soonest in search results.

Figure 15-14 shows an example Authoritative Pages configuration page in Search Service Application Administration. Configuring certain pages as authoritative is a simple case of adding them to the first, second, or third box.

Scrolling down the page (not shown in Figure 15-14), you should see a box to enter pages to demote. Demoted pages are those that you feel are unimportant, and those that you do not wish to see high in the list of search results. Sometimes the query processor decides a page is highly relevant because it contains many instances of a keyword, or matches many query rules, but your content owners may feel differently. Having the ability to demote a page ensures that the content owners remain happy.

Result Sources

SharePoint 2013 has done away with search scopes and replaced them with result sources. Search scopes used to allow users to refine search results returned from an index, so that you could scope the results for a particular scenario. For example, a search scope might restrict search results of a particular subsite and below in a site collection, so that users who use this scope in their search see only results for a narrow set of content. Result sources provide a similar function to search scopes, but with greater control over the filtering.

Clicking on the Result Sources link in the left navigation shows a page like that in Figure 15-15. SharePoint provides a number of result sources, based on what users typically search. Among those on the list are Pages, Documents, Pictures, and Local People Results. To understand how a result source works, you will now explore one of them by clicking the name and selecting the view option in the pop-up menu. I chose the Local People Results entry, which provides a page like that in Figure 15-16.

SharePoint provides a large warning message at the top of the page, indicating that you do not have permissions to modify this result source. This is a little misleading, in this case, because you do not have rights to edit any out-of-the-box result source. I am a farm administrator and administrator of my Search Service Application, so this clearly is not a permissions issue. In a moment, I shall demonstrate creating a new result source, where you do not see this warning.

Every result source has a name and description, and applies to Local SharePoint content, Remote SharePoint content, Open Search 1.0/1.1 content, or Exchange. Open Search is interesting in that you can request result sources from other search engines that support the 1.0/1.1 protocol. For brevity, I shall concentrate on result sources that apply to Local SharePoint content in this book.

The result source type applies to either SharePoint Search Results or People Search Results—SharePoint treats these types of search as distinctly different and applies different result sources to each accordingly.

Scroll to the Query Transform section of the Result Source page and you get into something more interesting. Before moving onto this sub-topic, I shall finish my summary of this result source with a brief mention about the authentication options at the bottom of the page. You have the choice to configure the result source using the common search account identity, or by providing a specific account—this comes in handy if you want results sets that a specific account has read rights to view.

To demonstrate query transform for result sources, I shall back out of the page (Figure 15-16) and return to the list of the Result Sources page (Figure 15-15). To create a new result source, execute the following steps:

• 1.  Click the New Result Source link.
• 2.  Provide a name and description—I created a result source that shows blog posts from my blog in the last month, so created a name and description as appropriate.
• 3.  Choose the Local SharePoint to scope results from SharePoint content in the Search Service Application local index.
• 4.  Leave all options default.
• 5.  Click the Launch Query Builder button to configure the Query Transform.
• 6.  You should see a dialog like that in Figure 15-17.

The query builder understands both Keyword Query Language (KQL) and FAST Query Language (FQL), which are used to define result source criteria. KQL and FQL provide superior query syntax to that of CAML (Collaborative Application Markup Language), used in earlier versions of SharePoint. SharePoint 2013 inherits FQL from that of the FAST ESP, which Microsoft included in the SharePoint 2013 platform. The syntax available for KQL and FQL is vast, so I shall provide you a reference at the following location: http://msdn.microsoft.com/en-us/library/sharepoint/jj163973%28v=office.15%29.

• 7.  The keyword filter provides filter capabilities of the entered keywords of a given search. For example, you can easily create a result source that lists recent documents edited by the user performing the search, or include a parameter from the query string in the search criteria. For my example, I only need the query from the search box.
• 8.  Choose your keyword filter and then click the button to add the keyword filter.
• 9.  The property filter allows you to apply additional filter properties to the search query, such as the Content Type, Author, or one or many managed properties.
• 10.  I added a property filter for Content Source and set a manual value to my content source: “My Blog.”
• 11.  Adding a restriction for last modified date is not so obvious. In the query text box I added the following to the end of the text: Write>{Today-30}
• 12.  My query text now looks as follows: {SearchBoxQuery} ContentSource="My Blog" Write>{Today-30}
• 13.  Click the Sorting tab.
• 14.  Change the “Sort by value” to desired sorting criteria, and add sort levels as desired.
• 15.  Click the Test tab; then click the Show More link.
• 16.  My Test tab looks like that in Figure 15-18.

• 17.  Provide a search query value to test.
• 18.  Click the Test query button to see the results in the right pane.
• 19.  Click the OK button to return to the Result Source page.
• 20.  Click OK again to save the result source.

At this stage, you might be wondering how to use the result source in your search results. Similar to how SharePoint 2010 allowed you to use scopes in search result Web Parts, SharePoint also allows you to apply result sources to search result Web Parts.

The ResultScriptWebPart now replaces the CoreResultsWebPart and provides greater functionality. One of the more obvious improvements is previous display, which SharePoint 2010 only provided with FAST. The ResultScriptWebPart understands result sources like the CoreResultsWebPart understood scopes. I shall demonstrate this behavior in the following steps:

• 1.  I am using a Search Center to render search results—you can just as easily create a page in your site collection and drop the ResultScriptWebPart.
• 2.  From the main landing page of the Search Center, execute a search to navigate to the Results page.
• 3.  Edit the page.
• 4.  Select the Search Results Web Part and then edit the Web Part properties (Figure 15-19).

  

  Figure 15-19. Properties for the Search Results Web Part

• 5.  Click the Change query button.
• 6.  You should see a query builder dialog appear (similar to that when creating a result source)—see Figure 15-20.

Query Rules

Query rules are a new feature of SharePoint 2013 that allows users to tailor search results in a flexible manner. Query rules consist of conditions and actions that SharePoint applies when a search query meets a condition. Think of query rules as a replacement for Best Bets, only smarter.

We are all familiar with Bing and Google, and you have probably seen promoted results when searching for a comment term. You can accomplish the same behavior using query rules in SharePoint 2013.

1. Click the Query Rules link in the left navigation of your Search Service Application.
2. Change the source drop-down to Local SharePoint Results.
3. You should see a page like that in Figure 15-21.

Figure 15-21 shows a page of query rules for the result source: Local SharePoint Results. The query rules consist of several conditions and matching actions. Take the “People Name in SharePoint Search” as an example. This query rule consists of a condition that matches the search terms with the People dictionary to determine if any of the terms match a person’s name. If the search terms satisfy the condition, the action promotes the search result at the top of all other search results, and additionally executes another sub-search for the last two recent documents modified by the person. When searching for my name in my Search Center, I see the result in Figure 15-22.

To demonstrate creation of custom query rules, I shall provide some steps to include a promoted block at the top of the search results when a user searches for the term “SharePoint.” I previously created a content source to crawl my blog, and am using the “Local SharePoint Results” results source in my demonstration.

1. Click on Query Rules from the left navigation of the Search Service Application.
2. Change the source to Local SharePoint Results (System).
3. Click the Add Rule button.
4. On the next page, provide a name for the rule.
5. Choose the option to match a keyword exactly.
6. Provide the keyword: SharePoint.
7. Scroll down the page and click the Add Promoted Result link.
8. In the dialog that appears, give the promotion a title, URL, and description—I used my blog.
9. Click the Save button on the promotion result dialog.
10. Click the Save button on the Query Result page.
11. Open the Search Center and execute a search, using the keyword “SharePoint” (make sure to type the casing correctly).
12. My results look like that in Figure 15-23.

    

    Figure 15-23. Promoted result in search results

Of course, my example was a trivial one. Feel free to add multiple query rules and order them according to your desired rank. You can also arrange certain query rules to fire in certain date ranges, so you can promote content for different times.

Query Client Types

There really is not a whole lot to say about query client types—they are a series of labels, used by different applications. Each application that requires the use of SharePoint 2013 search should provide a client type. SharePoint then throttles performance of search result generation based on three tiers: top, middle, or bottom. For example, applications using the client type as “Alerts” get a top tier search classification, whereas applications using the client type “Monitoring” receive a bottom tier classification.

Query client types come in handy when monitoring search query reports. Figure 15-24 shows the query latency report, filtered by query client type. Filtering by client type allows you to see what applications are consuming most resources for search.

Search Schema

Search schema is the new name for managed properties and crawled properties. Managed properties and crawled properties are metadata properties that drive search results and map back to content. SharePoint 2010 introduced refiners, which are essentially facets and allow filtering of search results by different fields, such as Author, Language, etc. Managed and crawled properties facilitate refiners. I shall tackle each of these properties’ types separately.