クロールとフェデレーションの計画を立てる (SharePoint Server 2010)

適用先: SharePoint Server 2010

トピックの最終更新日: 2016-11-30

エンド ユーザーが Microsoft SharePoint Server 2010 でエンタープライズ検索機能を使用できるようにするには、ユーザーによる検索の対象とするコンテンツのクロールまたはフェデレーションを行う必要があります。クロールまたはフェデレーションの計画には、次のような作業が含まれます。

• コンテンツ ソースを計画する

• 対象とするファイルの種類と IFilter を計画する

• 認証を計画する

• コネクタを計画する

• クロールの影響の管理を計画する

• クロール ルールを計画する

• ファーム レベルで管理される検索設定を計画する

• フェデレーションを計画する

コンテンツ ソースを計画する

コンテンツ ソースは、クロールするコンテンツの種類、クロールする URL、およびクロールする深さと時期を指定するために使用できるオプション セットです。既定のコンテンツ ソースは、ローカルの SharePoint サイトです。このコンテンツ ソースを使用して、特定の Search Service アプリケーションに関連付けられているすべての Web アプリケーションにあるすべてのコンテンツをクロールする方法を指定できます。既定では、特定の Search Service アプリケーションを使用する Web アプリケーションごとに、SharePoint Server 2010 は各サイト コレクションのトップレベル サイトの開始アドレスを既定のコンテンツ ソースに追加します。

既定のコンテンツ ソースを使用して検索要件を満たすことができるのは一部の組織だけです。多くの組織では、コンテンツ ソースを追加する必要があります。追加のコンテンツ ソースを計画するのは、次の作業を行う必要がある場合です。

• SharePoint サイト、ファイル共有、ビジネス データなど、さまざまな種類のコンテンツをクロールする。

• コンテンツによってクロール スケジュールを変える。

• クロールするコンテンツの量を制限または増やす。

• さまざまなサイトをクロールするときに異なる優先順位を設定する。

Search Service アプリケーションごとに最大 500 個のコンテンツ ソースを作成でき、各コンテンツ ソースには、500 個の開始アドレスを入れることができます。管理をできるだけ簡単にするために、作成するコンテンツ ソースの数を制限することをお勧めします。

さまざまな種類のコンテンツのクロールを計画する

1 つのコンテンツ ソースにつき 1 種類のコンテンツしかクロールできません。つまり、SharePoint サイトの開始アドレスを含んでいるコンテンツ ソースと、ファイル共有の開始アドレスを含んでいる別のコンテンツ ソースは作成できますが、SharePoint サイトとファイル共有両方の開始アドレスを含んでいる 1 つのコンテンツ ソースは作成できません。次の表に、構成できるコンテンツ ソースの種類を示します。

ビジネス データ用のコンテンツ ソースを計画する

ビジネス データ コンテンツ ソースの場合、データをホストするアプリケーションを Business Data Connectivity Service アプリケーションのアプリケーション モデルで指定する必要があります。1 つのコンテンツ ソースで、Business Data Connectivity Service に登録されているすべてのアプリケーションをクロールすることも、複数のコンテンツ ソースを使用してアプリケーションを個別にクロールすることもできます。

ほとんどの場合、ビジネス データをサイト コレクションに統合する計画を立てる担当者は、全体のコンテンツ計画プロセスの担当者とは異なります。このため、ビジネス アプリケーションの管理者をコンテンツ計画チームに加えて、ビジネス アプリケーションのデータをコンテンツに統合する方法、およびそのデータをサイト コレクションで効果的に配置する方法についてその管理者からアドバイスを得ることができるようにします。

異なるスケジュールでコンテンツをクロールする

コンテンツによってクロールの頻度を変えるかどうかを決定する必要があります。クロールするコンテンツの量が多くなるほど、異なるコンテンツ リポジトリからコンテンツをクロールする可能性が高くなります。このようなコンテンツは、種類が異なったり、さまざまな容量のサーバーに配置されている可能性があります。このような要因から、コンテンツ ソースを追加して、コンテンツ リポジトリごとに異なるスケジュールでクロールする必要が生まれます。

コンテンツを異なるスケジュールでクロールする主な理由には、次のようなものがあります。

• ダウン タイムと使用率のピーク時に対応するため。

• 更新頻度が高いコンテンツをより頻繁にクロールするため。

• 高速サーバーに配置されているコンテンツとは別に、低速サーバーに配置されているコンテンツをクロールするため。

多くの場合、このような情報の一部は、SharePoint Server 2010 を展開してある一定期間運用してみないとわかりません。このため、ファームの運用を開始した後でクロール スケジュールを指定する必要があります。ただし、現在わかっている情報に基づいてクロール スケジュールを計画できるように計画時にこれらの要因について検討することをお勧めします。

以下の 2 つのセクションでは、異なるスケジュールでコンテンツをクロールする方法について詳しく説明します。

クロールのスケジュールを計画するときの考慮事項

クロールのスケジュールは、コンテンツ ソースごとに個別に構成できます。コンテンツ ソースごとに、フル クロールを実行する時間と増分クロールを実行する時間を指定できます。増分クロールを実行できるようにするには、コンテンツ ソースのフル クロールを実行する必要があります。まだクロールしたことがないコンテンツについて増分クロールを指定した場合は、フル クロールが実行されます。

クロール サーバーとクエリ サーバーの可用性、パフォーマンス、および帯域幅に関する考慮事項に基づいて、クロールのスケジュールを計画することをお勧めします。

クロールのスケジュールを計画するときには、次のベスト プラクティスを考慮に入れてください。

• コンテンツをホストするサーバーの可用性の類似に基づき、それらのサーバーの全体的なリソース使用状況が許容範囲に収まるようにコンテンツ ソースの開始アドレスをグループ化します。

• コンテンツをホストするサーバーが利用可能で、サーバーのリソースに対する需要が低い時間帯に、各コンテンツ ソースの増分クロールをスケジュールします。

• ファーム内のサーバーの負荷が時間的に分散されるようにクロールのスケジュールをずらします。

• 次のセクションに挙げる理由でフル クロールを実行する必要がある場合にだけ、フル クロールをスケジュールします。フル クロールの実行頻度は、増分クロールよりも低くすることをお勧めします。

• フル クロールが必要になる管理上の変更は、計画したフル クロールのスケジュールの直前に実施されるようにスケジュールします。たとえば、次回予定されているフル クロールの前にクロール ルールを作成するという計画を立てて、フル クロールを別途実行する必要がなくなるようにします。

• 同時クロールは使用可能な容量に応じて実行します。最適なパフォーマンスが得られるように、コンテンツ リソースのクロール スケジュールをずらすことをお勧めします。各コンテンツ ソースのクロールに必要な標準的な時間がわかるようになると、クロールのスケジュールを最適化できます。

フル クロールを実行する理由

Search Service アプリケーションの管理者は、次の理由でフル クロールを実行します。

• ソフトウェア更新プログラムまたはサービス パックがファーム内のサーバーにインストールされた。詳細については、ソフトウェア更新プログラムまたはサービス パックの説明を参照してください。

• Microsoft Office SharePoint Server 2007 共有サービス管理者または SharePoint Server 2010 Search Service アプリケーションの管理者が新しい管理プロパティを追加した。新しい管理プロパティをすぐに有効にするには、フル クロールが必要です。新しい管理プロパティをすぐに有効にする必要がない場合は、フル クロールを実行する必要はありません。

• Windows SharePoint Services 3.0 サイトまたは Microsoft Office SharePoint Server 2007 サイトの ASPX ページのインデックスを再作成する。

  注意

  Windows SharePoint Services 3.0 サイトまたは Office SharePoint Server 2007 サイトの ASPX ページが変更されていると、クローラーは検出できません。このため、リスト アイテムが個別に削除されると、増分クロールではビューまたはホーム ページのインデックスが再作成されません。ASPX ファイルを含んでいるサイトのフル クロールを定期的に実行して、これらのページのインデックスが確実に再作成されるようにすることをお勧めします。

• 連続して発生する増分クロールのエラーを解決する。リポジトリの任意のレベルで増分クロールが 100 回連続で失敗すると、影響を受けたコンテンツがインデックスから削除されます。

• クロール ルールが追加、削除、または変更された。

• 破損したインデックスを修復する。

• Search Service アプリケーションの管理者が 1 つ以上のサーバー名マッピングを作成した。

• 既定のコンテンツ アクセス アカウントまたはクロール ルールに割り当てられているユーザー アカウントの資格情報が変更された。

増分クロールを要求したときに次の条件に当てはまる場合は、フル クロールが実行されます。

• 検索管理者が前回のクロールを停止した。

• コンテンツ データベースが復元された。または、ファーム管理者がコンテンツ データベースを切断して再接続した。

  注意

  Microsoft Office サーバー製品インフラストラクチャ更新プログラムがインストールされた Office SharePoint Server 2007 または SharePoint Server 2010 を実行している場合は、Stsadm コマンドライン ツールの復元操作を使用して、コンテンツ データベースの復元時にフル クロールを実行するかどうかを変更できます。

• サイトのフル クロールがこの Search Service アプリケーションから一度も実行されたことがない。

• 変更ログにクロール中のアドレスのエントリがない。クロール中のアイテムのエントリが変更ログにない場合、増分クロールを実行できません。

初期展開後に、ファーム内のサーバーおよびコンテンツをホストするサーバーのパフォーマンスと容量に基づいてスケジュールを調整できます。

クロールするコンテンツの量を制限または増やす

コンテンツ ソースごとに、開始アドレスをクロールするときの範囲を指定できます。クロール設定を変更することで、クロールの動作も指定できます。コンテンツ ソースに対して選択できるオプションは、選択するコンテンツ ソースの種類によって異なります。ただし、ほとんどのクロール オプションでは、開始アドレスから階層のどのレベルの深さまでクロールするのかを指定します。この動作は、特定のコンテンツ ソースにあるすべての開始アドレスに適用されます。一部のサイトでより深いレベルでクロールする必要がある場合、そのサイトを含んだ別のコンテンツ ソースを作成します。

クロール設定オプションを使用して、クロールするコンテンツの量を制限したり、増やすことができます。各コンテンツ ソースのプロパティで選択できるオプションは、選択したコンテンツ ソースの種類によって異なります。次の表では、クロール設定オプションを構成するときのベスト プラクティスについて説明します。

コンテンツ ソースを計画するときのその他の考慮事項

同じ Search Service アプリケーションで複数のコンテンツ ソースを使用して同じ開始アドレスをクロールすることはできません。たとえば、特定のコンテンツ ソースを使用してサイト コレクションとそのすべてのサブサイトをクロールする場合、別のコンテンツ ソースを使用して別のスケジュールでそのサブサイトのいずれかを個別にクロールすることはできません。

クロールのスケジュールを検討するときと同様、開始アドレスを 1 つのコンテンツ ソースにグループ化するのか、追加のコンテンツ ソースを作成するのかの判断は、管理上の考慮事項と大きく関係しています。管理者は、特定のコンテンツ ソースの更新を伴う変更を頻繁に行います。コンテンツ ソースを変更するには、そのコンテンツ ソースで指定されているコンテンツ リポジトリのフル クロールが必要です。管理を簡単にするために、コンテンツ ソース、クロール ルール、およびクロール スケジュールを管理者が更新しやすい方法で、コンテンツ ソースを構成します。

対象とするファイルの種類と IFilter を計画する

コンテンツがクロールされるのは、関連するファイル名拡張子がファイルの種類対象リストに含まれていて、そのファイルの種類をサポートする IFilter がクロール サーバーにインストールされている場合だけです。いくつかのファイルの種類と IFilter は、初回インストール時に自動的にインストールされます。初期展開で使用するコンテンツ ソースを計画するときには、クロールするコンテンツが使用しているファイルの種類が含まれているかどうかを確認します。含まれていない場合、展開時に [ファイルの種類の管理] ページでそのファイルの種類を追加する必要があります。

特定のファイルの種類がクロールされないようにする場合は、そのファイルの種類のファイル名拡張子をファイルの種類対象リストから削除します。削除すると、その拡張子が付いているファイル名はクロールされません。既定でインストールされるファイルの種類と IFilter のリストについては、「ファイルの種類と IFilter のリファレンス (SharePoint Server 2010)」を参照してください。

認証を計画する

クローラーがコンテンツ ソースに指定されている開始アドレスにアクセスするとき、そのクローラーは、そのコンテンツをホストするサーバーの認証を受け、アクセスを許可される必要があります。つまり、クローラーが使用するドメイン アカウントには、コンテンツに対する読み取りアクセス権以上の権限が必要です。

既定では、既定のコンテンツ アクセス アカウントが使用されます。または、クロール ルールを使用して、特定のコンテンツをクロールするときに使用する別のコンテンツ アクセス アカウントを指定できます。既定のコンテンツ アクセス アカウントを使用する場合でも、クロール ルールで指定した別のコンテンツ アクセス アカウントを使用する場合でも、使用するコンテンツ アクセス アカウントには、クロール対象のすべてのコンテンツに対する読み取りアクセス許可が必要です。コンテンツ アクセス アカウントに読み取りアクセス許可がない場合は、コンテンツはクロールされず、インデックスも作成されないので、クエリに使用できません。

クロール対象コンテンツのほとんどにアクセスできるアカウントを既定のコンテンツ アクセス アカウントとして指定することをお勧めします。セキュリティ上の理由から別のコンテンツ アクセス アカウントが必要な場合にだけ、それ以外のコンテンツ アクセス アカウントを使用します。

計画するコンテンツ ソースごとに、既定のコンテンツ アクセス アカウントではアクセスできない開始アドレスを特定し、その開始アドレスのクロール ルールを追加することを計画します。

もう 1 つ重要な点は、クローラーはホスト サーバーと同じ認証プロトコルを使用する必要があるということです。既定では、クローラーは NTLM を使用して認証を行います。必要に応じて、別の認証プロトコルを使用するようにクローラーを構成できます。

クレーム ベース認証を使用している場合は、クロール対象のすべての Web アプリケーションで Windows 認証が有効になっていることを確認します。

コネクタを計画する

クロールするすべてのコンテンツには、コネクタ (以前のバージョンではプロトコル ハンドラーという名称) を使用してアクセスする必要があります。SharePoint Server 2010 には、一般的なすべてのインターネット プロトコル用のコネクタが用意されています。ただし、SharePoint Server 2010 によってインストールされないコネクタが必要なコンテンツをクロールする場合は、そのコンテンツをクロールする前にサード パーティのコネクタまたはカスタム コネクタをインストールする必要があります。既定でインストールされるコネクタのリストについては、「既定のコネクタ (SharePoint Server 2010)」を参照してください。コネクタのインストール方法については、「コネクタをインストールする (SharePoint Server 2010)」を参照してください。

クロールの影響の管理を計画する

コンテンツをクロールすると、コンテンツをホストするサーバーのパフォーマンスが大幅に低下する可能性があります。これによる特定のサーバーへの影響は、ホスト サーバーにかかっている負荷、および使用率の通常時またはピーク時にサービス レベル アグリーメントを維持できるだけのリソース (特に CPU と RAM) がサーバーにあるかどうかによって異なります。

検索の管理者は、クローラー影響ルールを使用して、クローラーがクロール対象のサーバーに与える影響を管理できます。各クローラー影響ルールでは、1 つの URL を指定するか、URL パスにワイルドカード文字を使用して、そのルールを適用する URL のブロックを指定できます。次に、指定した URL に対して実行する同時ページ要求の数を指定するか、ドキュメントを一度に 1 つずつ要求して、次の要求まで指定した秒数の間待機することを選択します。

クローラー影響ルールでは、特定の開始アドレスまたは開始アドレスの範囲 (サイト名とも呼ばれる) からのコンテンツをクローラーが要求する頻度を指定します。クローラー影響ルールは、Search Service アプリケーションのすべてのコンテンツ ソースに適用され、要求頻度はクロール コンポーネントごとに適用されます。次の表に、クローラー影響ルールを追加または編集するときにサイト名に使用できるワイルドカード文字を示します。

特定のトップレベル ドメインにあるすべてのサイトに適用するクローラー影響ルールを作成できます。たとえば、*.com は, .com で終わるアドレスを持つすべてのインターネット サイトに適用されます。ポータル サイトの管理者が samples.microsoft.com のコンテンツ ソースを追加するとします。この samples.microsoft.com 専用のクローラー影響ルールを追加しない場合は、*.com のルールがこのサイトに適用されます。

組織内のコンテンツをクロールしている検索システムの管理者と連携して、サーバーのパフォーマンスと容量に応じてクローラー影響ルールを設定できます。ただし、ほとんどの外部サイトではこのような連携を行うことはできません。サーバー上の大量のコンテンツを要求したり、頻繁に要求を行ったりすると、クロールで使用されるリソースが多すぎる場合には、要求先のサイトの管理者によってアクセスが制限される可能性があります。初期展開時には、他のサーバーへの影響をできるだけ小さくしながら、インデックスの鮮度がサービス レベル アグリーメントを確実に満たすことができる頻度で十分な量のコンテンツをクロールするようにクローラー影響ルールを設定します。ファームの運用開始後に、クロール ログのデータに基づいてクローラー影響ルールを調整できます。

クロール ルールを計画する

クロール ルールは、Search Service アプリケーションのすべてのコンテンツ リソースに適用されます。クロール ルールを特定の 1 つの URL または URL のセットに適用して、次の処理を実行できます。

• 1 つ以上の URL を除外して、無関係なコンテンツがクロールされないようにする。これにより、サーバー リソースとネットワーク トラフィックの使用が低減し、検索結果の関連性が向上します。

• URL 自体をクロールしないで URL のリンクをクロールする。このオプションは、サイトに関連するコンテンツのリンクがあり、そのリンクを含んでいるページには関連する情報がない場合に便利です。

• 複合 URL をクロールできるようにする。このオプションを使用すると、疑問符を使用して指定されたクエリ パラメーターを含んでいる URL をクロールできます。サイトによっては、これらの URL に関連するコンテンツがない可能性があります。複合 URL によって無関係なサイトにリダイレクトされることが多いので、複合 URL から入手できるコンテンツに関連性があることがわかっているサイトに対してのみこのオプションを有効にすることをお勧めします。

• SharePoint サイトのコンテンツを HTTP ページとしてクロールできるようにする。このオプションを使用すると、ファイアウォールの内側にある SharePoint サイトをクロールしたり、クローラーが使用する Web サービスへのアクセスがクロール対象のサイトによって制限されている場合にクロールできます。

• 既定のコンテンツ アクセス アカウント、別のコンテンツ アクセス アカウント、クライアント証明書のうち、指定した URL のクロールに使用するものを指定する。

コンテンツのクロールではリソースと帯域幅が消費されるので、関連性のない可能性がある大量のコンテンツではなく、関連性があることがわかっている少量のコンテンツを対象とすることをお勧めします。初期展開後、クエリとクロール ログを確認して、コンテンツ ソースとクロール ルールを調整して、関連性を向上し、対象のコンテンツを増やすことができます。

ファーム レベルで管理される検索設定を計画する

ファーム レベルで管理されるいくつかの設定は、コンテンツのクロール方法に影響します。クロールを計画するときには次のファーム レベルの検索設定について考慮します。

• 連絡先の電子メール アドレス: コンテンツのクロールは、クロール対象のサーバーのリソースに影響を与えます。コンテンツをクロールする前に、クロールによって対象のサーバーに悪影響が生じた場合にその管理者が連絡できる、組織内の担当者の電子メール アドレスを構成設定で指定する必要があります。この電子メール アドレスは、クロール対象のサーバーの管理者のログに表示されるので、管理者はクロールによるパフォーマンスと帯域幅への影響が大きすぎる場合、または他の問題が発生した場合に連絡することができます。

  連絡先の電子メール アドレスは、必要な専門知識を持ち、要求にすぐに対応できる担当者のアドレスである必要があります。注意深く監視される配布リストのエイリアスを連絡先の電子メール アドレスとして使用することもできます。クロール対象のコンテンツが組織の内部に保存されているかどうかに関係なく、迅速な対応が重要です。

• プロキシ サーバー設定: コンテンツをクロールするときにプロキシ サーバーを使用するかどうかを選択できます。使用するプロキシ サーバーは、SharePoint Server 2010 展開のトポロジおよび組織内の他のサーバーのアーキテクチャによって異なります。インターネット コンテンツをクロールするときには、プロキシ サーバーを使用する必要性が高くなります。検索用にプロキシ サーバー設定を構成する方法については、「ファームレベル プロキシ サーバーの設定を構成する (SharePoint Server 2010)」および「プロキシ サーバーの設定を検索用に構成する (SharePoint Server 2010)」を参照してください。

• タイムアウト設定: タイムアウト設定を使用して、検索システムが別のサービスに接続しているときに待機する時間を制限します。

• SSL 設定: Secure Sockets Layer (SSL) 設定では、コンテンツをクロールするときに SSL 証明書が正確に一致する必要があるかどうかを指定します。

フェデレーションを計画する

フェデレーション検索とは、複数の Web リソースまたはデータベースの同時実行クエリのことで、エンド ユーザーには 1 つの検索結果ページが生成されます。フェデレーション対象を追加すると、エンド ユーザーはサーバーによってクロールされていないコンテンツをローカル システムで検索および取得できます。フェデレーション対象によって、クエリをリモート検索エンジンとフィードに送信できるようになります。このため、フェデレーション コンテンツがクロールされたコンテンツの一部であるかのように結果がエンド ユーザーに表示されます。

SharePoint Server 2010 では、次の種類のフェデレーション対象をサポートしています。

• **このサーバーのインデックスを検索する。**組織に SharePoint Server 2010 を実行しているサーバーがある場合、任意のローカル サイトまたはリモート サイトをフェデレーション対象として使用できます。たとえば、社内の人事部サーバーにある SharePoint サイトからのみ、従業員の連絡先情報を入手できるとします。そのサイトがクロールの範囲に含まれていない場合でも、検索センター サイトから検索を開始したユーザーが、そのユーザーに閲覧が許可されている従業員の連絡先情報の結果を取得できるように、フェデレーション対象を構成できます。次の条件が適用されます。

  1. フェデレーション対象は [このサーバーのインデックスを検索] に設定します。

  2. クエリ テンプレートは必要ありません。SharePoint Server 2010 では、オブジェクト モデルを使用してフェデレーション対象にクエリを実行します。

  3. 既定のサーバー認証が使用されます。

  4. 高度な検索クエリはサポートされていません。

• **OpenSearch 1.0 または 1.1。**OpenSearch 標準をサポートしているパブリック Web サイトをフェデレーション対象として使用できます。Bing などのインターネット検索エンジン、つまり、RSS または Atom プロトコルをサポートしている検索結果ページがこれに当たります。知的所有権に関わる技術研究について内部サイトを検索したユーザーに対して、パブリック Web サイトにある関連する研究情報も表示するとします。Bing 検索クエリのフェデレーション対象を構成すると、Web 検索結果が自動的に含まれます。次の条件が適用されます。

  1. クエリは、http://www.example.com/search.aspx?q=TEST のように URL として検索エンジンに送信できます。

  2. 検索結果は、RSS、Atom、または別の構成済み XML 形式で返されます。

  3. フェデレーション対象の機能、クエリ テンプレート、および応答要素は、フェデレーション対象に関連付けられている OpenSearch 記述 (.osdx) ファイルに格納されています。

  4. SharePoint Server 2010 固有の OpenSearch 拡張機能では、トリガーを追加する機能および XSL コードを検索結果と関連付ける機能がサポートされています。

  5. 検索結果に表示するメタデータの選択は、OpenSearch 場所によって決まります。

  OpenSearch の詳細については、https://www.opensearch.org/home (英語) を参照してください。

検索クエリがフェデレーション対象に送信されるとき、そのクエリは、クエリ テンプレートと呼ばれる形式で URL パラメーターとして送信されます。システムでは、結果を XML に整形し、検索センター サイトのユーザーに表示します。XML は、検索結果ページの Web パーツに可読テキストとして表示されます。検索結果ページの Web パーツは、フェデレーション検索結果 Web パーツ、上位フェデレーション検索結果 Web パーツ、または主要な検索結果 Web パーツとして追加および構成できます。既定では、検索結果ページには、3 つのフェデレーション検索結果 Web パーツがあります。

次の質問を使用して、フェデレーション検索結果をユーザーに表示するかどうかを決定します。

1. **特定の検索についてユーザー設定の結果を表示しますか。**フェデレーション対象が特定のクエリに一致する結果を確実に返すことができるようにするには、トリガー ルールを使用します。フェデレーション対象のトリガー ルールを作成すると、そのフェデレーション対象に関連付けられている Web パーツは、指定したパターンまたはプレフィックスに一致するユーザー クエリの結果だけを表示します。

2. **URL を使用してクエリに対して取得する結果を指定できますか。**フェデレーション対象を作成するには、クエリ テンプレートを指定する必要があります。クエリ テンプレートは、検索クエリを送信し、結果を XML として返すために必要な URL とパラメーターの組み合わせです。[フェデレーション対象の追加] ページの [クエリ テンプレート] フィールドにこの情報を追加するときには、([フェデレーション対象の追加] ページにある例と同じように) 正しい文字列の形式を使用する必要があります。正しくない場合、結果は検索結果プロバイダーから返されません。

3. **ユーザーはフェデレーション対象によって提供されるリンクにアクセスできますか。**組織内でインターネット リソースに対して制限付きアクセスだけが許可されている場合、インターネット検索エンジンをフェデレーション対象として使用すると、ユーザーは一部の検索結果を表示できないので、ストレスを感じる可能性があります。

4. **認証は必要ですか。**フェデレーション対象で認証が必要な場合、正しい資格情報を指定する必要があります。インターネット検索エンジンなど、多くのフェデレーション対象では資格情報は必要ありません。

フェデレーションの認証の種類を計画する

フェデレーション検索では、ユーザーごと、共通の資格情報など、複数の種類のユーザー認証を使用できます。ただし、ユーザーごとの認証で資格情報を収集するには、Kerberos 以外の認証の種類用の Web パーツ拡張機能が必要です。フェデレーション対象定義の認証および資格情報セクションで、フェデレーション対象の認証の種類を指定します。次のいずれかの認証の種類を指定できます。

• 匿名

  フェデレーション対象に接続するのに資格情報は必要ありません。

• 共通

  各接続で、同じ資格情報のセットを使用してフェデレーション対象に接続します。

• ユーザーごと

  検索クエリを送信したユーザーの資格情報を使用して、フェデレーション対象に接続します。

共通認証およびユーザーごとの認証の場合、次のいずれかの認証プロトコルも指定する必要があります。

• 基本

  基本認証は、HTTP 仕様で規定されており、ほとんどのブラウザーでサポートされています。

  Security Note
  基本認証を使用する Web ブラウザーでは、暗号化されていないパスワードは送信されません。悪意のあるユーザーは、ネットワーク上の通信を傍受し、公的に入手できるツールを使用して、パスワードを傍受および解読できます。このため、接続は安全である (専用回線や Secure Sockets Layer (SSL) 接続を使用する場合) という確信がない場合は、基本認証を使用しないことをお勧めします。

• ダイジェスト

  ダイジェスト認証は、World Wide Web コンソーシアム (W3C) の Web サイトで RFC 2617 仕様に定義されている HTTP 1.1 プロトコルを利用します。ダイジェスト認証では HTTP 1.1 の準拠が必要なので、一部のブラウザーではダイジェスト認証をサポートしていません。ダイジェスト認証が有効になっているときに HTTP 1.1 に準拠していないブラウザーがファイルを要求すると、ダイジェスト認証がクライアントでサポートされていないことが原因でその要求は拒否されます。ダイジェスト認証は、Windows ドメイン内でのみ使用できます。ダイジェスト認証は、Windows Server 2008、Windows Server 2003、および Microsoft Windows 2000 Server ドメイン アカウントでのみ動作し、パスワードを暗号化されたプレーンテキストとして保存することがアカウントに要求されることがあります。

• NTLM

  ユーザー レコードは、セキュリティ アカウント マネージャー (SAM) データベースまたは Active Directory データベースに保存します。各ユーザー アカウントは、LAN Manager 互換のパスワードと Windows パスワードの 2 つのパスワードに関連付けます。各パスワードは、暗号化して SAM データベースまたは Active Directory データベースに保存します。

• Kerberos (ユーザーごとの認証のみ)

  Kerberos プロトコルを使用すると、ネットワーク接続の一方のエンドポイントにいる相手は、もう一方のエンドポイントにいる相手はその相手が名乗るエンティティであることを確認できます。NTLM では、サーバーはクライアントの身元を確認できますが、クライアントはサーバーの身元を確認できません。また、サーバー間で他方のサーバーの身元を確認することもできません。NTLM 認証は、サーバーは信頼されると想定されるネットワーク環境を対象としています。

• フォーム ベース

  フォーム ベース認証の Cookie は、認証チケットのコンテナーにすぎません。各要求はチケットを Cookie の値として渡し、チケットはサーバーで認証対象のユーザーの身元を確認するために使用されます。ただし、Cookie を使用しないフォーム ベース認証では、チケットを暗号化して URL で渡します。Cookie を使用しないフォーム ベース認証を使用するのは、クライアント ブラウザーによって Cookie がブロックされる可能性があるためです。この機能は、Microsoft .NET Framework 2.0 で導入されました。

クレーム ベース認証を使用している場合は、クロール対象のすべてのコンテンツ ソースで Windows 認証を有効にする必要があります。SharePoint Server 2010 での認証方法の詳細については、「認証方法を計画する (SharePoint Server 2010)」を参照してください。

See Also

Concepts

現在の検索環境に関する情報を収集する (SharePoint Server 2010)
エンタープライズ検索チームと関係者を決定する (SharePoint Server 2010)