Up until this point, we have been working to recreate a solution that was partially out of the box with limited additional configuration needed so that we could reach the point of creating a specific solution for our Enterprise Search experience. And while it is true that the setup and configuration of Enterprise Search still needs to be performed in SharePoint 2010, the nature of setting up Enterprise Search through a Search Service Application (SSA) is not too far from the SSP setup that would have included the Search service in the first place. The only things we needed to do additionally, which were also identical to SharePoint 2007, was the creation and configuration of the Content Sources as detailed in my previous post. Now that we have arrived at the same starting point as the Collaboration Portal from SharePoint 2007, we can examine the additional customization needed to create our targeted Search solution.
As we have seen with SharePoint Foundation Search, Search is limited to only the Site Collections in which they are performed, allowing a search query to run in relation to any content within that Site Collection from the Site and below where the search is performed. In some ways, Enterprise Search in the previous version out of the box worked like this, since Context Search was added at that time. However, Context Search does not go beyond the Site Collection and thus cannot be considered Enterprise since it cannot touch other Site Collections, much less content not included in a SharePoint Site.
To achieve a more global search set, the inclusion of an indexing service and associated content sources is required to allow SharePoint to communicate with any content and thus return truly Enterprise Search results. Thus by default, a search query returns results from any crawled content, and is displayed through several possible interfaces, which include the Search Center Sites. In this regard, a Site Collection must be configured to determine which Search Center Site will display results as well as submit the queries. Since this is not configured in most Site Templates in SharePoint 2010, this must be set or the result sets will never return content outside of the Site Collection. This sums up what we have achieved thus far in our solution.
However, Enterprise Search is not limited to specific content like it is with Context Search, so long as the content is crawled by SharePoint. This means that more specific relevance may not have much impact on the search results if perhaps we were only looking for content in a specific repository, such as a specific Site or File Share. To configure this, we need to create a Search Scope. In essence, a Search Scope is a logical division of a Search Content Database configured to perform queries against less than the entire corpus of the searchable content.
Site Collection Search Scopes
There are, in effect, two configurable levels of Search Scope: Global and Local. Global refers to all Sites in a Farm (or connected Farm), while Local refers to a specific Site Collection. Although Search Scopes can be configured at either level – one through Central Administration or one through Site Collection Administration respectively – both scopes are managed by the SSA as far as publishing, rules, updating and availability. Global Search Scopes are useful when a particular logical division, such as by a specific type of content, is required or applicable across all Site Collections in the Farm, but the more granular nature of a Local Search Scope allows the Site Collection Administrator control over how that group of Sites will use a logical limitation that may only apply to that group of Sites. If this were a business unit, a branch location or even an internal only type of function, the ability to choose availability of Search Scopes can be beneficial.
One of the main reasons why the Search Scope is valuable, however, is inherent in the purpose of the Search Scope, which is to limit what will be searched within the arrangement of the available content. Search Scopes allow this limitation through several configuration options, all aimed at tightening the view of the content that will be searched. The most common is by Content Source, but this can also be configured to the URL level and thus as broad as an entire host or domain to a specific site or folder. This configuration, called a Scope Rule, allows for a specific, almost topic- or area-related scope to be applied to search queries. In our example, by configuring a Search scope with a Scope Rule that only searches the specific Document Center where the promotional data is located, we can pinpoint where the search will be run against without having to touch other content sources.
The key differences between a standard Contextual Search and a Search Scope allows the granularity of focusing only on a specific data source rather than the Site Collection as a whole. This also produces a targeted effect anywhere a search needs to be run, regardless of the Site in the Site Collection. This feature is applicable to our solution as a Site Collection Search Scope however, because it limits the availability to our targeted Portal rather than being a globally available limit. If the solution called for a specific targeting type not limited to a group of Sites, using a global Search Scope would be appropriate, but as this Site Collection was used specifically for the purpose of housing and accessing this specific data, the Site Collection level works best.
We need to complete several steps to configure our Search Scope for our Organizational Portal to target the Document Center where all the location-specific data will be searched.
1) Create the Search Scope
Through the Site Collection Administration page we create the Search Scope by simply naming the Scope, then configuring a few additional areas.
Aside from a Title, we also need a Display Group and a Target Results Page. The Display Group organizes Search Scopes by a type that shows in the drop-down options depending on where the Search Scope is logically grouped. A Search Scope grouped into a set can be used when configuring how search queries will be run by selecting the Scope for the type of search that is expected to be performed. In most cases, the Search Dropdown will be the most likely group as it is the default, but others can be created for additional targeting limitations, such as certain types of content only within certain branches or divisions. Display Groups can only be configured through the Site Collection Administration page governing the Search Scopes, ensuring that these groupings apply within a Site Collection.
As a Display Group is created, or a new Search Scope is created if the Display Group already exists, the Search scope can be paired with the proper Display Group by either means. A Display Group can further define which Search Scope will act as the default scope, but all Search Scopes within a Display Group can be giving a position, indicating its important, relevance or focus based on how far from the top the Search Scope is available. A Search Scope can be paired with more than one Display Group, if it applied. At times, with reasons such as types of content or location of content, a Search Scope could have a many-to-many relationship as well as a one-to-many relationship, although these types of configurations need to be logically organized to make sense to the user or it will lose its application and perhaps even confuse the user further.
We will discuss the Target Results Page at a later time.
2) Define the Display Group
By either method – Creating a New Display Group or Creating a New Search Scope if the Display Group is available – we can choose which drop-down will be tied to the Search Scope. Since we want to perform standard Enterprise Searches but also use a targeted search, a Display Group indicating where the Search Scope will be used will be created to indicate how that search will run. By creating a one-to-one relationship between Display Group and Search Scope, we can eliminate confusion over how the Search Scope will work. Note that at least one Display Group must be chosen for the Search Scope to surface and be usable.
Search Scope Rules
3) Create the Search Scope Rule
Once the Search Scope is created, a single or multiple set of Rules needs to be created for the Search Scope to be properly limited. The Search Scope will not be available until Rules are added, although only one Rule is necessary.
Each of the types of Rules focus on how the content will be divided, such as by Web Address or by Property. However, from within a Site Collection, one Rule type that focuses on Content Source cannot be chosen, although this can be configured through Central Administration. In our scenario, the Web Address Rule will apply as we want our Search Scope to be limited to only the Document Center within our Portal. Since the Web Address options are very specific, we need the Folder level to indicate our Document Center Subsite in our Portal Site Collection. Also, the ability to Include, Exclude or Require is also important, as each type indicates an OR, AND or AND NOT operator Rule respectively. This allows for multiple rules to be properly joined or excluded as needed. Since we do not need to configure additional Rules, the default of Include will suffice.
Once a Rule type is chosen it cannot be changed, although it can be deleted and recreated.
4) Publish the Search Scope
Rules can be changed, removed or added at any stage, but each change, including creation of the Search Scope with at least one Rule, requires that the Search Scope be processed by the SSA upon completion. This process typically takes about 14 minutes but can be processed sooner through Central Administration.
Once the Search Scope has been properly configured, it can now be bound to a Search Center through the use of Web Parts, Targeted Pages, and Search Settings.
Because this behavior of grouping and logically limiting search queries is not automatic behavior, there are several steps involved with configuring a working, usable targeting system that will allow for the right level of focus as well as application. By creating a Search Scope with a single rule to focus only a the Document Center, and then grouping that Search Scope into a single Display Group, all search queries that run through that Search Scope Display Group will only yield results from our targeted location, effectively creating and focusing the targeting requirement of our solution. And while this particular solution did not require it, some thought and planning should go into the creation of Search Scopes, Search Scope Rules, and Display Groups, to optimize the Enterprise Search experience and not confuse or detract from the Search Application.
One last customization needs our attention, however, which is how the Search Center, the Search Settings, the Content Source, and the Search Scope all come together. This will be the topic of the next blog post.