Export (0) Print
Expand All

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

FAST Search Server 2010
 

Applies to: FAST Search Server 2010

Topic Last Modified: 2011-04-04

Issue: Queries are returning fewer documents than expected.

Summary: If a Microsoft FAST Search Server 2010 for SharePoint query is returning fewer documents than you expect to see, it could be that the search term is not present in the documents you expected it to be in, or it could indicate one of several item-level security issues.

Symptom: Queries are returning fewer documents than expected.

Causes: We recommend that you work through the possible causes in the given order:

Resolution: Ensure that the term is present in the documents

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

Resolution: Log in as the correct user

Security around search results is based on the user who is 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.

Resolution: Re-index the documents

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

Resolution: Determine the user’s permissions and ensure that the user has access to see the documents

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

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

  3. Go to <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.

  4. Open the log file that uses the name format authorization-worker_<computer>.txt, where <computer> 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 that serviced the request.

  5. 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, and it then lists the data for each claim that is associated with the user. For the claims with a claim type of http://schemas.microsoft.com/ws/2008/06/identity/claims/primarygroupsid, the value will be the Windows SID (Security Identifier) of a group that the user is a member of.

There is a known issue that causes the logging mechanism to truncate log messages when it has reached a certain size. If the user is a member of many groups, not all of the information will be displayed in the log file. If the log file is truncated, you can create a new log file:

  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 create 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:

    Open a Microsoft FAST Search Server 2010 for SharePoint command prompt and run the following command: nctrl restart samworker.

    This will create a new log file here: <FASTSearchFolder>\components\sam\worker\samworkerservice.txt.

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

  7. When you are 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.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft