FSA: Queries are returning fewer documents than expected (FAST Search Server 2010 for SharePoint)
Published: May 12, 2010
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:
Cause 1: The search term is not present in the documents that you expected it to be in
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.
Cause 2: The query is performed by the wrong user
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.
Cause 3: The user did not have access rights to the documents when they were indexed
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.
Cause 4: The group that the user belongs to does not have access to the documents
Resolution: Determine the user’s permissions and ensure that the user has access to see the documents
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
Re-run the search.
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.
Open the log file that uses the name format
<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.
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:
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.
Go to the query processing node where you want to create a new log file.
Open the file <FASTSearchFolder>\bin\Microsoft.SharePoint.Search.Extended.Security.WorkerService.exe.config and search for
<dependency name=”FileLogWriter” />.
Remove the comments
-->from around this XML element and save the file.
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.
Re-run the search. The complete log message and all of the security information should be included in the newly created log file.
When you are finished with the log file, set the log level back to the default of Warning and comment out the
FileLogWriterthat allows the second log file to be generated.