Thursday, November 26, 2015

Gotcha’s when you move a FAST Search based solution to SharePoint 2013, running in 2010 mode

We’re running around like rabbits in my project these days migrating 2010 solution en-masse over to SharePoint 2013. Some are upgraded to the 2013 look and feel, while some heavy WSP based ones are kept in 2010 mode for the time being to keep cost down.

The 2010 farm is using FAST search and here’s a small list of things which will not necessarily work when you restore 2010 sites using Core Search Results web parts as part of the solution.

  1. Search index location for the web parts should be hard coded to FASTSearch, if it’s set to LocalSearchIndex or Default refiners will look and act weird. (See this post)
  2. If you have multiple web parts on a page, the ones set to use the non-default query id, will pick up the refiners from the default web part.
    imageAs an example image a result page which shows documents and people. You want to search for people and documents with the same query terms. When you click a refiner for documents, you do not want this to affect the people web part as those refiners might not exist. When setting a core result web part to use another query id, this just works in 2010, but when moving to a 2013 farm it does not.

    It’s solvable but you need to use some reflection like my FQL enabled web part (code at http://spsearchparts.codeplex.com/) which I wrote about in 2011. Need some pointers ping me :)

  3. If you have copied refiner URL’s like ?k=%2A&r=servicearea%3D%22ARIBVGVjaG5pY2FsIEFkdmlzb3J5C3NlcnZpY2VhcmVhAQJeIgIiJA%3D%3D%22, which have the FAST values base64 encoded in them, they will continue to work, but you might see double up of refiner values in the web part.
    image
    The reason for this is that the refinement value has changed format in 2013 and wraps the value itself in a hex encoded format, so we actually end up with a double encoding, and the web part will fail to highlight the correct entry.
  4. Metadata like O&G, which in FAST was stored just like that without spaces is tokenized into O & G with spaces in 2013. So if you have code filtering on properties with & in them you need to replace what the search filter looks like.

Summary

Migration is not necessarily easy, but fortunately for Microsoft not too many companies ever installed FAST (my guess), so the caveats on a migration to 2013 was no big concern. Also if customers spend the money to upgrade the UI’s to 2013, you would re-write everything anyways, and would not have to be concerned with all of this.

For this specific solution my initial migration estimate took a huge hit for sure, but the TCO was still lower digging into the weirdness, and I got to use some of my experimental code written for the FAST book.

That said, I hope this is the last time I ever ever ever ever ever have to touch FS4SP in a migration project again. I’m not a masochist by choice.

#FTW

Monday, November 23, 2015

People Search ranking for dummies

image

I’ve gotten a few questions about how people results are ranked in SharePoint/SharePoint On-line so I thought I would give a brief overview of two of the people ranking models available and how they work. I might be off on some points as decoding the models is not all that trivial as they have been created using machine learning and they also have multiple levels and use neural networks. If that sounded Greek or geek to you, then join the club :)

I’ll present my simplified interpretation and you can take it at face value.

For each model I will list the managed properties and associated user profile properties used in the rank profile, and list them in ranking importance from highest to lowest with my relative weights to put it into perspective.

User profile properties not listed in the tables will not influence how results are ranked.

Friday, November 20, 2015

Why Hybrid Crawl in SharePoint is a cold hot potato

image

[This rant is based on the preview of the Cloud Search Service Application]

Let me start by saying that I DO think hybrid crawl (or the Cloud Search Service Application) is a cool thing. It’s just the implementation of it which makes me go: Meh…..

When the Cloud SSA was first mentioned and further put into preview everyone was all YEAH!!!! WOW!!! AWESOMEPANTS!!!…..while I was quickly going… meh. What’s wrong with me?!?

To clue everyone in, hybrid crawl or the Cloud Search Service Application is a function where your on-premises SharePoint 2013 or 2016 farm can index local content (any source) and store it in the SharePoint Online search index instead of storing it in the local search index.

Monday, November 16, 2015

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.