none
How to Verify Sharepoint to FAStSearch is 100% OK RRS feed

  • Question

  • I have another post in here on my Event 6398 issues and am struggling to get a response.

    While i find many articles which use the Power Shell and use of the Web Client ON the FAST Search Server, i am struggling to find something that allows you to verify on the Sharepoint side (separate servers) that all is OK for Sharepoint to communicate with FASTSearch. In my case at the various FAST search setting screens, all appears OK.

    >> Is there such a guide ?

    Thanks

    Thursday, March 22, 2012 2:49 AM

Answers

  • Are you looking to see whether all components are ok(Sharepoint, FAST and the communication layer between both) or are you simply looking to make sure that Sharepoint is communicating properly with FAST?

    On the FAST side, your best bet is looking at logs located in %FASTSEARCH\var\log directory on each FAST node.  It's quite a bit of info there and still is a manual process if you really want to see what's happening deep on FAST component level.

    On the feeding side, looking at Sharepoint crawl logs would give you a good indication of any problems.  If you want to dive even deeper, you can take a look and enable some of the performance counters mentioned here:

    http://technet.microsoft.com/en-us/library/gg604768.aspx

    Crawling perf. counters would give you some info on communication layer between Sharepoint and FAST(feeding side), while other counters would give you FAST-specific info(indexer, item processing, query-side).

    Another interesting tool on FAST/Sharepoint communication layer(feeding side) would be this:

    ****

    Enable Sharepoint Content API logging. 

    This would be done on Sharepoint app server that has a crawl component and a log file would be generated during a new crawl:
     
     
    Additional debug logs for the FAST Connector can be enabled through the following registry key on your Sharepoint application server(crawl server):
     
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\14.0\Search\Global\Gathering Manager
    Create a String Value called "ContentAPILogFile", containing the full path + name of the file to use for logging.
     
    The mssearch.exe process ("osearch14" service) needs to be restarted for this setting to become effective.  Disabling logging is done by deleting the registry key and restarting the process.  Examine the new logfile for errors.
    ***

    For query side, i think if you are able to access FAST Managed properties via a GUI, search results are returned as expected and there are no strange WCF communication errors, you are probably ok.


    Igor Veytskin

    Thursday, March 22, 2012 3:22 PM
    Moderator

All replies

  • Are you looking to see whether all components are ok(Sharepoint, FAST and the communication layer between both) or are you simply looking to make sure that Sharepoint is communicating properly with FAST?

    On the FAST side, your best bet is looking at logs located in %FASTSEARCH\var\log directory on each FAST node.  It's quite a bit of info there and still is a manual process if you really want to see what's happening deep on FAST component level.

    On the feeding side, looking at Sharepoint crawl logs would give you a good indication of any problems.  If you want to dive even deeper, you can take a look and enable some of the performance counters mentioned here:

    http://technet.microsoft.com/en-us/library/gg604768.aspx

    Crawling perf. counters would give you some info on communication layer between Sharepoint and FAST(feeding side), while other counters would give you FAST-specific info(indexer, item processing, query-side).

    Another interesting tool on FAST/Sharepoint communication layer(feeding side) would be this:

    ****

    Enable Sharepoint Content API logging. 

    This would be done on Sharepoint app server that has a crawl component and a log file would be generated during a new crawl:
     
     
    Additional debug logs for the FAST Connector can be enabled through the following registry key on your Sharepoint application server(crawl server):
     
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\14.0\Search\Global\Gathering Manager
    Create a String Value called "ContentAPILogFile", containing the full path + name of the file to use for logging.
     
    The mssearch.exe process ("osearch14" service) needs to be restarted for this setting to become effective.  Disabling logging is done by deleting the registry key and restarting the process.  Examine the new logfile for errors.
    ***

    For query side, i think if you are able to access FAST Managed properties via a GUI, search results are returned as expected and there are no strange WCF communication errors, you are probably ok.


    Igor Veytskin

    Thursday, March 22, 2012 3:22 PM
    Moderator
  • Thursday, March 22, 2012 10:54 PM
  • Greg,

    Take a look at the original thread, i just posted there.


    Igor Veytskin

    Monday, March 26, 2012 8:32 PM
    Moderator