I’ve been doing a fair bit of FAST search configuration and re-configuration lately, and I just wanted to point out a few things that are good to know and understand.

Let’s start with some basics. If you use the following guide for configuring FAST (and I usually do) http://technet.microsoft.com/en-us/library/ff381243.aspx, then you should be aware of:

• You configure two service applications for FAST: FAST Content and FAST Query SSA. FAST Content is a FAST Search Connector. FAST Query SSA is FAST Search Query.
• The FAST Content service application is where you configure your Content Sources and crawl MOST content. Please note that I say MOST and not ALL. Your user profiles or ‘People’ search, are crawled using the FAST Query SSA.
  
  Please reference this article for details: http://sptechland.wordpress.com/2010/10/08/fast-people-and-content-search/. This is a key thing to understand, because until you initiate a crawl for the Local SharePoint sites Content Source in the FAST Query SSA, you won’t see any people results in the People scope.
• If you’re trying to figure out HOW to crawl your user profiles, make sure that the following url is added to your FAST Query SSA – Local SharePoint sites Content Source: sps3://serverurl.

Some other things I’ve noticed:

• My scopes in the FAST Query SSA service application don’t accurately display the number of items in each scope. I haven’t gotten to the bottom of this yet.
• My Content Distributor port as recorded in the Install_Info.txt was not accurate. Read more here: http://blog.qumsieh.ca/2011/08/02/error-unable-to-resolve-contentdistributor/
• There is a neat codeplex tool for querying your FAST farm to test search results. http://fastforsharepoint.codeplex.com/

And finally, if you come across this error:

The search service is not able to connect to the machine that hosts the administration component. Verify that the administration component ’43fa5edd-3e14-4dba-b54c-7aad045dfdf7′ in search application ‘FASTContent’ is in a good state and try again.

Run the following command:

stsadm -o provisionservice -action start -servicename osearch14 -servicetype "Microsoft.Office.Server.Search.Administration.SearchService, Microsoft.Office.Server.Search, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"

I thought I’d do a quick post for the visitors of my blog on a new initiative by SharePoint Nick called SharePoint Weekly.

So what is SharePoint Weekly. Well, as Nick describes it, it’s “a free, once weekly email round up of SharePoint news and articles.” If you’re like me at all, you really struggle with keeping up to date with all that goes on in a given day surrounding SharePoint. It’s so overwhelming at times, that I could easily spend my entire day reading through blogs and new content just to keep up with it all. I could repeat this every single day, that’s how quickly evolving this community is! At Black Ninja, we’re a bit unique, because we run an Apple shop, using VMWare Fusion to drive our Windows/SharePoint VMs and we are heavy into iOS and Ruby on Rails development. We’ve come to really love and absolutely rely on the weekly updates available in the iOS, Ruby on Rails and Javascript communities. I feel in some ways, the SharePoint side has been lacking a bit when it comes to this type of service.

For example, on the Ruby side, we have so many wonderful weekly podcasts and round ups for content. We’ve even sponsored some of them:

• Ruby5 – Great 5 minute round up of all things Ruby for the week.
• Ruby Weekly – Another great example, and very similar to the SharePoint Weekly format.
• Javascript Weekly – Weekly updates on the javascript world.

I’m a huge fan of this idea, and I’m sure Nick would appreciate any feedback or ideas the community might have on making this service even better. I’m open to supporting it in anyway we can as well. I think what would also be interesting to see is if the SharePoint Weekly concept will need to be broken down further into different categories, such as SharePointDevWeekly, or SharePointAdminWeekly, etc.

So take a minute and sign up here: http://www.sharepointweekly.com/

Thanks Nick for taking the time out to set this up and maintain it weekly.

We’ve recently upgraded a server farm from SharePoint 2010 Server Search to SharePoint 2010 FAST Search and ran into a couple of issues with getting the content sources crawled correctly.

Scenario: We have a 2 server farm: a single application server, and a WFE. There is a separate SQL Server installation where we host our databases. FAST was installed on the application server, which it’s worth mentioning, was already running SharePoint 2010 Server Search successfully.

After going through the steps for installation, what we’ve got configured are two NEW service applications and one old one:

1. FAST Search Connector
2. FAST Query SSA
3. Search Service Application 1 – to be deleted once FAST was configured correctly

FAST Search Connector is where we configure our content sources. In the case of the SharePoint content source that we had configured, a full crawl was generating several warnings and errors, but not a single success message. Something was not right.

Checking into the event logs, I found Event ID 2567.

Failed to connect to VCVANKMSSEARCH1.vci.local:13391 Failed to initialize session with document engine: Unable to resolve Contentdistributor

The issue for us was an error in the port listed for the Contentdistributor. Note: for those of you who did not install FAST personally, and need to know what settings were inputted during installation, you’ll find them in the root of the installation folder where FAST was installed.

\\FASTInstallationFolder\Install_Info.txt

Open the above file up, and locate the following configuration section:

---------------------------------------------------------------
 
FAST Search Content Search Service Application configuration
 
---------------------------------------------------------------
 
Content Distributors (for PowerShell SSA creation):   servername:13391
 
Content Distributors (for GUI SSA creation):          servername:13391
 
Default Content Collection Name:                      sp

Notice the port number. Now navigate to:

\\FASTInstallationFolder\etc\contentdistributor.cfg

When viewing the contentdistributor.cfg file, I was able to see that the port number was different from what was specified during installation. It was in fact set to 13390. So by looking at this setting, we know that the FAST Search Connector is going to be configured incorrectly as well.

Open Central Administration, Manage service applications. Click on the FAST Search Connector and select Properties in the Ribbon. Scroll down to the Content Distributors section and change the port number from 13391 to 13390.

In our case, I deleted and recreated the content source, and now the success messages are pouring in and search results are coming back. As always, I would love to know why the port for the Content Distributors was configured differently from what was specified during installation, but unfortunately I do not have the answer to that. If anyone does, ping me and I’ll update this post.

It’s also worth noting that now that my search results are being returned, I am still seeing Event ID 2567 pop up in the logs, and am currently investigating this. Also on my radar are several Timer errors: Event ID 6398 – Failed to communicate with the WCF service.