I recently setup FAST Search Server 2010 for SharePoint 2010 and here are the documented steps:

 

• FAST Search Server was installed on a dedicated server different from SharePoint 2010 server.

• FAST Server was not installed on a domain controller.

• FAST Server was patched with latest windows update and windows update service was running.

• Used the Pre-requisite installer for FAST Server 2010 (available on the installation media) to install all required components for FAST Server 2010

• Identify the user who is running the Microsoft SharePoint 2010 Timer Service (you will need this account to provide handshake between SharePoint 2010 Server and FAST 2010 Search Server)

• Configuring SSL enabled communicate is required when you setup Content SSA.

• Followed all step by step instructions mentioned in TechNet

 

Here are the high level steps that I followed from the article:

 

• Enable PowerShell scripts to run.

• Install FAST Search Server 2010.

• Configure a single server deployment.

• Setup the Content Search Service Application (SSA) – Content SSA is responsible for crawling content and feeding it into FAST Server for SharePoint back-end.

• Setup the Query Search Service Application – Query SSA fetches query results from the content that is crawled by the Content SSA.

• Configure claims authentication.

 

Once all the above steps are configured, check whether all FAST Search Server services are running by typing the following PowerShell command using Microsoft FAST Search Server 2010 for SharePoint shell

nctrl status

You should see the output as shown in the screenshot below

 

Next step, is to Test FAST Search Server 2010 for SharePoint (TechNet article has all the detailed steps)

On your SharePoint 2010 server, check the association between FAST Query SSA and your web application by clicking on “Configure service application associations” available under “Application Management”. You can see “FAST Query SSA” associated with my web application below

 

Once the association is complete, perform a search query and you will see FAST Search server in action (assuming you have crawled the content sources using FAST Query SSA)

This screen shot shows the Crawl History for FAST Query SSA

 

 

 

Search query results using FAST Query SSA

 

Check out the refinements search on the left (Result Type, Site, Date)…  Pretty cool… right?

I was going through the steps of deleting content db using stsadm (as you know it does not delete the content database from SQL Server, but just removes the reference from SharePoint perspective) and using stsadm –o addcontentdb to attach a content database from production to development server for testing purposes. Once the stsadm –o adcontentdb operation was completed successfully, I went into Manage Content Databases section and noticed the Current Number of Sites was set to 0.

 

To confirm that the content database had some valid entries for webs and sites, I queried the following tables

select * from Sites with (nolock)

and then the webs table

select * from webs with (nolock)

 

The query results showed entries existed in the sites table as well as the relevant webs table. After further troubleshooting, the issue was caused by GUID conflicts in SQL Server. I had restored the same content database from production to development server few months back for some other testing purpose to a different web application. Although this was a brand new web application that I had created, the GUID conflict still occurred and that is the reason the number of sites was set to 0. So, to ensure that the restore process was clean, I started the restore process again on SQL Server, executed stsadm –o deletecontentdb for the new web application I had created followed by stsadm –o addcontentdb pointing to the new database restored.

Now, if you have a question, so how do I maintain 2 copies of the same content database in production in this scenario without GUID conflicts? You can use stsadm backup and restore (or) content deployment. I did try with stsadm backup and restore and the process was successful.

Hopefully, this post will save you some time next time you encounter a similar situation.