Why you still should prefer PowerShell over UI to create Search Scopes in FAST for SharePoint

When SharePoint 2010 came out the only way to create a search scope was to do it by PowerShell. Well, you could create the scope name itself via Central Admin, but the actual scope filter had to be done via PowerShell.

Using FFDDumper to log items in a custom pipeline with FS4SP

In my previous post How to "spy" the data in a custom pipeline extensibility stage with FS4SP I explained how to use the undocumented Spy stage to view all crawled properties available in the pipeline.

There is also a documented way to log all content called FFDDumper which executes as the first step in the processing pipeline.

You enable this stage by editing C:\FASTSearch\etc\config_data\DocumentProcessor\optionalprocessing.xml.

Microsoft Virtual Labs for Search

Interested in learning more about how to develop great search solutions and what SharePoint 2010 can offer in terms of search capabilities?

Head over to the SharePoint Server Virtual Labs page at MSDN and check out the newly released labs on search.

The labs are virtual machines accessed via your browser and are accompanied by a script to walk you thru the exercises.

Note that some of the labs seem to be missing indexed content, so you might need to kick off a crawl before starting. The machines are also quite slow, and you might have better luck running the “2010 Information Worker Demonstration and Evaluation Virtual Machine” locally instead. It’s more or less the same machine as provided in the labs.

Prototyping pipeline stages in PowerShell

The defacto way of creating a custom pipeline stage in FAST for SharePoint is to create an executable file which reads and writes an xml file. This usually implies having Visual Studio available and compiling and deploying a new file each time you make a change in order to test it in a proper pipeline.

To the rescue comes PowerShell. Since all FAST servers have PowerShell installed you can create a PowerShell script and use this. All you need is notepad This gives the flexibility of trying out stuff without recompiling. But the cost is speed of execution. So you might want to port the code over to e.g. C# when you are done testing your code.

How not to name a configuration setting

Recently while looking over some FAST for SharePoint labs one of the exercises had you edit a property called:

AllowNonCleanUpClaimsCacheForTestingOnly.

The production setting for this is “false”, which will make the system do cleanup of a claims cache.

But reading the name and what it actually does is very hard due to using both the words “Allow”, “Non” and “TestingOnly”. You have a positive word, a negative word and a specific case where the property is valid, all in the same name.

The proper name for this should in my opinion be:

CleanUpClaimsCache

where the production value should be “true”. With a comment to explain why you would set this to false, e.g. in a test scenario.