FAST Search – Repair or Rebuild your Corrupt Index from FIXML?

The FAST Search environment is a robust search solution for your SharePoint environment and once it is configured correctly and optimized then it will purr in the background surfacing rich search results for your users. However, on the rare occasion that your index gets corrupted, you as a SharePoint administrator will need to be aware of the tools and methods you can use to get it working again. If anything else, this should be part of your recovery procedure for your SharePoint environment.

So what options do you have when your index gets corrupted? Well, firstly you could completely delete the Index from SharePoint in the Search administration and via powershell on your FAST Search admin server. Or if you’re Index will take too long to re-build and will not meet your SLA then you can recover your Index using the FIXML. When FAST Search for SharePoint is indexing items it not only stores the physical index itself in the location ‘%drive%\FASTSeach\data\data_index’ but it also stores each indexed item in the FIXML in the location ‘%drive%\FASTSearch\data\data_fixml’. The FIXML contains all the information which is to become that item in the index.

Now that we know we can use the FIXML, there are two options available to you that are detailed below.

Option A – Repair a corrupt Index from FIXML

This process can be performed from any FS4SP server and on any column or row. The index reset does not rebuild the column from scratch, the indexer validates each item within the FS4SP column against the original FIXML. Any item not in sync or corrupt will be updated in the column / index.

1. Ensure all crawls are stopped in Search Administration and the FS4SP column is idle. Use the powershell command below to show the status of FAST Search.

</p><p>Indexerinfo --row=0 --column=0 status
</p><p>

1. Stop the web analyser and relevancy admin processes.

</p><p>Waadin abort processing
</p><p>Spreladmin abortprocessing
</p><p>

1. Issue an Index Reset. You can re-run the second command to monitor the status or check the indexer.txt file in the logs directory (FAST Search\var\log\indexer).

</p><p>Indexeradmin --row=0 --column=0 resetindex
</p><p>Indexeradmin --row=0 --column=0 status
</p><p>

1. Once the repair is complete, you can then resume the web analyser and relevancy admin.

</p><p>Waadin enqueueview
</p><p>Spreladmin enqueue
</p><p>

Your FAST Search Index will now be repaired and will be operational.

Option B – Rebuild an Index from XML

Ok, so you attempted Option A and this didn’t resolve your issue and your index is still corrupted. The next step is to rebuild the index from your fixml. Rebuilding the index requires a lot more disk space than option A as temporary files are created and released (within FAST Search directory) which means you are likely to consume twice as much disk space. If the disk space gets to 2GB of free space then the rebuild will fail so you will need to manage your disk space. Follow the steps below to complete this task.

1. Ensure all crawls are stopped in Search Administration and the FS4SP column is idle. Use the powershell command below to show the status of FAST Search and keep a note of the entries “document size” and the “indexed=0”.

</p><p>Indexerinfo --row=0 --column=0 status
</p><p>

1. Stop the web analyser and relevancy admin

</p><p>Waadin abort processing
</p><p>Spreladmin abortprocessing
</p><p>

1. Rebuild the primary index column. Run the command from the primary indexer server to stop the processes.

</p><p>Nctrl stop
</p><p>

1. Delete the folder ‘data_index’ within the directory ‘FASTSearch\data’ and start the services again using the nctrl command. When you start the processes the ‘data_index’ folder will be re-created and will be populated with a rebuild of the index.

</p><p>Nctrl start
</p><p>Indexerinfo --row=0 --column=0 status
</p><p>

Notice the “document size” entry, and check that the “indexed=0” is displayed as this comes from the fixml and means the index is empty. Keep re-running the status query until indexed items are at their original value. This is when it is complete.

1. Once the rebuild is complete, you can then resume the web analyser and relevancy admin.

</p><p>Waadin enqueueview
</p><p>Spreladmin enqueue
</p><p>

Option B is now in place and complete. This will bring your FAST Search Index back online and ready for use.

Making SharePoint Search Available in Windows Explorer

In SharePoint 2010 there is a nice little feature in a search site called a ‘search connector’ that enables you to run search queries from Windows Explorer. The search connector is displayed in your favourites drop down. Also, you can have more that one search connector if you have a number of different search sites configured in your SharePoint environment and name them accordingly e.g Intranet Search, Team Site Search etc.

Below are the details of how to set up a search connector:

1) Run a search query from your search site (Any OOTB search site) and click on the third icon below which will be at the top of your search results and slightly to the right.

2) Select ‘Add’ to the Add Search Connector prompt’.

Your Search icon will now appear in your Favourites menu in Windows Explorer. The icon can be renamed accordingly.

Storage Metrics in SP2010 Service Pack 1

Quite a nice feature in SharePoint 2010 that has gone relatively unnoticed in SharePoint 2010 service pack 1, is the Storage Metrics feature. It is available under Site Collection Administration and it enables you to get useful information regarding how content is being used within your site collection. The report will give you a list breakdown of the content and the physical size along with the percentage of the site quota that has been used. This is particularly useful for Site Collection Administrators and IT Pro’s who will want to monitor the size of the content for particular sites. You can take this a step further with using third party tools such as Axceler’s Control Point application which will give you trend analysis on your content.

You are able to go granular with the results to the individual file level, so you can troubleshoot a growing content database by finding out what sort of file types are taking up space in a particular document library or list.

Please note that this feature is only available in Service Pack 1 of SharePoint 2010.

Web Analyzer Failing for FAST Search

The FAST Search implementation for SharePoint 2010 is a convoluted process and mistakes in the deployment.xml can cause performance and functionality headaches further down the line during your testing and implementation process. As part of the initial installation phase of FAST search you are required to pre-configure the deployment.xml file. The deployment.xml file is used to determine what components are to be utilized and for which server in your FAST Search topology. As part of all FAST Search topologies, you will have an admin server which will host the web analyzer component. This component is used to analyse search clickthrough logs and hyperlink structures which both contribute to better ranked search results and relevancy.

An issue that we discovered in testing was that the web analyzer was not functioning correctly as we had numerous error messages in the webanalyzer.log file stating that the web analyzer could not connect to the config server. Typical error messages we discovered are detailed below:

“Module (Web Analyzer) at “fast1.domain:13300″ is not responding”

“Couldn’t connect to the Config Server”    

So what caused this error? The error relates to the deployment.xml, the file is case sensitive and if you name your admin server with a case mismatch (e.g “Server1.domain.com”) then this will cause the web analyzer to fail as it will not be able to identify the config server due to the upper case ‘S’ even if you use the FQDN. So in order to avoid this issue then I recommend using a lower case naming convention for all server names when configuring your deployment.xml.

If you encounter this issue in your existing environment then there is a process that can be followed to update your FAST Search configuration. The steps are detailed below:

1.Stop the services on all FAST Search Servers using “nctrl stop” in FAST powershell.

2. Edit the deployment.xml on the FAST Search Admin server and change the FQDN for the admin component to be all lower case.

3. On the admin server, edit ‘etc\waconfig.xml’ and ‘etc\node.xml’ and update the hostname to be all lowercase.

4. In FAST Powershell, run “Set-FASTSearchConfiguration” on the admin server and start the services by running “nctrl start”.

5. Now repeat steps 3 and 4 for all your other FAST servers in your topology.

Your FAST Search environment will now have a working web analyzer. For further reading on the deployment.xml then please refer to the msdn article.

FAST Search 2010 (FS4SP) – Disabling TCP/IP Offloading Engine (TOE)

Installing and configuring FAST Search for SharePoint 2010 is a complex process which is mainly due to FAST Search being bought by Microsoft and then bolted onto the SharePoint 2010 product. If you are deploying your FAST Search Server to virtualised servers, then you may well encounter an issue where FAST servers fail to communicate with each other correctly with the default settings of the network adapter. In addition to the communication issues, the feeding of content to a multi-node FAST environment will not be indexing properly and the full crawls will take drastically longer than they should to complete. This will be due to a known issue where IPSEC does not work correctly with TCP/IP offloading.

The types of errors you will be getting in your FAST Search logs are:

WARNING systemmsg Module (Search Dispatcher) at fast.yourdomain.com:15102 is not responding
VERBOSE systemmsg The ping call resulted in the following exception: socket.error: [Errno 10061] Connection refused.
WARNING systemmsg Module (NodeControl) at fast.yourdomain.com:16015 is not responding
VERBOSE systemmsg The ping call resulted in the following exception: Timeout

TCP/IP Offloading (or TOE for short) is a technology system used for the purpose of optimizing the throughput of Ethernet systems. The communication speed in Ethernet systems has increased faster than computer processor speed. This means that the speed of the data from the network is too much for the processor to handle and thus will cause a bottleneck. TOE would solve this problem by removing offloading from the microprocessor and I/O subsystem. However, TOE does not work with IPSEC which is used by FAST Search for SharePoint so TOE is required to be disabled on your virtual machine. In doing this, you will see a performance increase in FAST Search (and your SharePoint servers) and the communication errors during crawls will be resolved.

To disable TCP/IP offloading on your virtual machine, follow the steps below:

1) Open a Cmd prompt and run the following:

netsh int ip set global taskoffload=disabled

netsh int ip show global (This will show that it is disabled Task Offload’)

Netsh int tcp set global chimney=disabled

Netsh int tcp show global (This will show the ‘Chimney Offload State’ as disabled)

2) Now go to the ‘Advanced’ tab of the Network Adapter device properties and change all the properties with ‘Offload’ in the property name to ‘Disabled’ and reboot the machine. Repeat this process for all your FAST Search servers.

This process is now complete and you will no longer have the communication errors during crawls and the warnings will no long appear in your logs. If you wish to read more about this TCP/IP offloading issue, then I would recommend Microsoft’s KB article.