Configure trust for search between two SharePoint Server 2013 farms

http://technet.microsoft.com/en-us/library/dn133749(v=office.15).aspx

http://blogs.technet.com/b/mspfe/archive/2013/02/01/how-query-rules-and-result-sources-can-be-used-to-customize-search-results.aspx

SharePoint 2013

2 out of 2 rated this helpful - Rate this topic

 

Applies to: SharePoint Server 2013

Topic Last Modified: 2014-07-16

Summary:Configure a SharePoint Server 2013 content farm that receives search queries to trust the SharePoint Server 2013 farm that sends the queries.

To configure an on-premises SharePoint Server 2013 content farm to return results from its search index to a separate on-premises SharePoint Server 2013 farm, you must perform the following two main procedures:

1. In the farm that will receive the search queries, configure trust of the farm that will send the queries by doing the following:
   • Configure a server-to-server trust relationship by using the Open Authorization 2.0 (OAuth 2.0) web authorization protocol.
   • Enable the farm that receives the queries to return search results from all of its web applications that host content.
2. In the farm that will send the search queries, create a result source that does each of the following:
   • Specifies Remote SharePoint as the protocol.
   • Specifies the address of any root site collection in the SharePoint farm that will receive the search queries.
   For more information, see Configure result sources for search in SharePoint Server 2013.

   Note:
   After you create the result source, you expose the search results that it provides by using it in a Web Part or a query-rule action. In this way, users of the farm that is sending search queries can see results from the farm that is receiving the queries. For more information, see Understanding result sources for search in SharePoint Server 2013.

This article describes how to perform the first procedure in the list above: how to configure the farm that receives search queries to trust the farm that sends the queries.

For brevity in this article, the following terms are used:

 

SendingFarm	An on-premises SharePoint Server 2013 farm that has a search service that sends search queries to ReceivingFarm.
ReceivingFarm	An on-premises SharePoint Server 2013 content farm that has a search index that receives search queries from SendingFarm. In this article, it is assumed that ReceivingFarm has at least one web application that hosts content.

In order for SendingFarm to be able to get search results from the search index in ReceivingFarm, the farms must have the following characteristics:

• Each farm is a SharePoint Server 2013 on-premises deployment.
• User profiles in the two farms are synchronized. For more information, see Server-to-server authentication and user profiles in SharePoint Server 2013.

Note:

Because SharePoint 2013 runs as websites in Internet Information Services (IIS), administrators and users depend on the accessibility features that browsers provide. SharePoint 2013 supports the accessibility features of supported browsers. For more information, see the following resources: Plan browser support Accessibility for SharePoint 2013 Accessibility features in SharePoint 2013 Keyboard shortcuts Touch

To configure ReceivingFarm to trust SendingFarm

1. Verify that the account that performs this procedure is a member of the following groups:
   • Farm Administrators group in ReceivingFarm.
   • Administrators group on the server on which you are running Windows PowerShell cmdlets.
     An administrator of that server can use the Add-SPShellAdmin cmdlet to grant someone permission to use SharePoint 2013 cmdlets. When you run the Add-SPShellAdmin cmdlet, you must have membership in the securityadmin fixed server role on the SQL Server instances, and you must have membership in thedb_owner fixed database role on all databases that are to be updated. For more information, see Add-SPShellAdmin. Contact your system administrator or SQL Server administrator to request these memberships if you do not have them.
2. On a server in ReceivingFarm, start the SharePoint 2013 Management Shell.
   • For Windows Server 2008 R2:
     In the SharePoint 2013 environment, on the Start menu, click All Programs, click Microsoft SharePoint 2013 Products, and then click SharePoint 2013 Management Shell.
   • For Windows Server 2012:
     • In the SharePoint 2013 environment, on the Start page, click SharePoint 2013 Management Shell.
     • If SharePoint 2013 Management Shell is not on the Start page, right-click Computer, click All apps, and then click SharePoint 2013 Management Shell.
     For more information about how to interact with Windows Server 2012, see Common Management Tasks and Navigation in Windows Server 2012.
3. On a server in ReceivingFarm, run the following commands at a Windows PowerShell command prompt. The commands use the OAuth 2.0 web authorization protocol to configure a server-to-server trust, so that ReceivingFarm will trust SendingFarm.
   # Create a trusted security token issuer
   $i = New-SPTrustedSecurityTokenIssuer -Name "SendingFarm" -IsTrustBroker:$false -MetadataEndpoint "https://<SendingFarm_web_application>/_layouts/15/metadata/json/1"
   # Configure trust of the token-signing certificate'
   # by adding the trust used to sign oAuth tokens'
   # to the list of trusted root authorities'
   # in ReceivingFarm
   New-SPTrustedRootAuthority -Name "SendingFarm" -MetadataEndPoint https://<SendingFarm_web_application>/_layouts/15/metadata/json/1/rootcertificate
   

   Where:
   https://<SendingFarm_web_application> is any SSL-enabled web application in SendingFarm

   Important:

   Web applications that include server-to-server authentication endpoints for incoming server-to-server requests, or that make outgoing server-to-server requests, should be configured to use Secure Sockets Layer (SSL). For information about how to configure a web application to use SSL, see Create claims-based web applications in SharePoint 2013. For information about how to configure HTTP support for server-to-server requests, see Configure an STS for HTTP in Configure server-to-server authentication in SharePoint 2013.

4. On a server in ReceivingFarm, at a Windows PowerShell command prompt, run the following command:
   # Use $realm to store the string'
   # that comes after the "@" character'
   # in the value of $i.NameId
   $realm = $i.NameId.Split("@")
   

5. On a server in ReceivingFarm, at a Windows PowerShell command prompt, run the following commands to enable all web applications in ReceivingFarm to return search results to SendingFarm:
   $s1 = Get-SPSite -Identity https://<ReceivingFarm_web_application>
   $sc1 = Get-SPServiceContext -Site $s1
   # Set up an authentication realm for'
   # a web application that hosts content in ReceivingFarm 
   Set-SPAuthenticationRealm -ServiceContext $sc1 -Realm $realm[1]
   # Get a reference to the application principal'
   # for that web application in Farm B
   $p = Get-SPAppPrincipal -Site https://<ReceivingFarm_web_application> -NameIdentifier $i.NameId
   # Grant rights to the application principal'
   # that SendingFarm will use'
   # when it sends queries to ReceivingFarm
   Set-SPAppPrincipalPermission -Site https://<ReceivingFarm_web_application> -AppPrincipal $p -Scope SiteCollection -Right FullControl
   

   Where:
   https://<ReceivingFarm_web_application> is an SSL-enabled web application in ReceivingFarm.
6. Repeat the previous step (step 5) for each web application in ReceivingFarm that hosts content that you want to search.

How To Customize SharePoint 2013 Search Results Using Query Rules and Result Sources

Premier Field Engineers

1 Feb 2013 12:00 AM

• 9

---

Summary:  Brendan Griffin, Microsoft Certified Master (SharePoint 2010) and Senior Microsoft Premier Field Engineer based in the UK, provides us with details on working with SharePoint 2013 Search.  As you may (or may not) know, SharePoint 2013 search has changed quite dramatically from previous versions both from a functionality and manageability perspective – as Brendan mentions: all for the better, of course!  Enjoy!   

---

SharePoint 2013 brings together the power of FAST Search with the simplicity and management of SharePoint 2010 search.  SharePoint 2013 is the first release of SharePoint to fully integrate FAST Search into the core product, as a result of this search has changed quite dramatically both from a functionality and manageability perspective – all for the better, of course!

The aim of this post is to provide insight into Query Rules and Results sources.  Some of the functionality provided by these features may sound familiar as previous releases of the product did include some of this functionality; however, as you will see, SharePoint 2013 takes this to the next level.

Query Rules

Let’s get started with Query Rules, in prior releases of the product it wasn’t really possible to do much with an end user search query.  Sure, SharePoint found what it thought was relevant and provided search results to the user, but sometimes it would have been great to tune search results based upon the intent of the query that the user submitted, essentially providing the ability to influence search results.  For example, when a user performs a query for “product ABC” it may be desirable to promote results for marketing material for the product.

Query Rules can be created at the Search Service Application, Tenant, Site Collection or Site level, as follows:

Site

Site Collection

Search Service Application

Tenant

Query rules are composed of three components:

1. Condition – When to apply the rule?
2. Action – What to do when the rule is matched?
3. Publishing – When should the rule be active?

Conditions

Conditions determine when the rule should apply; there are six different types of conditions that are available. Full details of all of the conditions can be found here – Managing Query Rules in SharePoint 2013.

Here are examples of how three of these conditions can be used:

Query Matches Keyword Exactly – If you need the query rule to apply when a specific query is performed, this is the condition to use. In the example below the query rule will apply when a query for “widget” is performed

Query Contains Action Term – An action term is basically a trigger word, this rule will apply when the query contains the action term specified, either at the beginning or the end of the query.  In the example below the action term is “human resources,” therefore queries for either “human resources contacts” or “contacts for human resources” will cause the rule to apply however a query for “human resources” would not.

It’s also possible to configure this condition to use a term set rather than specifying each action term within the rule itself.  This is really useful if you have a large number of action words, for example a list of products:  instead manually typing in each product -- which wouldn’t be fun -- the rule could use a term set that contained product names.  An added benefit of this is that when a new product is introduced you wouldn’t need to edit the query rule, as the action term is contained in a term set it’s a simple as updating the term set.

One thing to point out:  search checks the dictionary every 30 minutes for updates so changes to the term set will not be reflected in the query rule straightaway.

Query Matches Dictionary Exactly

This is basically the same as Query Matches Keyword Exactly, however, instead of manually specifying one or more keywords this rule is configured to use a specific term set, any values within the specified term set will cause the rule to apply.  In the example below, the Customers term set has been used, this contains three terms – Litware, Contoso and Adventure Works.  Therefore a query for any of these customers would cause the rule to apply.

Actions

Once the condition has been configured the fun begins!  The next step is to decide what to do when the query rule applies.  Essentially there are three options here:

1. Add Promoted Result
2. Add Result Block
3. Change ranked results by changing the query

Here’s some drill-down on each of these options:

Add Promoted Result – A promoted result is a result that appears at the top of the search results, this is particularly useful way to promote a particular search result.  For example, you may want a query for “human resources info” to promote a link to the human resources SharePoint Site.

For those of you familiar with previous versions of SharePoint this is a “Best Bet.”  When a promoted result is added three pieces of information are required:  a title, URL and description.

Here is an example of how this would look to an end user.

As you may have seen from the screenshots above it’s also possible to render the URL as a banner instead of presenting a link.  This could be useful in an Intranet scenario, for example when a user searches for “London office” a banner is displayed that provides the address and telephone number of the London office.  It’s a quick and easy way to present users with the information they are searching for.  For those familiar with FAST this functionality was known as a Visual Best Bet.

Add Result Block – A result block is a selection of results that are integrated into the core search results. The interesting thing about a result block is that the results don’t necessarily need to come from the local search index!  A result block uses a result source, which can be one of the following:

• Local SharePoint farm
• Remote SharePoint farm
• OpenSearch
• Exchange

As well as providing access to search results both inside and outside of SharePoint (for example Exchange), a result source can also be used to narrow down the content returned.  For those of you who have worked with previous versions of SharePoint, search scopes and federated locations have evolved into result sources.  A number of result sources are available out of the box, such as Documents, which returns all files which match the following file types from the local SharePoint index - DOC, DOCX, XLS, XLSX, PPT, PPTX or PDF.

A result source could be configured using OpenSearch to return results from Bing within the standard search results from the local SharePoint index.  In the example below, the queries for “legislative codes” have been configured to add a result block that uses the Bing result source.

The result block itself can be shown at the top of search results (as above) or can be ranked within the core results – this may mean that the result block doesn’t display as it will be ranked like all other results.  One thing to point out is that the result block is ranked as a whole rather than each link within the result block having a separate ranking.

Additional configuration options include the ability to select the number of links to show in the result block and also to display a “Show More” link to obtain further results from the source.  In this example the more results link would open Bing and perform the same query.

MOSS 2007 and SharePoint 2010 did include similar functionality using the “Federated Results Web Part,” however this didn’t provide the ability to present results within the core search results, and results were presented in a separate Web Part which wasn’t aesthetically pleasing or user friendly.

Change ranked results by changing the query – This is where you have ultimate power to change the way in which a query is handled by SharePoint.  The Query Builder tool provides the ability to supplement a query with additional keyword or managed property restrictions.  For example, a query with the action word “contract” such as “sales contract” could be configured to only return Word documents using the action term “contract” as the keyword filter and the managed property filetype=DOCX.  This is a fantastic way to tune search results, either based upon user feedback or analysis or the out of the box Search Usage Reports, more information on which can be found here - View search diagnostics in SharePoint Server 2013

Below are the subsequent search results for “sales contract”

As you can see this is a very powerful tool, but with great power comes great responsibility so caution is always advised when using this functionality.

Publishing

Last but not least, the final decision is when to make the rules active. The default setting will make the rule active until such a time that it is manually deactivated, however it’s also possible to control when a rule is active using a schedule.

This could be really useful when a query rule only needs to be active for a set period of time, for example an e-commerce site could have a query rule in place for the term “sales” that only needs to be active for a short period of time, such as the holiday period.  From an Intranet perspective this could be a query rule for “performance review” that’s only active whilst a performance review cycle is in place – as with most things in SharePoint the possibilities are endless!

Summary

As mentioned earlier in the article query rules can be configured at multiple levels and are inherited by default, therefore a query rule created at the Search Service Application level will be inherited by all Site Collections, and rules created at the Site Collection level will be inherited by all Sites within the Site Collection.  It’s possible to deactivate an inherited rule at any scope if required, for example when an inherited rule causes un-desired results due to a clash with a rule that has been created at the Site level.

One final point to be aware of - If multiple query rules are in place there is a chance that more than one will apply to a given query, this poses a potential challenge as there isn’t a prescribed order that the rules will execute unless a custom group is used to organise the query rules.  The process is documented here – Section - To rank query rules for a site collection

Well that’s it for this short overview on Query Rules and Result Sources, I’m sure you will agree these two new features provide some great opportunities for tuning search to meet your specific requirements.