FSA: Queries are returning fewer documents than expected (FAST Search Server 2010 for SharePoint)(informazioni in lingua inglese)

Aggiornato: 4 giugno 2010

If a FAST Search query is returning fewer documents than you expect to see, it could indicate one of several item level security issues.

Resolution

Work through each possible resolution in order.

Is the search term in the expected document?

If possible, verify that the search term is in the document outside SharePoint Server. Open the file and search for the term. If the document cannot be viewed outside SharePoint Server, try searching for a different term that should also be in the document.

Is the correct user logged into SharePoint when the search is performed?

Security around search results is based on the user logged into SharePoint Server when the search is performed. Verify that the correct user is logged into SharePoint Server by looking at the name of the user in the upper-right corner of the Web page.

At the time that the documents were indexed, did the user have permissions to view the documents or was that permission recently granted?

If the permissions on the document have changed, security on the search will not reflect those changes until the documents are re-indexed.

Does the searcher belong to a group that has permissions to the document?

Determine the user’s permissions to the document:

  1. Set the log level to info. Open a Microsoft FAST Search Server 2010 for SharePoint command prompt as an administrator and run the command:

    Set-FASTSearchSecurityLogLevel -DefaultLogLevel Info
    
  2. Re-run the search.

  3. In the directory <FASTSearchFolder>\var\log\syslog (where <FASTSearchFolder> is the path of the folder where you have installed FAST Search Server 2010 for SharePoint, for example C:\FASTSearch), open the log file that uses the name format authorization-worker_<machine>.txt, where <machine> is the computer name of the query processing node. If there are multiple query processing nodes in the system, the information can be in any log file for any of the query processing nodes, depending on which query processing node serviced the request.

  4. When you look in the log file for the FSA worker (FAST Search for SharePoint Sam Worker), search for a message from Claims.dll:GetClaimsPrincipal. This message includes the ID of the user making the request and the number of claims for this user. It then lists the data for each claim associated with the user. For the claims with a claim type of https://schemas.microsoft.com/ws/2008/06/identity/claims/primarygroupsid, the value will be the Windows SID value of a group that the user is a member of.

There is a known issue that causes the logging mechanism to truncate log messages after a certain size. If the user is a member of many groups, all of the information will not be displayed in the log file specified earlier in this section. Here is a workaround to this issue.

  1. Restart the FAST Search for SharePoint Sam Worker. This can cause the query processing node to be unavailable until the FSA worker is functioning and up to date with configuration.

  2. Go to the query processing node where you want to enable a new log file.

  3. Open the file <FASTSearchFolder>\bin\Microsoft.SharePoint.Search.Extended.Security.WorkerService.exe.config and search for <dependency name=”FileLogWriter” />.

  4. Remove the comments <!-- and --> from around this XML element and save the file.

  5. Restart the FSA worker in a Microsoft FAST Search Server 2010 for SharePoint command prompt by running nctrl restart samworker. This will create another log file that is located at <FASTSearchFolder>\components\sam\worker\samworkerservice.txt.

  6. Re-run the search and the complete log message together with all of the security information should be included in the newly created log file.

  7. When you have finished with the log file, set the log level back to the default of Warning and comment out the FileLogWriter that allows the second log file to be generated.

Cronologia delle modifiche

Data Descrizione Motivo

4 giugno 2010

2010/05May/Week5

Aggiornamento contenuto

12 maggio 2010

Pubblicazione iniziale