Inconvenient SharePoint 2010 search center in 2013 (Hey Waldek :)

I’m currently working on moving some 2010 farms over to a 2013 farm, and when doing so we decided to keep the 2010 UI for some of the custom solutions for the time being. The 2010 solutions used FAST search, and this is where the inconvenience hit us.
When using FAST in 2010 and you click a refiner, you will see a weird encoded URL parameter similar to

r=knowledgeportalsegment%3D%22ARMBU3Vic2VhIGFuZCBGbG9hdGVycxYBa25vd2xlZGdlcG9ydGFsc2VnbWVudAAcAiLHgseCNTM3NTYyNzM2NTYxMjA2MTZlNjQyMDQ2NmM2ZjYxNzQ2NTcyNzMi%22

which after migration looked like the plain readable non-FAST 2010 version:

r=knowledgeportalsegment%3D%22Subsea%20and%20Floaters%22

In addition to the change of URL format for a refiner multi-term taxonomy fields where being rendered together with a semicolon separator instead of as multiple refiner entries.


One of the search solution were also executing some extra queries behind the scenes in a custom web part using the KeywordQuery object, and adding refiner values to the query. The values passed into the KeywordQuery query object has to be sent in via the encoded form, and not the plain text form, in order to work (all mentioned in my FAST 2010 book at page 360+  ;)

Long story short: In the original solution the Location property of the Core Search Results Web Parts had not been explicitly set to FASTSearch, and once migrated it thinks it’s using the old SharePoint way of searching. As a dev I know this is not true as FAST has been integrated into SharePoint 2013.

Once all the web parts had been explicitly set to use FASTSearch as the index, which in the UI reads as Local ESS_MINIMAL_NAME_RTM Results, it works as expected.




To sum it up. For all 2010 mode search web parts being used in SharePoint 2010, make sure the .webpart Location property is set to FASTSearch. and for the KeywordQuery object, set the ResultsProvider provider to SearchProvider.FASTSearch;