(このポストでは、書籍「VSTO と SharePoint Server 2007 による開発技術」(8章 : エンタープライズ検索と BDC) の補足情報を記載しています。基本的な内容 / 全体は、書籍を参照してください。)

環境:
Office SharePoint Server 2007 (インフラストラクチャー更新プログラム含む)
または Search Server 2008

SharePoint エンタープライズ検索 (4回シリーズ)

• 検索セキュリティのアーキテクチャ
• フェデレーションと Windows 7
• 検索精度のチューニング (関連性とランキング)
• FAQs / さいごに

こんにちは。

最後に、懇親会で頂いたその他のご質問事項について回答を記載します。(いくつかは、会場で回答させていただいた内容に補足しています)

エンタープライズ検索を実現できる SharePoint のエディション

書籍でも記載しているように、エンタープライズ検索では、Office SharePoint Server 2007 をご使用ください。Windows SharePoint Services 3.0 では、そのサーバー (SharePoint) のドキュメントしか検索対象にはできませんし、管理 UI も非常に限定的です。(懇親会でも参加者の方よりフィードバックがありましたが、このエディションで検索の細かな設定をしようとすると結構面倒です。確か、再クロールなども、stsadm.exe コマンドで実施する必要があったように記憶しています . . .)

無償環境で試してみたいという方は、Search Server 2008 Express Edition を使用すると良いでしょう。ただし、セミナーでお伝えしたようないくつかの制限事項がありますので、大きな企業などでは、この Express Edition は試用環境のつもりでお使いください。
尚、BDC (ビジネスデータカタログ) の使用には、Office SharePoint Server 2007 のエンタープライズ用ライセンス (ECAL) が必要となりますのでご注意ください。

各エディションで使用可能な機能の詳細については以下が参考になります。

Office Online : SharePoint Server 2007 エディション比較 :
http://office.microsoft.com/ja-jp/products/FX101758691041.aspx

Office SharePoint Server Search (osearch) のアカウント / アクセス権

検索に関して一般に多い問題として、検索時のアカウントの問題があります。
基本的なクロールの処理に失敗するケースならすぐに原因が突き止められるかもしれませんが、例えば、BDC を使用した検索などでも使用されているため (BDC の場合、対象の LOB データに接続できれば良いように思われるかもしれませんが、SharePoint の検索データベースなども同時に見に行っています)、この理由で BDC の検索が失敗するといったことも起こる場合があります。(この場合、「ローカルサーバーファームを検出できませんでした」 (Local Server Farm cannot be detected.) という例外が発生します。)

「ただインストールしただけなのに動かない !」といったケースも多く、インストール後の最初のクロールで、まずは、SharePoint のエラーログ (%ProgramFiles%\Common Files\Microsoft Shared\web server extensions\12\LOGS) やクロールログを確認してアクセス権のエラー/例外などが発生していないか確認してみましょう。

エラーが発生するようであれば、SQL Server に (SQL Server Management Studio などで) 管理者でログインし、検索サービスで参照されるコンテンツデータベースや構成データベースなどのセキュリティをチェックしてみましょう。そして、コンテンツデータベースが osearch (Office SharePoint Server Search) のアカウントでアクセス可能か確認し、不可な場合には、以下の手順でデータベースの利用が可能となるようにアカウントの変更をおこなっておきましょう。

1. [サーバーの全体管理] で [サーバー構成の管理] を選択し、[サーバーのサービス] をクリックします。
2. サービスの一覧の中の [Office SharePoint Server Search] を選択し、使用されているサービスアカウントを確認し、必要に応じ変更します

尚、書籍にも記載していますが、エンタープライズ検索で使用されているサービスは、Office SharePoint Server Search (osearch) サービスであり、Windows SharePoint Services Search サービスではありません。

BDC (ビジネスデータカタログ) を使用した検索におけるトラブル

書籍にも記載していますが、こちらも検索に関するトラブルがいくつかあります。
BDC でアクセス権のエラーが発生する場合には、まず、以下の手順で、コンテンツアクセスアカウントとして充分な権限をもったユーザー (例えば、NetworkServices や LocalService 以外の、一般の権限を持ったアクセス可能なユーザー) が使用されているか確認しましょう。

1. 共有サービス管理の画面で、[検索の設定] をクリックします
2. [既存のコンテンツアクセスアカウント] を選択します

BDC では、個別のメソッドインスタンスの実行権限も設定されており、共有サービス管理の画面で [ビジネスデータカタログの権限] をクリックするとこの設定を確認/変更することができます。クロール時にもメソッドインスタンス (書籍でも記載している IDEnumerator メソッド) が実行されるため、ここで、メソッドインスタンスに対する充分な権限が付与されていないと、クロールの実行時にも権限不足でエラーになります。(通常は、管理者に対してすべての権限が付与されていますので、上記のコンテンツアクセスアカウントもまずは管理者に設定しておくと問題なくクロールされます。)

一部のファイルが検索できない ! 

SharePoint では非常に多くの IFilter を最初からサポートしていますが、書籍に記載したように、PDF, OneNote などについては追加の IFilter のインストール/設定が必要となります。下記のブログには、これらの最新情報が掲載されています。

http://blogs.msdn.com/ifilter/

また、独自のファイル形式などでは一般に IFilter の開発が必要となりますが、サードパーティが提供しているツールや、業界で著名なソフトウェアなどの場合、既に製品を提供しているベンダーや、パートナー企業、同一業界の他企業などにより IFilter が提供されている場合も多くありますので、検索してみると良いでしょう。例えば、国内でも AutoCAD 用の IFilter が開発されていたりします。( http://www.satori.co.jp/product/division/3037/3714.html )

また懇親会で、.mht (単一ファイルの Web アーカイブファイル) が検索できないというご質問がありました。この形式の IFilter は SharePoint インストール時にはちゃんとインストール/設定されています (検索可能です) が、試しに MSDN のサイトなどを .mht、あるいは .htm などで保存して SharePoint にアップロードして検索をしてみると、御質問者の方が言われていたように、確かに検索結果に表示されませんでした。
こうした場合には、クロールログを確認すると、各ドキュメントについてクロールできなかった原因が記載されています。今回の私のケースでは、該当のドキュメントで 「この URL のコンテンツはインデックス付けしない属性を持つため、サーバーによって除外されています」(Content for this URL is excluded by the server because a no-index attribute.) という警告が表示されていました。こうした場合は、このコンテンツ (HTML のソース) に、検索対象から除外するようタグなどが指定されている可能性があります。NOHTMLINDEX や、NOINDEX などの Meta タグが指定されていないかドキュメント内のソースを確認し、このタグを削除してドキュメントを登録して再クロールをしてください。(ある意味、これは、ファイングレインパーミッションによる正しい動作です。MSDN の場合、多くの文書で NOINDEX が指定されていました。)

トポロジー構成 (インデックスサーバー / クエリサーバー構成) における注意点

これはセミナーの中でご説明したポイントですが、クエリーサーバーが検索をおこなう際には、クロールで抽出されたインデックスカタログ (ファイル) と search property (データベース) が使用されています。書籍でも記載しているように、クエリーサーバーが複数に分散されている場合には、収集されたインデックスカタログもクエリーサーバーにコピーされますので、クエリーサーバーは複数への負荷分散が可能ですが、例えば、1 台のクエリーサーバーをインデックスサーバーと同一マシン上に配置し、もう1 つのクエリーサーバーを別のマシンに配置する、といった負荷分散をおこなった場合には、インデックスサーバーとクエリーサーバーが同一マシン上に存在していると判断し、インデックスサーバーはカタログのコピーをおこないません。
ファーム構成に際しては、この点を注意して構成をおこなうようにしましょう。

またクロール中にもデータベースにアクセスすることになるため、クエリーの利用頻度などによってはデータベースへの IO もボトルネックとして無視できない場合があるでしょう。こうした場合には、データベースのファイルグループをクエリー用とクロール用にわけるといった裏技もエンタープライズ検索のチームブログで紹介されていますので、規模の大きな検索ポータルを構成する場合には是非参考にしてください (下記)。

Microsoft Enterprise Search Blog : SQL File groups and Search
http://blogs.msdn.com/enterprisesearch/archive/2008/09/16/sql-file-groups-and-search.aspx

さいごに (FAST ESP へ)

FAST でどのようなレベルの機能が実現できるかはデモでご覧いただいた通りです。ここまでを理解 (書籍の内容含め) された方なら、FAST の威力が理解していただけるでしょう。

その特徴を復習しておきます。

• デモでご覧いただいたように、FAST では、さらに高度で、多次元的な検索ストラクチャーを管理 しています。
  FAST による絞り込み、ナビゲーションなどの機能と同等のものを SharePoint 上で (カスタムに) 作成する場面を連想していただけるとその恩恵が容易におわかり頂けるでしょう。
• とにかく、コマースサイトでの経験が豊富です。
  サイト名までは挙げませんが、国内外の著名なサイトでもいくつか活用されており、クエリー規模に対しての スケーラビリティの実績 の面でも商用レベルでの豊富な経験を有しています。
• デモでご覧いただいたように SharePoint との連携が可能 です。
  SharePoint 上のコンテンツも検索対象にでき (最初にご説明した検索セキュリティも維持されます)、リレーショナルデータとの統合なども同様に可能で、さらに SharePoint 上の Web パーツとして UI も表現できます。
• さらに FAST では、パイプライン方式の統一的で柔軟なカスタマイズ手法 を提供しています。
  検索エンジンにカスタマイズ機能を追加している、というよりも、カスタマイズを想定したフレームワークに基づいて構成されています。

FAST は、イベントやセミナーなどでも 時折 紹介されていますので、またご覧になる機会などありましたら是非参考にしてください。