FSA: Queries always fail on a specific query processing node (FAST Search Server 2010 for SharePoint)(informazioni in lingua inglese)

  • Articolo

Data pubblicazione: 12 maggio 2010

If FAST Search does not always work, determine whether queries are failing on one specific query processing node. If that is true, follow these steps to resolve the problem.

Resolution

Work through each possible resolution in order.

Is the FAST Search Server 2010 for SharePoint query processing node currently running?

The FAST Search Server 2010 for SharePoint services must be running for queries from the SharePoint Server front-end to be serviced by the FAST Search Server 2010 for SharePoint back-end. Verify that FAST Search Server 2010 for SharePoint is running:

  1. Log onto each FAST Search Server 2010 for SharePoint query processing node server and open a Microsoft FAST Search Server 2010 for SharePoint command prompt.

  2. Run the command: nctrl status.

  3. Verify that these processes are running: samworker, qrproxy, and qrserver.

    See also Restart FSA.

Was the FAST Search Server 2010 for SharePoint query processing node set up correctly to communicate with SharePoint?

To verify the setup of FAST Search Server 2010 for SharePoint, follow the steps in Has the SharePoint certificate been copied to the FAST Search Server 2010 for SharePoint query processing node? and Has SharePoint been configured to point to the FAST Search Server 2010 for SharePoint query processing node?.

Is the query processing node’s FSA worker process up to date with configuration changes?

When configuration changes are made to FSA, the changes must be copied to all the query processing nodes. Configuration changes occur when you run the Windows PowerShell cmdlets with the prefix verb-FASTSearchSecurity. For example, the Set-FASTSearchSecurityLogLevel cmdlet updates the configuration with the log level setting. When a FAST Search for SharePoint Sam Worker is restarted, it must wait for the FAST Search for SharePoint Sam Admin process to communicate with it and to verify that it has all the configuration changes. This process may take several minutes depending on how many query processing nodes are in the system and how many changes occurred while the node was down. To verify that all the worker nodes have the most recent configuration changes, follow these steps:

  1. Open a FAST Search Server 2010 for SharePoint command prompt.

  2. Run Get-FASTSearchSecurityWorkerNode.

  3. Verify that the status for all nodes is active. If any node is not active, wait for several minutes and recheck. If it is still not active after 5 to 10 minutes, increase the log file levels and look in the logs for both the FAST Search for SharePoint Sam Worker and FAST Search for SharePoint Sam Admin.

Does the event viewer contain a message for the FAST Search QRProxy that says, “An unhandled exception occurred: Unable to connect to SAM”?

This error is caused when the QRProxy service cannot communicate with FSA. You may receive this error message because the FAST Search for SharePoint Sam Worker is not started, because the FAST Search for SharePoint Sam Worker does not have the most recent configuration changes, or because a WCF error is preventing it from communicating. If the FAST Search for SharePoint Sam Worker is running and has the most recent configuration, restart QRProxy with the following steps.

  1. Open a FAST Search Server 2010 for SharePoint command prompt.

  2. Run the command: nctrl restart qrproxy.

  3. After the QRProxy service is started, retry the search.

If the problem still exists, verify that the FAST Search for SharePoint Sam Worker is ready to receive requests. Follow these steps on the node where the QRProxy and FAST Search for SharePoint Sam Worker communication is not working.

  1. Open the FAST Search Server 2010 for SharePoint command prompt as an administrator and run the following commands:

    set-alias installutil $env:windir\Microsoft.NET\Framework64\v2.0.50727\installutil

installutil Microsoft.SharePoint.Search.Extended.Security.Worker.PowerShell.Commands.dll

add-pssnapin FASTSearchSecurityWorkerSnapIn

  2. Modify the configuration file base port value. There is a known issue which requires a minor change to the file at <FASTSearchFolder>\bin\Microsoft.SharePoint.Search.Extended.Security.Worker.Powershell.Commands.dll.config. This file includes a base_port XML element. Add one to the value and save the file. For example, if the value is 13000, change the value to 13001 and save the file.

  3. Run the cmdlet:

    Get-FASTSearchSecurityConfigurationStatus

  4. If the return value from this cmdlet is false, increase the log levels and look at the FSA worker logs.

  5. If the return value from this cmdlet is true, the problem is related to WCF. If restarting the FSA worker and QRProxy does not resolve the problem, enable WCF tracing to diagnose the error. To enable WCF tracing between QRProxy and the FSA worker, follow these steps.

    1. Modify <FASTSearchFolder>\bin\Microsoft.SharePoint.Extended.Security.WorkerService.exe.config and <FASTSearchFolder>\bin\QRProxyService.exe.config. Remove the comments <!-- and --> from around the <diagnostics> and <system.diagnostics> XML elements in both files.

    2. Save the files.

    3. Restart both the FSA worker and QRProxy. This will create two files in the <FASTSearchFolder>\bin with extension .svclog.

    You can find more information about how to view WCF trace files by searching TechNet.

Cronologia delle modifiche

Data Descrizione Motivo

12 maggio 2010

Pubblicazione iniziale