FAST Search isn’t 100% with Claims Based Authentication

If you have tried to configure FAST search for SharePoint with a site using CBA and/or kerberos, you probably noticed that the thumbnail images won’t appear. Apparently a known issue:

From MSDN forum post http://social.technet.microsoft.com/Forums/en-US/sharepoint2010setup/thread/2cf51010-7845-47bb-adcf-a009abcfcbb4/

Your reported issue is a known limitation in the current version of FAST Search for SharePoint, main reason being kerberos / claim requirement came a bit too late after main design and implementation of doc preview wacproxy and its interface with WAC server were finished. So far it doesn’t seem to be possible to resolve this issue without introducing a significant redesign in both WAC and FAST, and as a result the FAST product group has confirmed there will be no plan (at least for now) to introduce any design change to support this. While we clearly understand that this is an important issue to many customers we do regret that there won’t be any change in the current version of product. On the other hand, both FAST and WAC product groups have taken this scenario into planning in the next wave of SharePoint release, so let’s hope it will work like charm by then.

So wait we do…

UPDATE 11/4/11 9:18 AM

Within an hour of posting this I received some feedback stating it is in fact doable. Note comments on this post and the MSDN forum post. I’ll try it out and see how it goes.

UPDATE 11/11/11 10:30 AM

Haven’t tried the proposed workaround from the above. Microsoft released a KB article stating the bug, with a resolution of removing claims… http://support.microsoft.com/kb/2641517

Advertisements

2 thoughts on “FAST Search isn’t 100% with Claims Based Authentication

  1. Arno Flapper

    Strange. I got the results working on a claims based site, Usually the problem lies somewhere else, although finding the root cause is a pain.

    Many attribute the problems with the previews to claims, but since it does work on several sites I have build using claims and FAST, I do not believe this answer.

    Finding the root cause involves using Fiddler to analyze the requests, reinstalling Office Web Apps, giving service accounts rights to the managed metadata & user profile services, installing IIS on the FAST server, etc.

    The first time it cost me around 2 weeks to find the root cause, which was a proxy that was blocking traffic.

    Reply
    1. David Lozzi Post author

      Thanks for the info, I was going to look for a workaround but if it is fixable, I’ll keep looking. Thanks!

      Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s