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.

European SharePoint Conference Copenhagen 2013 – Enterprise Search

I have finally got round to blogging about the European SharePoint conference. I would have liked to have given the excuse that it has taken this long due my hands still needing time to defrost from the Scandinavian chill but work and life have been on fast forward til now. Ok, enough of me rabbiting on, here is some feedback from the conference and in particular Enterprise Search.

As you may well know, SharePoint 2013 now fully integrates FAST Search for SharePoint into the main product as a service application (so no separate install). Below are some key points about SP2013 search from the Enterprise Search workshop I attended that was run by Agnes Molnar.

  • Fast Search now fully integrated as a service application
  • Deep refiners are not switched on by default, they have to be enabled.
  • A new hover button is available in your search results (very nice feature)
  • Document previews are only available for documents held within SharePoint.
  • Document previews not available for PDFs.
  • Managed Properties are now opened from the ‘Search Schema’ in your search administration.
  • ‘Results Sources’ now replaces ‘Search Scopes’ and ‘Federated Sources’ in search administration.
  • You can now create ‘Result Sources’ from managed properties.
  • A new feature called ‘Continuous Crawling’ can enable you to crawl your content sources continually. However, this is for SharePoint content sources only.
  • The Continuous Crawler component requires resources of at least 6-8 processors.
  • You can now delegate search administration to designated users.
  • People Search is now fully integrated into the Search application using the Fast search capabilities unlike in SP2010 where it had to use SharePoint Search only to crawl people data.
  • Better query rules, one query request returns multiple result sets.
  • Document parsing is different than 2010, the crawl component crawls every file in the content source regardless of the document extension. I believe powershell can be used to exclude certain document extensions if needed. This will mean that your ndex will be larger in SharePoint 2013, worth looking out for.

I hope this sheds a little light into the SP 2013 Search Application. Some companies will be some way off migrating to SharePoint 2013 but the more information we are aware of before migrating then the more prepared we will be.

I will have another blog on troubleshooting and the performance of SharePoint Search from the conference which will follow soon.

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.