Navigate Up
Sign In
Supporters of Developer
Web

A side-by-side approach for upgrading SharePoint search to FAST

Search SSA in disguise
Item is currently unrated. Press SHIFT+ENTER to rate this item.1 star selected. Press SHIFT+ENTER to submit. Press TAB to increase rating. Press SHIFT+ESCAPE to leave rating submit mode.2 stars selected. Press SHIFT+ENTER to submit. Press TAB to increase rating. Press SHIFT+TAB to decrease rating. Press SHIFT+ESCAPE to leave rating submit mode.3 stars selected. Press SHIFT+ENTER to submit. Press TAB to increase rating. Press SHIFT+TAB to decrease rating. Press SHIFT+ESCAPE to leave rating submit mode.4 stars selected. Press SHIFT+ENTER to submit. Press TAB to increase rating. Press SHIFT+TAB to decrease rating. Press SHIFT+ESCAPE to leave rating submit mode.5 stars selected. Press SHIFT+ENTER to submit. Press SHIFT+TAB to decrease rating. Press SHIFT+ESCAPE to leave rating submit mode.

The scheduled downtime solution

Upgrading your search solution to FAST for SharePoint (FS4SP) involves creating two new Search Service Applications, reindexing your content, and then at some point switching out the Standard SSA with the FAST Query SSA in your application proxy group as seen in fig. 1. (You can read more about the FS4SP SSA architecture on the TechNet Wiki)

Figure 1 - Configure Service Application Associations

In addition you will have to create a new search center for your FS4SP results in order to verify that you actually get results back and that they look the way you expected. Depending on how much content you have indexed this can usually only be done in the production environment. When testing your new search solution against FS4SP you must switch the default SSA in the application proxy group from the SharePoint one to the FS4SP one. This renders the built-in search in a non-working state while you test FS4SP. And once you switch back, the FAST search center will not work.

This all boils down to scheduled down time for testing and switching your search solution over to FS4SP.

You can work around this limitation by creating a new web application and a new application proxy group for this web application. You will also have to create a new site collection and a search center in this site collection. But why all the extra work, when you can have both the built-in search and FAST search running side by side in the same site collection?

Mikael's no-downtime solution

The approach is to "upgrade" your current SSA to take the role of the FAST Query SSA. You will still have to reindex all your content (except people search) and most likely customize a new search center, but you can do it without touching the proxy application group or creating new web applications or site collections. And there is no down-time!

How is this possible?

Figure 2 - Create new Search Service Application

If you look under the covers on the search service applications, you will see that the FAST Query SSA is merely a regular SharePoint SSA with some extra properties. The first clue as to how alike they are is that people search with FS4SP is set up on the FAST Query SSA, using all the search bits from SharePoint itself and not FS4SP.

The second clue appears when you look at <14 Hive>\TEMPLATE\FEATURES\SearchAdminWebParts\searchadministration.aspx which has a conditional setting to display a link to the "FAST Search Administration" page as seen below.

<% if (IsSearchApplicationFast) { %>
<li class="static">
	<a  class="static menu-item" href="/_admin/search/extendedsearchadministration.aspx?appid=<%=SearchApplicationId%>" title='<asp:Literal runat="server" Text="<%$Resources:Microsoft.Office.Server.Search,FSAdmin_Central_Admin_Title%>"/>'
		id="S2LeftNav_Fastsearch"> 
		<span class="additional-background">
		<span class="static menu-item" >
		<asp:Literal runat="server" Text="<%$Resources:Microsoft.Office.Server.Search, FSAdmin_Central_Admin_Title%>"/>
		</span> 
		</span> 
	</a>
 </li>
<%}%>

And thirdly when looking at the PowerShell command to script both a FAST Query SSA and a SharePoint SSA, the likeness is pretty obvious.

New-SPEnterpriseSearchServiceApplication "Search SSA" -SearchApplicationType "Regular" -DatabaseServer "intranet.contoso.com" -DatabaseName "SearchApplicationDB" -ApplicationPool $AppPool

New-SPEnterpriseSearchServiceApplication "FAST Query SSA" -SearchApplicationType "Regular" -DatabaseServer "intranet.contoso.com" -DatabaseName "FAST Query DB" -ApplicationPool $AppPool

Both lines create a search application of type "Regular". The difference with the FAST Query SSA is five additonal PowerShell commands. First change the default search provider from SharePoint to FASTSearch.

Set-SPEnterpriseSearchServiceApplication "FAST Query SSA" -DefaultSearchProvider "FASTSearch"

Then set four extended properties, which associates the SSA with services on the FS4SP farm (included in the upgrade script at the end).

What this means is that you can take your existing search service application, change the default search provider, set the extended properties and your conversion is complete.

Any request from your old search center will have "Local Search Results" as the search location, and will get results from the SharePoint search index, while your new search center based on the FAST Enterprise Search site template will set the search location to "Local FAST Search Results" and the requests are redirected over to FS4SP.

Extended Query Properties before and after the "upgrade"

PS C:\> Get-SPEnterpriseSearchExtendedQueryProperty -SearchApplication "Search Service Application"

PropertyKey                               Value
-----------                               -----
FASTSearchContextProperties               SPS-Location,SPS-Responsibility
FASTSearchAdminServiceAuthenticationUser
FASTSearchAdminServiceLocation
FASTSearchQueryServiceLocation
FASTSearchContextCacheTimeout
FASTSearchManagedPropertyResultMapping
FASTSearchDisableUserContext
FASTSearchResourceStoreLocation
FASTSearchAlternateAccessMapProperties


PS C:\> .\upgrade_ssa.ps1
PS C:\> Get-SPEnterpriseSearchExtendedQueryProperty -SearchApplication "Search Service Application"

PropertyKey                               Value
-----------                               -----
FASTSearchContextProperties               SPS-Location,SPS-Responsibility
FASTSearchAdminServiceAuthenticationUser  comp\svc_spadmin
FASTSearchAdminServiceLocation            http://intranet.contoso.com:13257
FASTSearchQueryServiceLocation            http://intranet.contoso.com:13287
FASTSearchContextCacheTimeout
FASTSearchManagedPropertyResultMapping
FASTSearchDisableUserContext
FASTSearchResourceStoreLocation           http://intranet.contoso.com:13255
FASTSearchAlternateAccessMapProperties

Note that if you are using the KeywordQuery class in parts of your solution with the ResultsProvider property set to Default, you will have to change this to "SharePointSearch" if you want results from the SharePoint index and not FS4SP, as we changed the default provider with PowerShell.

Conclusion

You will still have to create the FAST Content SSA as per the FS4SP deployment documentation and migrate all your content sources and crawl rules from your existing SSA to the FAST Content SSA. But you don't have to schedule any downtime, and you can test both search solutions side by side before shutting down the old one.

Once you have results from FS4SP up and running you can delete all content sources except the sps3://server entry which has to be kept for people search to function.

Upgrade script

# upgrade_ssa.ps1
#
# The below script is based on a script found in "Microsoft® SharePoint® 2010 Administrator's Companion", but fixed for bugs.
# The port numbers used assume you are using 13000 as the FS4SP base port, and use http and not https for the query traffic.
# Edit $SrvName, $ResLoctV and $ssa to match your system

Function Set-FASTProp { 
param ($SSA, [string] $Cmd, [string] $Prop, [string] $PropValue) 
# Initialise $obj to Extended property object 
$obj = "SPEnterpriseSearchExtended" + $cmd + "Property"
$GetProp = &("Get-" + $obj) -Sea $ssa -id $Prop -ErrorAction SilentlyContinue
 
  if ($GetProp) 
  { 
    # Property exists 
    &("Set-" + $obj) -SearchApplication $ssa -ID $Prop -Value $PropValue 
  } else { 
    # Property does not exist 
    &("New-" + $obj) -SearchApplication $ssa -Name $Prop -Value $PropValue 
  } 
} # End of Function Set-FASTProp

$ssa = "Standard Search SSA"
$SrvName = "://intranet.contoso.com:"
$AdminUserV = "contoso\svc_spadmin"  
$QueryLoc = "FASTSearchQueryServiceLocation" 
$QueryLocV = "http" + $SrvName +"13287"
$AdminLoc = "FASTSearchAdminServiceLocation" 
$AdminLocV = "http" + $SrvName + "13257" 
$AdminUser = "FASTSearchAdminServiceAuthenticationUser" 
$ResLoc = "FASTSearchResourceStoreLocation" 
$ResLoctV = "http" + $SrvName + "13255"

Set-SPEnterpriseSearchServiceApplication $ssa -DefaultSearchProvider "FASTSearch"

Set-FASTProp $ssa "Query" $QueryLoc $QueryLocV 
Set-FASTProp $ssa "Query" $AdminLoc $AdminLocV 
Set-FASTProp $ssa "Query" $AdminUser $AdminUserV 
Set-FASTProp $ssa "Query" $ResLoc $ResLoctV
Categories: Search; Search and Indexing; FAST Search; Deployment

Comments

Wahid S

Well done!

Hi Mikael, This was an excellent presentation on how to quickly upgrade to FAST Search - many business really can't afford downtime. Thanks!

Posted 17-Oct-2011 by Wahid S
Michal Pisarek

Awesome

Awesome work Mikael! We have had a couple of client request just this scenario so its good to know that it can be done.

Posted 19-Oct-2011 by Michal Pisarek

Notify me of comments to this article

E-mail:
   

Add Comment

Title:

 
Comment:
Email:

   


Name:

 
Url: