AAM と独自の Web アプリ上の SearchCentre

Question

まず、SP2013 に向けてオンプレミスで OOTB の方法を探しています。追加のヘッダーをハックすることでこれを行うことができます。目的は、AAM を使用する複数の Web アプリに単一のグローバル検索センターを持たせることです。結局のところ、複数の検索センターが必要な場合、グローバル検索センターを持つことに何の意味があるのでしょうか?- とりあえずそのようにしました

トポロジは次のとおりです。

内部 ユーザーは以下を使用します:

• intranet.companyname.net -> デフォルトゾーン

外部の ユーザーは信頼できるプロバイダーを通じてアクセスします。

• extranet.companyname.net -> インターネット ゾーン

イントラネットには、エクストラネット アドレスからアクセスできないサイトがいくつかありますが、すべてのエクストラネットにはイントラネットからアクセスできます。ここまではシンプル。

がある 三つ ウェブアプリ:

• ポータル
• 私のサイト
• 検索センター

各 Web アプリには 2 つのアドレスの AAM があります イントラネット そして エクストラネット

• イントラネット.会社名.net / エクストラネット.会社名.net
• my.intranet.companyname.net / my.extranet.companyname.net
• search.intranet.companyname.net / search.extranet.companyname.net

しかし、検索サービス アプリケーションに、インターネット ゾーン ユーザー (エクストラネット) を検索アドレスのエクストラネット フォームに送信し、それに応じて検索結果を変更するように指示する方法を見つけることは一生できません (項目へのリンクは、それらはインデックス付けされており、絶対的なものです）

では、2013 年にこれをどのように実現するか、ゾーンに応じてグローバル検索 URL を動的に変更するようにすべてのサイトに指示するか、ユーザーごとの結果を動的に変更するにはどうすればよいでしょうか。

ゾーンが検索でピックアップされることを期待していますが、それは疑わしいです。

[アップデート]

からのコメントに答えるには マイク・オリザック これを確実に達成する唯一の方法は、3 つのサイト コレクションすべてに対して 1 つの Web アプリケーションを使用することです。ご存知のとおり、MySites のベスト プラクティスでは、MySites を別の Web アプリケーションに分離することが求められています。これでは、アイテムの URL やさまざまなゾーンの問題も解決されません。(ただし、これを回避するには、サーバー名マッピングを使用してエクストラネット アドレスを常に使用するように強制することもできます)。

それでは、この問題に対する解決策は何になるでしょうか?単一の Web アプリケーションに移行することは望ましい解決策ではないため、MySite アプリケーション上に SearchCentre を作成してアプリケーションを作成する必要があります。上で述べたように、私の本ではこれに対する 3 つの Web アプリ ソリューションがベスト プラクティス期間です。サイト コレクション タイプごとに 1 つの Web アプリを作成し、サイトを完全に分離します。

答える テレスコ 2 つの WFE、フェールオーバー WFE として機能するクロール サーバー、分散キャッシュ サーバー、2 つのアプリケーション サーバー、およびデータベース クラスターがあります。中規模展開の場合、ボックス全体に合計 98 GB の RAM と 20 個の CPU が搭載されており、この設計はすぐに拡張可能であり、ファームにさらに追加することができます。

【バウンティ報酬の更新】

答えは、トポロジに準拠し、当面の問題を解決するための手順の概要 (すぐに使用できる場合のみ) を必要とします。これは、検索コントロールと検索結果からの検索 URL を制御するコードを少し加えて、私が少し手を加えてすでに実行されています。しかし、これは OOTB であるべきもので行う必要はありません。500pt。これをやろう。

[アップデート]問題の半分が解決されました:URL の問題を解決するには、AAM を使用する代わりに、Web アプリを新しいアドレスに拡張します。

Answer 1

これは、AAM のみを指定するのではなく、各 Web アプリケーションを拡張することで実現できます。現在の段階からの手順は次のようになります。

• 各 Web アプリで AAM を削除し、デフォルトの AAM のみを残します
• ISS 上で、それぞれの Web サイトの各 SharePoint サーバー上の削除された AAM の IIS バインディングを削除します。
• [全体管理] => [Web アプリケーションの管理] で、一度に 1 つの Web アプリを選択し、それぞれの AAM を指定して各ゾーンに拡張します。
• コンテンツ ソースが各 Web アプリのデフォルトの AAM URL をポイントしていること、およびそれらの Web アプリで NTLM 認証プロバイダーが有効になっていることを確認してください。
• フルクロールを実行する

それもそのはずです。検索結果は、アクセス元の AMM に一致するリンクを返します。このソリューションはトポロジとは関係がなく、どのトポロジでも機能します。

Answer 2

コードなしでは SharePoint 側からは不可能です。これは、IIS と URL 書き換えモジュールを介して実行できます。@Miguel Lima が提供するのと同じ拡張 Web アプリ トポロジを引き続き利用できます。

Microsoft は SharePoint URL の書き換えをサポートしていませんが、リダイレクト機能を使用してこれを実現できます。

外部から内部検索アドレスにアクセスすると外部ページにリダイレクトされ、その逆も同様のルールを作成するだけです。検索センターの URL は適切な AAM ですでに拡張されているため、リダイレクト後に結果が適切に返されるはずです。

リダイレクトも非常に迅速に行われるため、ほとんどの場合、ユーザーは気付かないでしょう。

そうは言っても、私はサイト コレクションごとに専用の検索センターのアプローチを支持します。長期的なケアと栄養補給は非常に簡単で、コンテンツ データベースに保存したものとは別に IIS 構成をバックアップすることを心配する必要はありません。