This is a short post about two FAST for SharePoint topics that I have had trouble finding information about on the Web. I hope this post helps others who run into either of these issues.
The first topic is people search. It is well known that SharePoint continues to handle people search even when a web application is configured to use FAST for content search. The question I had a hard time finding an answer to is “how do you configure your service applications to crawl the profile store to support people search?” Configuring a SharePoint farm to use FAST requires the creation of two FAST search service applications. The first is the content or crawling application and the second is the query application. The content application is responsible for crawling content and passing it to the FAST server to be indexed. The query application passes queries along to FAST and then returns the results to the UI layer for display.
Which of these do you think you should configure to crawl the profile store for people search?
Although it is somewhat counter-intuitive (at least it is to me), it is the query service application that needs to be set up to crawl the profile store. You create your content source, crawl rules, and crawl schedule in the query application and, when a crawl is performed, it is this application that handles the indexing of the profile data. This is a completely separate index from the FAST index.
I have always thought it was strange that the FAST query application would have crawl related links in its left-hand navigation. Now I know why.
The second topic is security trimming of BCS content sources in FAST for SharePoint. BCS supports a method type called AccessChecker that can be used to check a user’s access to content at query time. This can be used as an alternative to including a WindowsSecurityDescriptorField on your BCS entity that provides security ACLs at crawl time. Both approaches are supported by SharePoint search. Unfortunately, only the crawl-time ACL-based approach is supported by FAST search.
I have received confirmation from Microsoft that the query-time access check is not supported by FAST, but I did not get any information on why this is the case. My guess is that it is because the query is processed by the FAST server which knows nothing about the BCS entity. The FAST server knows only about the data that it was provided by SharePoint and which it has stored in its index. Perhaps in the future, Microsoft could build a hook into the query service application that would allow it to do some additional trimming of the results returned by FAST before sending these results to the UI.
The first topic is people search. It is well known that SharePoint continues to handle people search even when a web application is configured to use FAST for content search. The question I had a hard time finding an answer to is “how do you configure your service applications to crawl the profile store to support people search?” Configuring a SharePoint farm to use FAST requires the creation of two FAST search service applications. The first is the content or crawling application and the second is the query application. The content application is responsible for crawling content and passing it to the FAST server to be indexed. The query application passes queries along to FAST and then returns the results to the UI layer for display.
Which of these do you think you should configure to crawl the profile store for people search?
Although it is somewhat counter-intuitive (at least it is to me), it is the query service application that needs to be set up to crawl the profile store. You create your content source, crawl rules, and crawl schedule in the query application and, when a crawl is performed, it is this application that handles the indexing of the profile data. This is a completely separate index from the FAST index.
I have always thought it was strange that the FAST query application would have crawl related links in its left-hand navigation. Now I know why.
The second topic is security trimming of BCS content sources in FAST for SharePoint. BCS supports a method type called AccessChecker that can be used to check a user’s access to content at query time. This can be used as an alternative to including a WindowsSecurityDescriptorField on your BCS entity that provides security ACLs at crawl time. Both approaches are supported by SharePoint search. Unfortunately, only the crawl-time ACL-based approach is supported by FAST search.
I have received confirmation from Microsoft that the query-time access check is not supported by FAST, but I did not get any information on why this is the case. My guess is that it is because the query is processed by the FAST server which knows nothing about the BCS entity. The FAST server knows only about the data that it was provided by SharePoint and which it has stored in its index. Perhaps in the future, Microsoft could build a hook into the query service application that would allow it to do some additional trimming of the results returned by FAST before sending these results to the UI.
