In my previous blog post, Examining the new search core in SharePoint 2013, I attached a presentation on Slideshare. The first few slides summarized FAST’s product history, both before and after it was acquired by Microsoft. I also boldly stated that we’re seeing the “End of an era, the birth of a new age”. As cheesy as it may sound, at least from a technology perspective, I find this to be very true.

FAST Search and Transfer, the Norwegian company that sprung from the university in Trondheim, was founded as early as 1997. That’s a staggering 16 years ago. Even 4 years before the initial release of SharePoint.

Although it’s debatable when FAST initially entered the Enterprise Search market, the first release of FAST Data Search (FDS) was certainly a milestone. Much later, Microsoft acquired FAST and snapped up its hugely successful successor, the Enterprise Search Platform (ESP). It was later turned into the products FSIA/FSIS and also served as the backbone for FAST Search Server 2010 for SharePoint (FS4SP).

One thing that strikes me when reminiscing about FAST, is how the technology stack can be traced throughout its history. Many of the internal FAST processes we saw in FS4SP were actually already introduced back in FDS (of course in varying shape and form). But like I said in my last blog post, the idea that “FAST is now fully integrated” in SharePoint 2013 is just… well, wrong. The “technology trace” is now gone.

The figure below outlines FAST’s product history. As you can see, FS4SP was a merge between the FAST and the SharePoint worlds. And it showed. A Microsoft technician, who shall remain unnamed, once referred to it as the “bastard child of the two paradigms”. Although a little harsh – FS4SP was arguably a great improvement to the search-deprived SharePoint world – there was certainly some truth to it.

Eventually, with the arrival of SharePoint 2013, Microsoft released a well-tailored and cohesive search experience. But there was no longer an obvious technical inheritance from the earlier FAST product line, which is why SharePoint 2013 isn’t about having FAST “fully integrated”. It’s, simply put, a whole new platform. Of course with a few exceptions, e.g. some functionality from FSIS carried over to the new release. But generally speaking, we’re looking at a completely new platform, rewritten from the ground up.

In other words, the pre-MS technology is no longer around and the “technology trace” that we saw in earlier products is now cut off. Additionally, the “FAST” trademark has now slowly started the process of fading into obscurity.

All said and done, it’s only appropriate that FAST – the company, its technology and the trademark – is finally given a proper farewell. Without further ado, I give you its obituary: FAST, may you rest in peace, among friends in Enterprise Software heaven.

(Sorry, just couldn’t help but to shamelessly plug Comperio’s consulting services )

Let’s take it from the beginning. Using Best Bets, i.e. hard-wiring a certain result item to a particular search term, is a great way for Search Administrators to make sure end-users find what they’re looking for. Interestingly enough, there’s sometimes a slight contempt towards Best Bets in the technical community. Some people seem to think that the search solution’s relevance model should be able to stand on its own, and make sure the best results are always returned at the top of the results anyway.

But as a Search Administrator, if you could increase the perceived end-user experience a lot by a just a little manual (or semi-automatic) labor, wouldn’t you do it? Sure you would. One way of doing that is simply to look into the top X search queries in your query logs, and spend a few minutes on each search query and hard-wire a certain result item against it.

Anyway – we’re on the Technology section, so let’s get dirty.

In FS4SP, Best Bets are managed through the FAST Search Keywords page under Site Collection Administration. Adding a new one is easy: you start by creating a keyword, and then attach a Best Bet to it. Simple enough.

Let’s say you added the keyword “Comperio”, with the definition “Microsoft Search Partner of the Year 2011”. You then attached a Best Bet to it, linking to Comperio’s web site. With the minimal configuration, you’d end up with something like this:

Cool! You got yourself a Best Bet, and this is how they’re shown on the majority of FS4SP deployments out there. However, the Best Bet is not the only thing showing. The first star is showing the keyword itself, a long with its definition.

Let’s say you want to save some pixel real-estate, and decides that showing just the link is enough. At the Edit Keyword page, there’s no switch saying if to show the definition or not, but you can remove the text altogether from the text area shown below. That ought to do it!

Unfortunately, the result is not much better. We still get two stars, only now the keyword definition text is removed. The keyword itself is floating around by its own above the Best Bet – and not a single pixel was saved from vertical misery.

There’s no other setting on the FAST Search Keywords page to fix this – but there’s still a nice work-around. Enter PowerShell!

In an FS4SP shell, get hold of a Search Setting Group object corresponding to your Site Collection. If you only have one site collection, you can do:

$ssg = Get-FASTSearchSearchSettingGroup

If you have more than one, and haven’t named the group manually, pass in the id of your site collection to the the cmdlet’s –Name parameter. Running the two lines below in a SharePoint Management shell will print the id:

$site = Get-SPSite -Identity <a href="http://&lt;site collection root&gt;">http://&lt;site collection root&gt;</a>
$site.ID

When you’ve got hold of the search setting group, you can use it to view all internal information about the keyword:

PS C:\FASTSearch\bin> $ssg.Keywords.GetKeyword("comperio")
Synonyms        : {}
BestBets        : {Comperio}
FeaturedContent : {}
Promotions      : {}
Group           : Microsoft.SharePoint.Search.Extended.Administration.WCFClient.SearchSettingGroupImplWCF
Definition      : <DIV> </DIV>
Term            : comperio
LastChanged     : 1/27/2012 12:36:57 AM
Id              : 2

Looking at the Definition property, you’ll notice that’s it not actually empty at all – even though you’ve clearly removed all text from the definition text area. It contains the HTML entity for a non-breaking space wrapped in a <div> tag! Turns out that if you use the GUI to clear the definition, this is literally as empty you can make it. Even on a brand new keyword, without even specifying a definition. Bug or feature? I don’t know. But now knowing what the problem is, you can easily fix it for yourself by running:

PS C:\FASTSearch\bin> $keyword = $ssg.Keywords.GetKeyword("comperio")
PS C:\FASTSearch\bin> $keyword.Definition = $null

For the most part, Microsoft has done a great job integrating FAST into the SharePoint world, but there are certainly some areas where you notice there are actually two paradigms behind the scene: how things work in SharePoint, and how things (used to) work in FAST.

The primary key of the FS4SP index is one of those areas. In this post, I’ll try to make this a little more understandable.

First of all, the place where most people will notice that a primary key actually exists is in the crawl log on the FAST Content SSA.

Each indexed item is assigned an auto-incremented integer referred to as Item ID. All right, so let’s dig a little deeper.

If you’ve been reading up on FS4SP, you probably already know that there is an internal FAST-process called “qrserver”. It is responsible for receiving queries from the FAST Query SSA and internally forwarding the query to the actual index. You might also know that this process exposes a small web interface. For security reasons, it’s only available from within the server it runs on. More specifically: http://localhost:13280.

Searching for something here will return results in an internal XML format. The actual result items are listed under the <RESULTSET> tag a bit down in the XML. There are lots of things to talk about here, e.g. that the naming convention used internally in FAST is quite different to what is used when the results come back through the FAST Query SSA. A managed property for example, is referred to as a “field” internally. But let’s not fret over that now. Instead, let’s look at the first few properties of the first result:

After a few quick comparisons of the crawl log on the FAST Content SSA and the search results from the qrserver, it’s clear that the Item ID is stored in FS4SP’s index inside the property contentid. When comparing with the Item IDs listed on the FAST Content SSA, we also notice that SharePoint is prefixing the Item ID with “ssic://” when it’s stored in the index. In other words, the true primary key as used internally, is based on the pattern “ssic://[auto-incremented integer]”.

But as anyone who’s been using FAST pre-Microsoft can tell you, the contentid is actually not the primary key of the index. The real primary key is what’s stored inside the property internalid. The value of this property is the MD5 digest of the contentid, concatenated with the name of the content collection it is stored in. Let’s double-check, using our example. We had these two:

<FIELD NAME="internalid">8a832873c701c00135ce827d6c64c09c_sp</FIELD>
<FIELD NAME="contentid">ssic://33</FIELD>

Calculating the MD5 digest of the contentid correctly yields the internalid (sans the collection suffix):

md5(“ssic://33”) == “8a832873c701c00135ce827d6c64c09c”

Since the internalid is suffixed with the name of the collection, we can actually put several items with the same contentid into the index. The requirement being that they’re stored in separate collections, so that the concatenated internalid value becomes unique. In FS4SP however, we often use only the default “sp” collection. Luckily, SharePoint makes sure to assign the Item IDs so that they’re unique across all collections, hence creating unique internalid:s even though the items are in the same collection.

However, there are ways in FS4SP to index data without going through the FAST Content SSA, i.e. you can index data without letting SharePoint know about it. This happens when you’re using any of the FAST Search specific connectors or the command-line tool docpush. These tools talk directly with the index, bypassing SharePoint completely. Thus, the content id item won’t be assigned an Item ID using the “ssic://” pattern.

So, what happens instead? Let’s try it out. Using the docpush tool, we can send an arbitrary web page into the index:

Using the qrserver web interface, we inspect what was indexed:

In this case, the contentid property is the URL of the web page we specified. This makes sense as the URL is unique for the whole web, and as such it is also a good candidate for being a primary key in the index. A URL is just a special case of a URI, which is what many of the FS4SP command-line tools use when referring to the primary key of the index. Examples being the docpush tool (when deleting a item from the index with the –d switch) and the waadmin tool (used for retrieving link cardinality data for an indexed item).

To sum up with some key points:

• The primary key of the index is stored in a property called contentid, though in the SharePoint GUIs it is referred to as an Item ID and look slightly different. They relate to one another as: [contentid] = ssic://[item id]
• Items that are indexed using the connectors of the FAST Content SSA are assigned a contentid on the form “ssic://”…
• Items that are indexed with the FAST Search specific connectors or the docpush tool do not follow the same pattern, but are typically a proper URL or a value from a database.
• If a command-line tool calls for a “URI” to an indexed item, use whatever is stored in the item’s contentid property.

The video is 70mins long and roughly divided into three sections: 1) the challenges you face as an implementer (quite interesting), 2) the nuts and bolts of how you overcome this, and 3) Some real life examples. At the end of the presentation I showcase some really nice SharePoint search front-ends that Comperio made for Microsoft a few months ago.

How do you make great UX? What can be done to make your Fast Search For SharePoint application a joy to use? Can Scottish people make themselves understood to Americans? What tips would you give the up and coming UX designer?

But even if you do, you may have noticed that the FAST Search Web crawler is still turned on behind the scenes (on a default single-node installation). The Node Controller, i.e. the “nctrl” tool that handles FS4SP internal processes, is set to automatically start the Web crawler and its associated processes by default. In this blog post, we’ll circumvent this in order to gain some insight into the inner workings of the Node Controller.

Run a “nctrl status”, and you will see all running FS4SP-processes:

The processes in red are all related to the crawler:

crawler
The main component of the FAST Search Web crawler.

browserengine
A component which emulates a real web browser, and makes sure the crawler “see” what a regular user see while browsing the web.

webanalyzer, fdmworker, walinkstorereceiver, walookupdb0
Components of the Web Analyzer, which calculates a link graph of the crawled content. This data can be used for ranking purposes (compare to Google’s PageRank algorithm). Please note that the Web Analyzer is also used for relevance calculations in SharePoint crawls – and not only for crawled external web content.

If you don’t plan to use the FAST Search Web Crawler, and don’t care for the output from the Web Analyzer module, you can shave off something like 50-200 MB of RAM usage by stopping these processes. Although it’s an easy operation, don’t do this unless you understand the steps involved, the consequences, how to roll back the changes, and most importantly: that you now tread into unsupported and undocumented waters. Also, even though I and a few other people have tested this without running into problems, it’s impossible to guarantee that your particular configuration is unaffected. But at the very least, please read on to gain some insight into how the Node Controller works.

If you still want to disable the FAST Search Web Crawler, stop all crawler-related processes by running the following command in a FS4SP shell:

nctrl stop browserengine crawler fdmworker walinkstorerreceiver walookupdb0 webanalyzer

Running “nctrl status” will now show you this:

As the crawler processes are now in the “User suspended” mode, they will remain suspended even after a full restart of FS4SP.

If you like, you can go even further and clean up the output of “nctrl status” by removing the now disabled processes from the list altogether. To do this, open up the Node Controller’s configuration file, i.e. %FASTSEARCH%\etc\NodeConf.xml. At the top, you will see something like:

<startorder>
  <proc>nameservice</proc>
  <proc>configserver</proc>
  <proc>contentdistributor</proc>
  <proc>indexer</proc>
  <proc>search-1</proc>
  <proc>topfdispatch</proc>
  <proc>samworker</proc>
  <proc>samadmin</proc>
  <proc>qrserver</proc>
  <proc>qrproxy</proc>
  <proc>indexingdispatcher</proc>
  <proc>browserengine</proc>
  <proc>fdmworker</proc>
  <proc>walookupdb0</proc>
  <proc>walinkstorerreceiver</proc>
  <proc>webanalyzer</proc>      
  <proc>sprel</proc>
  <proc>spelltuner</proc>
</startorder>

Comment out all crawler-related processes, like this:

<startorder>
  <proc>nameservice</proc>
  <proc>configserver</proc>
  <proc>contentdistributor</proc>
  <proc>indexer</proc>
  <proc>search-1</proc>
  <proc>topfdispatch</proc>
  <proc>samworker</proc>
  <proc>samadmin</proc>
  <proc>qrserver</proc>
  <proc>qrproxy</proc>
  <proc>indexingdispatcher</proc>
  <!--
  <proc>browserengine</proc>
  <proc>fdmworker</proc>
  <proc>walookupdb0</proc>
  <proc>walinkstorerreceiver</proc>
  <proc>webanalyzer</proc> 
  -->    
  <proc>sprel</proc>
  <proc>spelltuner</proc>
</startorder>

Save the file, and then issue the command “nctrl reloadcfg” to make the Node Controller pick up the changes. All processes you commented out are not stripped from the “nctrl status” output. But the “crawler” process remains, indeed it was not listed under the <startorder> tag that you just edited. This is because the crawler is administered through the “nctrl” tool itself, and not through its configuration file. Run “nctrl remove crawler” to get rid of it as well.

Your status output should now look like the below. Nice and clean!

Of course, turning off functionality like this is an advanced operation – not recommended to most users. However, even though you don’t want to do this yourself, at least you’ve now gained some insight into how FS4SP’s Node Controller works. With a little imagination and extrapolating you can now even add your own custom applications to the Node Controller, and make sure they are started alongside FS4SP. Let me know if you have any questions, or run into problems.

Update:

If you’re serious about getting rid of the FAST Search Web crawler, Mikael from Tech and Me kindly pointed out an alternative strategy for disabling it: change the deployment.xml accordingly, and run the Set-FASTSearchConfiguration cmdlet. This will however require you to shut down FS4SP (nctrl stop), which is not necessary using the above procedure. But it’s arguably a cleaner approach for getting rid of the crawler. TechNet has more information about deployment reconfigurations in general. Please note that this will overwrite your %FASTSEARCH%\etc\NodeConf.xml – editing it manually is unsupported after all.

Microsoft offers three different flavors of search for SharePoint 2010: Foundation, Standard and Enterprise. For each level upwards you get more feature and better search capabilities. One of the visual features included with FAST for SharePoint is Thumbnails and Previews for the search results, as listed on the comparison table below (Compare SharePoint Editions – Search).

Wouldn’t it be nice to have this feature on all versions of SharePoint? I will tell you how, as I demonstrated in a proof of concept talk at Arctic SharePoint Challenge 2011.

The Thumbnail and Preview feature is depending on Office Web Apps, which is an additional module you can install on all versions of SharePoint 2010 in order to get web based editing capabilities of Office documents (Word, Excel, PowerPoint and OneNote). Office Web Apps itself is free, but requires Volume Licensing for Microsoft Office 2010.

The API’s used for generating the thumbnails and the PowerPoint previews are the Office Mobile PowerPoint Web Handler Protocol and the Office Mobile Word Web Handler Protocol, both included with Office Web Apps. These API’s include functions to retrieve generated images of the documents as well as functions to retrieve the textual content within the documents. The API works for doc, docx, ppt and pptx files (Office 97-2010 formats).

The Word API is limited to generating a thumbnail for the first page in your document, while the PowerPoint API can generate an image of any slide as seen below.

If you have installed the Enterprise version of SharePoint you have the possibility to create a new Search Center based on the “FAST Search Center” template, even though FAST is not installed.

The FAST Search Center template features XSLT in the Core Results Web Part which renders javascript calls to functions in a file called search.js located in the _layouts folder. Search.js further implements the communication with the mobile API’s to generate the images.

There are quite a few lines of javascript to implement this feature, but if you are a bit experienced with javascript and ajax programming you would be able to program this feature yourself. This will allow you to get thumbnails and PowerPoint previews with any version of SharePoint, from the free Foundation version to the Enterprise version.

If you are less handy with javascript you can copy out the XSLT used in the Core Results WebPart in the FAST Search Center site template, modify it some, and use it with a search site based on the “Enterprise Search Center” template instead. This way you will get additional visual improvements to the standard search page without having to install FAST.

The quick way is to replace some of the xsl:params set by the web part with pre-set variables instead. If you have FAST installed, then the parameters will be set via the Core Results Webpart. As we are using the oob search we have to set these parameters as variables instead.

<xsl:variable name=“OpenPreviewLink“ select=“‘Preview’“ />

<xsl:variable name=“ClosePreviewLink“ select=“‘Close Preview’“ />

<xsl:variable name=“ThumbnailTooltipLoadingFailed“ select=“‘Loading failed!’“ />

<xsl:variable name=“ThumbnailTooltipLoading“ select=“‘Click to toggle preview’“ />

<xsl:variable name=“AAMZone“ select=“0“ />

<xsl:variable name=“PreviewWindowSize“ select=“160“ />

<xsl:variable name=“EnableDocumentPreviewPowerPoint“ select=“‘true’“ />

<xsl:variable name=“EnableDocumentPreviewWord“ select=“‘true’“ />

<xsl:variable name=“ConcurrentDocumentPreview“ select=“10“ />

<xsl:variable name=“TotalDocumentPreview“ select=“10“ />

I also had to modify the xslt two more places. Around line 665 and line 725 locate the FST_CheckForPreview call and change the function parameter

‘<xsl:value-of select=“sitename“/>’

with

‘http://rootsite’

where rootsite is the name of your SharePoint server url.

This was to ensure the calls to the Mobile API went to the top level site, as they failed when called on sub-site url’s.

That being said, there are several other good reasons for deploying FAST for SharePoint in your organization besides these visual enhancements. Capabilities to enrich and modify your content prior to indexing, thus tailoring search experience towards the real needs of your users, as well as the powerful query capabilities offered via FAST Query Language are just a couple of arguments for choosing FAST.

But then again, it never hurts to have moderate amounts of eye-candy on your search page, as it will increase the perceived quality of the results.

flickr.com/theredproject

Technology has no inherent business value. Technology doesn’t provide improved findabiliy, decision-making or knowledge management by itself. Technology just provides features that help users perform tasks, thereby reaching their goals. Only when user goals and business goals align, can you hope to create business value. Without people, there is no purpose – and without purpose, there is no value.

Enterprise search technology is no different from the rest in this respect. In fact, I know only 3 good reasons for investing in search technology.

Spending time and money on an enterprise search platform like FAST Search For SharePoint (FS4SP) may be a good idea if you believe the success of your business depends on:

1. Consolidation of information from different data sources and formats.
2. Content refinement and entity extraction.
3. Linguistic processing and advanced querying capabilities.

There is of course more to search than this, but these features are in my opinion the hallmarks of FS4SP and the old FAST ESP – what enterprise search does better, faster and with higher tractability than any other available technology. Search is by no means the only way to access information, and similar technologies (like data warehouse, ETL and topic maps) will let you do similar things, each having their own particular strengths and weaknesses.

The true value of enterprise search technology is not bound to fair promises of improved efficiency and profitability, but to the marvels it can do in the hands of brilliant engineers – without requiring any prior knowledge of the context of use. Business value is only attainable when technological capabilities form a higher unity with user needs and business goals through cross-diciplinary user-centered design.

The success of your business may depend on improved findability, decision-making and knowledge management, and that is the true value of designing the user experience of search.

Note: this post is cross-posted at Things On Top.

Instead of having a deployment script creating your properties, you could have an event receiver which creates your mappings once a site or list is provisioned. Or when some other action is going on.

So how do you go about doing this?

Well, first off Crawled and Managed Properties for FAST are a part of the index schema and is accessible via the following two namespaces:

Microsoft.SharePoint.Search.Extended.Administration Microsoft.SharePoint.Search.Extended.Administration.Schema

which are the namespaces used for working with the FAST components.

Below is a quick example showing how this can be done in code, with comments along the way to guide the process. It’s all pretty straight forward.

const string propertyName = “productname”;

// Get a reference to the Index Schema via the SchemaContext class

SchemaContext schemaContext = new SchemaContext();

Schema schema = schemaContext.Schema;

// Assign a guid to the custom Crawled Propery Category

Guid myGuid = new Guid(0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1);

Category catGroup;

// Create if it does not exist

if (!schema.AllCategories.Contains(myGuid))

{

catGroup = schema.AllCategories.Create(“My Crawled Properties”, myGuid);

}

else

{

catGroup = schema.AllCategories[myGuid];

}

// Create a new crawled property if it doesn’t exist

CrawledProperty cp = catGroup.GetAllCrawledProperties().Where(

c => c.Name == propertyName && c.VariantType == 31 && c.Propset == myGuid).FirstOrDefault();

if (cp == null) cp = catGroup.CreateCrawledProperty(propertyName, myGuid, 31);

// Create a new managed property if it doesn’t exist

ManagedProperty mp;

if (!schema.AllManagedProperties.Contains(propertyName))

{

mp = schema.AllManagedProperties.Create(propertyName, “”, ManagedType.Text);

}

else

{

mp = schema.AllManagedProperties[propertyName];

}

// Create a new crawled to managed property mapping if it doesn’t exit

CrawledPropertyMapping mapping = mp.GetCrawledPropertyMappings();

if (!mapping.Contains(cp))

{

mapping.Add(cp);

mp.SetCrawledPropertyMappings(mapping);

}

// Get a reference to the default full text index (first one)

FullTextIndex fti = schema.AllFullTextIndecies.First();

// Get the full text index mapping from the Managed Property

FullTextIndexMappingCollection fullTextIndexMappingCollection = mp.GetFullTextIndexMappings();

FullTextIndexMapping indexMapping =

fullTextIndexMappingCollection.Where(ftpMap => ftpMap.FullTextIndex.Name == fti.Name).FirstOrDefault();

// Set a mapping to importance level 6, if it’s not already set to something else

if (indexMapping == null || !fullTextIndexMappingCollection.Contains(indexMapping))

{

fullTextIndexMappingCollection.Create(fti, 6);

}

With FS4SP,  these query suggestions are automatically created over a period of time based on how often the users search for a specific query within a certain timeframe. Sometimes, it can however make sense to modify the query suggestions manually – and to help us do that, we can always lean on PowerShell.

The script I have implemented, has the following parameters:

.\QuerySuggestions.ps1 -file [fileName] -action [add|delete] -queryssa [querySSAName]

where file is the file with the query suggestion phrases (one per line), action decides if the query suggestions should be added or deleted, queryssa is the name of the Query SSA. And now for the actual code.

#Get input
param
(
    [string]$file,
    [string]$action,
    [string]$queryssa
)

function LoadQueryCompletion()
{
    # Read input file with stuff that you should add to the Query suggestion list
    if (test-path $file)
    {
        log VERBOSE "Reading file: $file"
	$input = Get-Content $file
    }
    else
    {
        log ERROR "File noe found. Exiting script."
        exit 1
    }
    # Get SSA search application
    $searchapp = Get-SPEnterpriseSearchServiceApplication -Identity $queryssa

    # Populating a dictionary with the query suggestions that have already been added before
    $query_suggestions = Get-SPEnterpriseSearchLanguageResourcePhrase -SearchApplication $searchapp -Language En-Us -Type QuerySuggestionAlwaysSuggest
    $already_dict = @{}
    foreach ($term in $query_suggestions)
    {
        if (!$term){ continue }
        $already_dict.Add($term.Phrase,$term.Phrase)
    }

    if ($action -eq "add")
	{
	    foreach ($entry in $input) {
	        if ($already_dict.ContainsKey($entry))
	        {
	            log WARNING "Key already added: $entry"
	        }
	        else
	        {

			try {
				log VERBOSE "Adding entry ($entry) with language En-US"
			    	$nooutput = new-spenterprisesearchlanguageresourcephrase -SearchApplication $searchapp -Language En-Us -Type QuerySuggestionAlwaysSuggest -Name $entry
				$already_dict.Add($entry,$entry)
			}catch {
				log ERROR "Could not add entry ($entry). Exiting script."
				exit 1
			}
	        }
	    }
	}
	elseif ($action -eq "delete")
	{
		foreach ($entry in $input) {
			try {
				if ($already_dict.ContainsKey($entry)) {
					log VERBOSE "Removing entry ($entry) with language En-US"
			    	        $nooutput = remove-spenterprisesearchlanguageresourcephrase -SearchApplication $searchapp -Language En-Us -Type QuerySuggestionAlwaysSuggest -Identity $entry -Confirm:$false
					$already_dict.Remove($entry)
				}else{
					log WARNING "Entry ($entry) has not been added as a query suggestion"
				}
			}catch {
				log ERROR "Could not remove entry ($entry)."
			}
	    }
	}
	else
	{
		log ERROR "-action parameter contains an invalid value. Exiting script."
	}

    #Run timerjob manually to upload entries from DB
    Start-SPTimerJob -Identity "prepare query suggestions"

    log VERBOSE "Finished loading query completion phrases."
}

#Main
$spInstalled = Get-PSSnapin | Select-String Sharepoint
if (!$spInstalled)
{
    Add-PSSnapin Microsoft.Sharepoint.PowerShell
}
LoadQueryCompletion

If you want to include the logging output , add this to the top of the PowerShell script.

# Log level to color mapping
$lc = @{
	VERBOSE="green";
	WARNING="yellow";
	ERROR="red";
	MESSAGE="blue";
}
function log([string] $level, [string] $message) {
	$date = get-date -uformat "%G-%m-%d %T"
	write-host "[$date] " -nonewline
	write-host -foregroundcolor $lc[$level] $level.padright(7) -nonewline
	write-host " $message"
}

If you’re really picky (like me), you should also consider having some kind of validation on the input parameters. For instance verifying that the file exists, that the action parameter contains a valid value, and that the Query SSA exists. You can check the last-mentioned by adding the following lines of code to the script.

$ssaExists = Get-SPEnterpriseSearchServiceApplication | Select-String $queryssa
if ($ssaExists -eq $null)
{
	log ERROR "-queryssa is invalid. Search Service Application does not exist. Exiting script."
	$queryssas = Get-SPEnterpriseSearchServiceApplication | Where-Object {$_.DefaultSearchProvider -eq "FASTSearch"}
	foreach ($queryssa in $queryssas)
        {
		if ($queryssa)
    	    	{
    			$name = $queryssa.Name
    			log VERBOSE "Found the following Query SSA: $name"
    	    	}
        }
}

After doing that, you should be ready to run the script on the SharePoint Admin server.

Afterwards, go to your FAST Search Center, and start typing one of the terms you have added. The result can look something like in the screenshot below.

You can read the article over at SharePoint Magazine, and if you like it feel free to click the Facebook Like button at the end.

The other two finalists are:

“Best Practices for SharePoint Groups” by Josh McCarty and “A Guide to Leaving Lotus Notes and Moving to Microsoft SharePoint” by Andrew Vevers.

And if you are serious about search within SharePoint, go FAST!