Logo
programming4us
programming4us
programming4us
programming4us
Home
programming4us
XP
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server
programming4us
Windows Phone
 
Windows Server

SharePoint 2010 : Configuring Search Settings and the User Interface - Federated Search

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
4/5/2013 4:39:45 PM

This section focuses on understanding what federated locations are as well as best practices on how to use them. It also gives a detailed description of typical management tasks related to federated locations.

Federated Locations

SharePoint 2010 comes with a preconfigured set of locations (Figure 1), which includes local locations that are indexed and searched by the SharePoint 2010 search engine. It is, however, sometimes required that content is indexed outside SharePoint. The list of locations can be expanded to include other federated locations as long as they support the OpenSearch 1.0 or OpenSearch 1.1 standards.

Examples of when federation is feasible include the following:

  • Large external content sources that are already indexed elsewhere; Wikipedia is an example of this.
  • When the scheduled crawler in SharePoint is not optimal—for instance, when content changes rapidly and needs to be immediately available. For these cases a custom crawler and index are better.
  • Security setup requires a context not available in SharePoint. This could, for example, be when content is stored on a different isolated domain and the search needs to be performed using a different security context.
  • The content is indexed externally and only searched for rarely, which makes it overkill to index it in SharePoint.
  • The limitation of 500 content sources in SharePoint forces the use of federated locations.

In some cases, however, it is not feasible to use federation. Examples of this include the following:

  • Bandwith between the SharePoint farm and the federated location is too small such that crawling and indexing are not possible with a reasonable performance.
  • The content to be indexed is changing raplidly but does not need to be immediately available.
  • It is not possible or feasible to index the content externally.
  • It is not possible to make the content searchable through the supported OpenSearch specifications.

Federation is configured from the Search service application. To open the federation page, go to Central Administration => Search Service Application => Federated Locations.

Image

Figure 1. Federated Locations page

A new federated location can be created in three ways:

  • Import Location: It will prompt for an FLD (Federated Location Definition) file. This file contains all information required to automatically configure the location.
  • New Location: All settings must be specified from scratch.
  • Copy Location: Option available on the drop-down of existing locations; this will duplicate that location and its settings.

Which method should be chosen depends on the scenario. For cases where an FLD file already exists, this option is best. Even if the FLD file does not contain the exact configuration needed, it is much easier to modify an existing definition than to create one from scratch. The same thing applies if a definition that is similar to the new one exists. Then it is almost always a better choice to use the Copy option to duplicate an existing location and then modify it as needed. This is generally the best practice with SharePoint. Start with something that works, and then modify it. A lot of developers and IT professionals have spent countless hours trying to solve problems that are hard to identify because they attempted to configure from scratch instead of modifying something that works. SharePoint is not always generous with its error messages.

Note Federated locations must support the OpenSearch 1.0/1.1 standards.

Import Location

The easiest way to add a new federated location is to use the location's FLD file for SharePoint 2010 (if one exists). FLD files are typically 15–50 kilobytes. The FLD file contains all the rules and markup required to make it show in the SharePoint federated search Web Part.

Note Microsoft has published a set of federated search connectors on http://technet.microsoft.com/en-us/enterprisesearch/ff727944.aspx.

To add a connector to SP2010 (Figure 2), follow these steps:

  • Open the federation page: Central Administration => Search Service Application => Federated Locations.
  • Click Import Location to open the file dialog.
  • Browse to the FLD file, and click the OK button.
Image

Figure 2. Loading FLD file

After importing an FLD file, a prompt will be shown with the import result (Figure 3). It is not possible to import malformed FLD documents. The important part of this message is the note that the location must be added to a property on the relevant Web Part in the search center.

Image

Figure 3. FLD file loaded result

After successfully importing the FLD file, it now shows as an item in the Federated Locations list (Figure 4).

Image

Figure 4. Federated Locations page with new locations

New Location

New federated locations (Figure 5) can be created for both the existing SP2010 index or for external search indexes. SP2010 offers great functionality for easing the configuration of adding external federated sources and displaying results from them.

To add a new federated location to SP2010, do the following:

  1. Open the federation page: Central Administration => Search Service Application => Federated Locations.
  2. Click New Location to open the Create Location page.
  3. Enter the appropriate information, and continue to the next section.
Image

Figure 5. Location creation—general settings

Choose a trigger for the federated search (Figure 6). In most cases, this will be set to Always. Filters can, however, be applied to provide logic for when the federated location should be queried.

Image

Figure 6. Location creation—trigger settings

Select the appropriate Location information (Figure 7). To query external search indexes, they must support OpenSearch version 1.0 or 1.1. This is not required for the internal search index.

Image

Figure 7. Location creation—location type

The query template defines the URL to query and the filters to be applied to the query. For live search, this could be http://search.live.com/news/results.aspx?q={searchTerms}&format=rss, as shown in Figure 8.

Image

Figure 8. Location creation—query template

The “More Results” Link Template box (Figure 9) defines the navigation URL that allows the end user to request more results. This is per default disabled on the Top Federated Results Web Part. For live search, this could be http://search.live.com/news/results.aspx?q={searchTerms}&mkt=en-us&scope=&FORM=LIVSOP.

Image

Figure 9. Location creation—“More Results” Link Template box

The Display setting defines how search results will be presented in the user interface (Figure 10). SharePoint 2010 can show results from almost all sources in a nicely formatted manner. Some federated locations, however, might benefit from customized formatting. An example could be YouTube videos if YouTube is selected as a federated location.

Image

Figure 10. Location creation—Top Federated Results Display Metadata options

It is possible to restrict usage of locations (Figure 11). Some search indexes require authentication. SP2010 offers options to use either anonymous access, common authentication, or user authentication. Common authentication is relevant for searching secured internal repositories available to all employees. User authentication is relevant when not all users of the search center with the federated search results are permitted to view the entire source data of the search index.

Image

Figure 11. Location creation—Restrict Usage and Specify Credentials options

Note When searching federated locations, special attention must be paid to the security implications of allowing queries to be sent to external sources. Most search engines store queries for months or years. If the queries themselves contain confidential information, this will be stored at remote sites. As information is sent on unsecured channels, queries can also possibly be intercepted. It is always recommended to do a security review before using external federated locations.

Copy Location

New locations can also be created by copying an existing location (Figure 12). This is useful if the new location should be similar to an already existing location. Copying federated locations is an easy way to get started with creating a new federated location. SP2010 offers great functionality for easing the configuration of adding external federated sources and displaying results from them.

Image

Figure 12. Duplicating locations with the Copy Location option

To copy an existing federated location, do the following:

  1. Click the drop-down for the location to duplicate, and choose Copy Location. After clicking Copy Location, the Create Location page of the new location will open.
  2. On the Create Location page, all fields will be filled out with the same values as the location that is being duplicated, except the Location Name field (Figure 13). This field must be unique and is therefore required to be filled before the copy is completed.
Image

Figure 13. Duplicating locations—specify a new unique Location Name

Other -----------------
- Windows Server 2008 R2 : Hyper-V feature focus - Planning for Hyper-V, Installing and Administering Hyper-V
- Windows Server 2008 R2 : Hyper-V feature focus - Introduction to Virtualization and Hyper-V, Hyper-V Changes
- Windows Server 2003 on HP ProLiant Servers : File Replication Service Design and Implementation (part 2) - Diagnostics and Troubleshooting Methods and Tools
- Windows Server 2003 on HP ProLiant Servers : File Replication Service Design and Implementation (part 1)
- Understanding Network Services and Active Directory Domain Controller Placement for Exchange Server 2007 : Understanding AD Functionality Modes and Their Relationship to Exchange Groups
- Understanding Network Services and Active Directory Domain Controller Placement for Exchange Server 2007 : Exploring DSAccess, DSProxy, and the Categorizer
- Understanding Network Services and Active Directory Domain Controller Placement for Exchange Server 2007 : Defining the Global Catalog
- Integrating BizTalk Server 2010 and Microsoft Dynamics CRM : Communicating from BizTalk Server to Dynamics CRM (part 6)
- Integrating BizTalk Server 2010 and Microsoft Dynamics CRM : Communicating from BizTalk Server to Dynamics CRM (part 5) - Generating a proxy service
- Integrating BizTalk Server 2010 and Microsoft Dynamics CRM : Communicating from BizTalk Server to Dynamics CRM (part 4) - Configuring the BizTalk endpoints
 
 
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
 
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server