代替アクセス マッピングを計画する (Windows SharePoint Services)

  • [アーティクル]

この記事の内容 :

  • 代替アクセス マッピングについて

  • リバース プロキシ公開

  • 認証プロバイダとの代替アクセス マッピング統合

  • Web アプリケーション ポリシーとの代替アクセス マッピング統合

  • 代替アクセス マッピングおよび外部リソース マッピング

  • 代替アクセス マッピングのトラブルシューティング

代替アクセス マッピングは、Windows SharePoint Services 3.0 との通信中 (Windows SharePoint Services 3.0 Web サイトのホーム ページの参照中など) にユーザーを正しい URL に転送します。代替アクセス マッピングによって、Windows SharePoint Services 3.0 は Web 要求を正しい Web アプリケーションおよびサイトにマップでき、Windows SharePoint Services 3.0 は正しいコンテンツをユーザーに提供できます。

代替アクセス マッピングが実装された理由は、インターネット インフォメーション サービス (IIS) が受信する Web 要求の URL がエンド ユーザーが入力した URL と一致しないというインターネット展開シナリオがよくあるためです。これは、リバース プロキシの公開と負荷分散を含んだ展開シナリオで最もよく起こります。

注意

負荷分散を実現するために代替アクセス マッピングを構成する必要があります。ただし、通常、代替アクセス マッピングはサイト コレクションのホスト ヘッダーに適用されません。既定領域のパブリック URL は、すべてのユーザーに表示されるように適切なドメイン URL に設定されている必要があります。この操作を実行しない場合、Web サーバーの名前またはその IP アドレスが Windows SharePoint Services 3.0 内のページ間で渡されるパラメータで表示される場合があります。

代替アクセス マッピングについて

代替アクセス マッピングによって、5 つの認証領域のいずれかで内部 URL の要求を受信した Web アプリケーションは、その領域のパブリック URL へのリンクを含んだページを返すことができます。内部 URL とパブリック URL とのマッピングのコレクションに、Web アプリケーションを関連付けることができます。内部とは Windows SharePoint Services 3.0 が受信したときの Web 要求の URL を指します。パブリックとは外部からアクセスできる Web サイトの URL を指します。パブリック URL は、Windows SharePoint Services 3.0 が返すページで使用するベース URL です。内部 URL は、リバース プロキシ デバイスによって変更されている場合、パブリック URL と異なることがあります。

注意

ホスト名付きサイト コレクションでは、代替アクセス マッピングを使用できません。ホスト名付きサイト コレクションは自動的に既定領域に存在すると見なされ、要求の URL はエンド ユーザーとサーバーとの間で変更できません。

複数の内部 URL を単一のパブリック URL に関連付けることができます。マッピング コレクションには最高 5 つの認証領域を含められますが、それぞれの領域にはパブリック URL を 1 つしか割り当てられません。マッピング コレクションは次の認証領域に対応しています。

  • 既定

  • イントラネット

  • インターネット

  • カスタム

  • エクストラネット

リバース プロキシ公開

リバース プロキシとは、エンド ユーザーと Web サーバーとの間に配置するデバイスです。Web サーバーへのすべての要求は、最初にリバース プロキシ デバイスが受信し、その要求がプロキシのセキュリティ フィルタ処理を通過した場合は、プロキシがその要求を Web サーバーに転送します。リバース プロキシは、HTTPS (Hypertext Transfer Protocol over Secure Socket Layer) を使用して、インターネット経由の Web 要求を受信するなど高度な機能を実行できますが、サーバーへの要求の転送には HTTP を使用します。これは、「オフボックス SSL ターミネーション」と呼ばれます。リバース プロキシは、要求を最初に受信したポート以外のポート番号に要求を転送できます。リバース プロキシは、HTTP ホスト ヘッダー フィールドを変更することもできます。

Windows SharePoint Services 3.0 は多くのリバース プロキシ サーバーと互換性がありますが、次の例では、公開ルールはリバース プロキシ ソフトウェアである Microsoft Internet Security and Acceleration (ISA) Server 2006 のものです。ISA Server 2006 には、Windows SharePoint Services 3.0 の公開ルールの作成に役立つ公開ウィザードが含まれています。ルールは作成後いつでも変更できます。

注意

リバース プロキシ デバイスの中には、要求のパス (URL のホスト名とポート番号の後の部分) を変更して、たとえばユーザーが www.contoso.com/sharepoint/default.aspx に送信した要求を、http://sharepoint.perimeter.example.com/default.aspx として Web サーバーに転送できるものもあります。

これは非対称パスと呼ばれます。Windows SharePoint Services 3.0 は非対称パスをサポートしていません。URL のパスは、パブリック URL と内部 URL とで対称になっている必要があります。つまり、上記の例においては、逆プロキシ デバイスによって URL の "/sharepoint/default.aspx" の部分が変更されてはなりません。

リバース プロキシ サーバーを構成する

この例の最初の 2 つの図は変更した公開ルールを示しており、ここでは代替アクセス マッピングの柔軟性を示すために [元のホスト ヘッダーを、転送する] オプションを無効にしています。[元のホスト ヘッダーを、転送する] オプションがオンになっていると、代替アクセス マッピングを構成するときに、パブリック ホスト名が内部ホスト名としても機能します。

次の図はルールのプロパティ シートの [リスナ] タブと [パブリック名] タブを示しています。これらのプロパティで、Web アプリケーションへのアクセスに使用する URL が定義されます。この URL は、実際には Windows SharePoint Services 3.0 を実行しているサーバーに要求を転送するリバース プロキシ サーバーの URL です。

代替アクセス マッピングの計画 - リスナ [代替アクセス マッピング パブリック名] ダイアログ ボックス

エンド ユーザーの URL は、次の表に示すように、パブリック プロトコル、パブリック ホスト名、およびパブリック ポート番号から構成されます。

パブリック プロトコル パブリック ホスト名 パブリック ポート番号 パブリック URL

HTTPS

+ "://" +

www.contoso.com

+ ":" +

443

=

https://www.contoso.com

次の図はルールのプロパティ ページの [公開先] タブと [ブリッジ] タブを示しています。これらのプロパティで、Windows SharePoint Services 3.0 を実行しているサーバーへの要求の転送にリバース プロキシ サーバーが使用する URL が定義されます。

代替アクセス マッピング - サイト プロパティ 代替アクセス マッピングの計画 - ブリッジ

Windows SharePoint Services 3.0 を実行しているサーバーの URL は、次の表に示すように、内部プロトコル、内部ホスト名、および内部ポート番号から構成されます。

内部プロトコル 内部ホスト名 内部ポート番号 内部 URL

HTTP

+ "://" +

sharepoint.perimeter.contoso.com

+ ":" +

80

=

http://sharepoint.perimeter.contoso.com

この時点で、リバース プロキシ サーバーは、https://www.contoso.com でエンド ユーザーからの Web 要求を受信し、http://sharepoint.perimeter.contoso.com で Windows SharePoint Services 3.0 を実行しているサーバーにその要求を転送するように構成されます。

SharePoint Web アプリケーションを構成する

リバース プロキシ サーバー公開ルールを構成した後で、公開ルールに合わせて Web アプリケーションと代替アクセス マッピングを構成します。この構成を行うには、リバース プロキシ公開ルール専用の追加 IIS Web サイトに既存の Web アプリケーションを拡張します。この公開ルールの新しい Web アプリケーションも作成できます。入力する必要のある値はどちらの場合も同じです。

既存の Web アプリケーションを拡張するには、次の手順を使用します。

既存の Web アプリケーションを拡張する

  1. [管理ツール] で SharePoint サーバーの全体管理 Web サイトを開きます。

  2. サーバーの全体管理のホーム ページで、[アプリケーション構成の管理] をクリックします。

  3. [アプリケーション構成の管理] ページで、[SharePoint Web アプリケーション構成の管理] セクションの [Web アプリケーションの作成または拡張] をクリックします。

  4. [Web アプリケーションの作成または拡張] ページで [既存の Web アプリケーションの拡張] をクリックします。

  5. [別の IIS Web サイトへの Web アプリケーションの拡張] ページで Web アプリケーションを選択します。Web アプリケーションを選択したら、前の「リバース プロキシ サーバーを構成する」で定義した内部 URL プロパティに基づいて、ポート、ホスト ヘッダー、SSL のフィールドの値を入力します。次の図に示すように、「リバース プロキシ サーバーを構成する」で定義したパブリック URL を、[URL] フィールドに入力します。

    [代替アクセス マッピングの構成] ページ

  6. この Web アプリケーションの拡張を割り当てる代替アクセス マッピング領域を選択します。各 Web アプリケーションに利用できる領域は最高で 5 つあります。この例では、インターネット領域を使用します。すべての領域は同じ機能を提供しますが、既定領域は常に、サイト コレクション所有者への管理電子メール メッセージの送信など特定の機能に使用されます。

  7. IIS Web サイトを作成するには、[OK] をクリックします。

これらの手順を完了したら、代替アクセス マッピングでパブリック URL が正しく作成されたことを確認し、内部 URL を追加します。内部 URL がパブリック URL と同じ場合を除いて、これは手動で行う必要のある追加手順です。

[代替アクセス マッピング] ページを表示するには、次の手順を使用します。

[代替アクセス マッピング] ページを表示する

  1. [管理ツール] でサーバーの全体管理を開きます。

  2. サーバーの全体管理のホーム ページで [サーバー構成の管理] をクリックします。

  3. [サーバー構成の管理] ページで、[グローバル構成] セクションの [代替アクセス マッピング] をクリックします。

  4. [代替アクセス マッピング] ページで、リバース プロキシ サーバー経由で公開する Web アプリケーションを選択します。

この時点で、次の図に示すように、Web アプリケーションに割り当てられた代替アクセス マッピングの URL が表示されます。

[代替アクセス マッピング] ページ 1

リバース プロキシ公開ルールからのパブリック URL は、Web アプリケーションのインターネット領域に割り当てられています。Web アプリケーションのインターネット領域にリバース プロキシ公開ルールからの内部 URL を追加するには、次の手順を使用します。

リバース プロキシ公開ルールからの内部 URL を Web アプリケーションのインターネット領域に追加する

  1. [代替アクセス マッピング] ページで、[内部 URL の追加] をクリックします。

  2. 内部 URL の名前を入力し、パブリック URL に使用したものと同じ領域を選択します。この例では、インターネット領域を使用します。

  3. [保存] をクリックします。

この時点で、次の図に示すように、追加の URL が (リバース プロキシ公開ルールのパブリック URL と同じ領域にある) Web アプリケーションに割り当てられています。

[代替アクセス マッピング] - ページ 2

ユーザーが https://www.contoso.com を参照すると、リバース プロキシ サーバーが Web 要求を受信して、http://sharepoint.perimeter.contoso.com に転送します。続いて Windows SharePoint Services 3.0 は Web 要求を受信し、その要求の URL が http://sharepoint.perimeter.contoso.com であることを確認し、この URL が Contoso 社の Web アプリケーションに割り当てられていることを検出して、その Web アプリケーションのコンテンツを返します。さらに、http://sharepoint.perimeter.contoso.com の URL は、インターネット領域に割り当てられているので、Windows SharePoint Services 3.0 は、その領域のパブリック URL (https://www.contoso.com) を使用することによって、ページ上にリンクを生成します。このようにして、エンド ユーザーはページ上のリンクをクリックすると適切な URL に転送されます。

ロード バランサも、特に要求の負荷分散先の個々の Web サーバーの URL で、エンド ユーザーの元の URL を上書きする場合に、同様に機能します。これらの上書きされた URL を明らかにするには、個々の Web サーバーの URL に対応する代替アクセス マッピングを内部 URL として追加し、それらをエンド ユーザーのパブリック URL と同じ領域に関連付けるだけです。元の URL が保持されている場合は、単に元の URL をパブリック URL にします。

認証プロバイダとの代替アクセス マッピング統合

代替アクセス マッピングにより、5 つの異なる領域で Web アプリケーションを公開でき、各領域をバッキングする別々の IIS Web サイトを使用できます。

注意

これを、最高 5 つの異なる Web アプリケーションで同じコンテンツ データベースを共有することと誤解する人もいますが、実際には、1 つの Web アプリケーションしかありません。

これらの領域により、複数の URL を使用して同じ Web アプリケーションにアクセスできるだけではなく、複数の認証プロバイダを使用して同じ Web アプリケーションにアクセスすることもできます。

Web アプリケーションを領域に拡張する場合には、IIS が提供する Windows 認証を使用する必要があります。Web アプリケーションを領域に拡張した後、別の種類の認証を使用するように領域を変更できます。

領域の認証構成を変更するには、次の手順を使用します。

領域の認証構成を変更する

  1. [管理ツール] でサーバーの全体管理を開きます。

  2. サーバーの全体管理のホーム ページで、[アプリケーション構成の管理] をクリックします。

  3. [アプリケーション構成の管理] ページの [アプリケーション セキュリティ] セクションで、[認証プロバイダ] をクリックします。

  4. [認証プロバイダ] ページで、[Web アプリケーション] ボックスの一覧から Web アプリケーションを選択します。

  5. 認証構成を変更する領域の名前をクリックします。

    注意

    バッキング IIS Web サイトがある領域からのみ選択できます。IIS Web サイトは「既存の Web アプリケーションを拡張する」の手順でこれらの領域に割り当てられています。

  6. [認証の編集] ページの [認証の種類] セクションで、この領域に使用する認証の種類を選択します。

    • [Windows]

    • [フォーム]

    • [Web シングル サインオン]

  7. 変更する他の認証構成設定を修正し、[保存] をクリックします。

この時点で、他の領域の認証構成設定も変更できます。同じコンテンツにアクセスする異なる領域に対して完全に独立した認証設定を構成できます。たとえば、匿名でアクセスできるように一部のコンテンツを構成し、資格情報を必要とするように他のコンテンツを構成できます。匿名アクセスを有効にし、他のすべての形式の認証を無効にするようにある領域を構成して、匿名コンテンツへのアクセスだけを有効にできます。同時に、匿名アクセスを無効にし、NTLM 認証を有効にするように別の領域を構成して、認証されたアクセスだけを有効にできます。さらに、Windows Active Directory アカウントを使用するようにある領域を構成し、ASP.NET フォーム ベース認証を使用した非 Active Directory アカウントを使用するように別の領域を構成するなど、同じコンテンツへのアクセスに種類の異なるアカウントを使用できます。

Web アプリケーション ポリシーとの代替アクセス マッピングの統合

管理者は Web アプリケーション ポリシーを使用して、領域で公開されているすべてのサイトに対するアカウントおよびセキュリティ グループへのアクセスを許可または拒否できます。このポリシーはさまざまなシナリオで役立ちます。

たとえば、Windows SharePoint Services 3.0 検索クローラは、他の全員と同じ承認インフラストラクチャで承認を受ける必要があり、アクセス権を持っているコンテンツしかクロールできません。しかし、ユーザーによっては、検索で制限されたコンテンツをクロールして、権限のあるユーザーがそのコンテンツを検索結果で確認できるようにする必要があります。検索サービスは、Web アプリケーションのすべて読み取りポリシーを使用して、その Web アプリケーションの全コンテンツを読み取るためのアクセス許可をクローラに与えます。このようにして、サイト管理者が明示的にアクセス権を与えていないコンテンツを含め、すべての既存および将来のコンテンツをクロールし、インデックスを作成できます。

別の例は、ヘルプデスク担当者が、ユーザーをサポートするために Windows SharePoint Services 3.0 サイトへの管理者アクセス権を必要とする場合です。この場合、ヘルプデスク担当者アカウントにフル コントロール アクセス許可を与える Web アプリケーション ポリシーを作成して、Web アプリケーションの現在および将来の全サイトへの完全管理アクセス権をヘルプデスク担当者に与えることができます。

ポリシーは Web アプリケーションとその領域の両方に関連付けられているため、1 つの領域に適用したポリシーは他の領域に影響しません。これは、コンテンツを企業ネットワークとインターネットの両方に公開する場合に役立ちます。たとえば、企業ネットワークに割り当てられた Web アプリケーションの領域に対するフル コントロール アクセス許可を、ヘルプデスク担当者アカウントに与えているとします。だれかがそのアカウントを使用してインターネットからサイトにアクセスしようとした場合、URL が別の領域にあることが認識されるため、そのフル コントロール ポリシーは適用されません。したがって、サイトへの管理者アクセス権が自動的にそのアカウントに与えられることはありません。

代替アクセス マッピングおよび外部リソース マッピング

Windows SharePoint Services 3.0 では、Windows SharePoint Services 3.0 ファーム内でホストされていないコンテンツに、代替アクセス マッピング機能を拡張できます。この機能を構成するには、[代替アクセス マッピング] ページに移動して、[外部リソースへのマップ] をクリックします。すると、外部リソースのエントリを作成するように求められます。これは、別の Web アプリケーションと見なすことができます。外部リソースを作成した後、Web アプリケーションの場合と同じ方法で、別の URL と領域をその外部リソースに割り当てることができます。この機能は Windows SharePoint Services 3.0 では使用できませんが、Windows SharePoint Services 3.0 上に構築されたサード パーティ製品では使用できます。

たとえば、Office SharePoint Server 2007 の検索テクノロジは、ファイル共有、Web サイトなど、ファームの外部にあるコンテンツをクロールできます。そのコンテンツが別のネットワーク上の別の URL で使用できる場合、ユーザーの現在のネットワークの適切な URL を使用することによって、検索で結果を返します。代替アクセス マッピングの外部リソース マッピング テクノロジを使用することによって、検索は、ユーザーの領域に一致するように、検索結果における外部 URL を再マップできます。

代替アクセス マッピングのトラブルシューティング

次のガイダンスを使用して、代替アクセス マッピングに関して管理者が最もよく行う 6 つの間違いを避けます。

間違い 1: SharePoint を特殊な方法で展開していない限り、代替アクセス マッピングを構成する必要がないと想定する

代替アクセス マッピング関連の問題の最も一般的な原因は、代替アクセス マッピングを構成する必要があることを最初から管理者が認識していないことです。代替アクセス マッピングが Windows SharePoint Services 3.0 の新しい要件なので、このような誤解も無理はありません。すべての Windows SharePoint Services 3.0 管理者は、単純な展開であっても、確実に代替アクセス マッピングを正しく構成する必要があります。

次のどちらかの問題が発生している場合、代替アクセス マッピングは、正しく構成されていない可能性があります。

  • サイトで壊れた画像が表示される。

  • ファイル名を指定せずにサイトを参照すると (http://computer_name/site_name など)、DNS エラー メッセージやサーバーが見つからないことを示すエラー メッセージが表示されるが、サイト内のファイルを指定して直接参照すると (http://computer_name/site_name/default.aspx など)、サイトにアクセスできる場合は、代替アクセス マッピングの構成が間違っているためにこの問題が発生している可能性があります。

  • サイトを参照すると、http://コンピュータ名にリダイレクトされます。Windows SharePoint Services 3.0 が認識されない URL (または、代替アクセス マッピング用に構成されていない URL) からの要求を受け取り、Windows SharePoint Services 3.0 インフラストラクチャ更新プログラムをインストール済みである場合、Windows SharePoint Services 3.0 では、正しい Web アプリケーションの特定を試行し、次に、Web アプリケーションが返すページのリンクの同じベース URL を使用して要求に対応します。要求が代替アクセス マッピング用に構成されていない URL からであり、Windows SharePoint Services 3.0 インフラストラクチャ更新プログラムをインストール済みである場合、Windows SharePoint Services 3.0 はさらに、Windows イベント ログ内および Windows SharePoint Services の ULS ログ内に重要なエラーを作成し、Windows SharePoint Services 管理者に対して、認識されない URL に対して代替アクセス マッピングを構成するように通知します。

注意

エクストラネットの展開など、代替アクセス マッピングを逆プロキシやネットワーク ロード バランサと一緒に使用している Windows SharePoint Services 3.0 ファームに、Windows SharePoint Services 3.0 インフラストラクチャ更新プログラムをインストールした場合、一部のパブリック URL が応答しなくなることがあります。マイクロソフトではこの問題を認識しており、解決策を開発中です。この構成を使用する場合は、Windows SharePoint Services 3.0 インフラストラクチャ更新プログラムをインストールする前に、テスト環境を使用して、更新プログラムのインストール後も引き続きパブリック URL にアクセスできることを確認してください。

Web アプリケーション サービスを実行していないコンピュータを含め、複数のコンピュータで機能できる堅固で安定した API を Windows SharePoint Services 3.0 で実現するため、サイトの URL の解決はホスト ファイル、DNS、または IIS バインドには依存できません。代わりに、Windows SharePoint Services 3.0 は要求を受信するときに、代替アクセス マッピングだけを使用して URL 解決を実行します。Web 要求が Windows SharePoint Services 3.0 サーバーに到達できるように、ホスト ファイル、DNS、および IIS バインドが正しく構成されていることが必要ですが、次の例に示すように、代替アクセス マッピングの URL を構成することも必要です。

完全修飾ドメイン名 (FQDN)

Web アプリケーションに到達するために FQDN URL を使用している場合、DNS でそのドメイン名を構成する必要があります。また、代替アクセス マッピング用に対応する URL を構成する必要もあります。これが、エンド ユーザーがサイトに到達するために使用する URL である場合、これをパブリック URL にします。これが、リバース プロキシ サーバーがサイトに要求を転送するために使用する URL である場合、これを内部 URL にします。

注意

URL が内部のものである場合、エンド ユーザーの URL を同じ領域のパブリック URL として構成していることを確認します。

localhost

localhost は、ブラウザに https://localhost と入力すればローカル コンピュータ上でホストされている Web サイトに到達できる特別なホスト名です。ただし、localhost は、コンピュータのホスト ファイルにアクセスすることによって利用可能になるため、Windows SharePoint Services 3.0 では自動的に利用することはできません。https://localhost を Windows SharePoint Services 3.0 の有効な URL にする必要がある場合は、https://localhost を代替アクセス マッピングとして入力する必要があります。

IP アドレス

DNS またはホスト名解決がない環境で、IP アドレスによる URL だけを使用している場合は、さらにこれらの URL を代替アクセス マッピングとして入力する必要があります。

間違い 2: 代替アクセス マッピングの代わりにリバース プロキシ サーバーのリンク変換機能を使用できると想定する

管理者の中には、代替アクセス マッピングによってページのリンクが変更され、エンド ユーザーを正しいパブリック URL に転送することを理解していても、リバース プロキシ サーバーのリンク変換機能が類似機能を行うため、代替アクセス マッピングは必要ではないと想定している場合があります。この想定は次の複数の理由により、誤っています。

  • 互換性テストによれば、ISA Server 2006 などのリバース プロキシ サーバーのリンク変換機能では、パブリック URL を使用するようにすべての Windows SharePoint Services 3.0 リンクを変更するには十分ではありません。Windows SharePoint Services 3.0 は、多くの場所にさまざまなエンコード方法で、その URL を埋め込みます。リバース プロキシ サーバーは現在、すべての URL を検出して変更できるほどまで高度になってはいません。

  • 電子メール警告など、リバース プロキシ サーバー公開ルールを受けない Windows SharePoint Services 3.0 機能があります。代替アクセス マッピングを使用することによってのみ、電子メール警告内のリンクでユーザーの正しい URL を使用できます。

    重要

    公開ルールを使用してサーバーの全体管理を公開する場合は、必ずそのルールに対してリンク変換機能を無効にしてください。リンク変換機能が無効になっていないと、リンク変換機能によって代替アクセス マッピングの構成が妨げられる場合があります。

間違い 3: 代替アクセス マッピングで同じ URL を再使用しようとする、または同じ領域に URL を割り当てていない

これは、内部ネットワークとインターネットの両方に Web アプリケーションを公開するように Windows SharePoint Services 3.0 を構成する場合によくある間違いです。たとえば、既定領域の URL として "https://sharepoint" を使用した企業ネットワークで Web アプリケーションを構成し、それを www.contoso.com としてインターネットに公開する場合、https://sharepoint に要求を転送するようにリバース プロキシ サーバーを構成し、www.contoso.com をパブリック URL としてインターネット領域に追加するケースがあります。これは誤りです。企業ネットワークからのサイトへのアクセスは予想どおり機能し続けますが、インターネットからのアクセスはうまくいかず、https://sharepoint をポイントする複数のリンクが存在する場合があります。これは、2 つの URL が別々の代替アクセス マッピング領域に入力された結果、互いに関連付けられていないためです。

URL は代替アクセス マッピングで一度しか使用できず、前の例では、https://sharepoint の URL が企業ネットワークで既に使用されていました。インターネット ベースの要求を同じ Web アプリケーションに転送するには、リバース プロキシ公開ルールに対して、http://sharepoint.perimeter.contoso.com などの別の内部 URL を使用します。代替アクセス マッピングに https://sharepoint を残したまま、インターネット領域にパブリック URL として www.contoso.com を追加できます。www.contoso.com のパブリック URL と同じ領域 (インターネット領域) には、追加内部 URL として http://sharepoint.perimeter.contoso.com を追加する必要があります。同じ領域で両方を使用することによって、Windows SharePoint Services 3.0 は、その領域のパブリック URL を使用した正しいリンクを生成できます。

注意

使用する領域ごとで新しい IIS Web サイトに Web アプリケーションを拡張することをお勧めします。これが、バッキング IIS Web サイトになります。Microsoft から明確に指示されている場合以外は、複数の領域に同じ IIS Web サイトを再使用することはお勧めしません。

間違い 4: 代替アクセス マッピングでの更新によって、IIS バインドが自動的に更新されると想定する

Web アプリケーションが領域に拡張されても、Windows SharePoint Services 3.0 はその IIS バインドを変更しようとしません。ホスト ヘッダー バインドの追加、ポート番号の変更、または SSL ポートの追加によって IIS でこれらのバインドを変更した場合、Windows SharePoint Services 3.0 は変更を認識せず、代替アクセス マッピング URL を更新しません。同様に、SSL URL を追加するように代替アクセス マッピング URL を更新しても、一致する IIS バインドは自動的に更新されません。

IIS バインドで変更を行う必要がある場合、[アプリケーション構成の管理] ページで [IIS Web サイトからの SharePoint の削除] リンクを使用して、領域から Web アプリケーションを削除します。

注意

この操作は、IIS Web サイトとその領域だけを Web アプリケーションから削除します。Web アプリケーション自体も Web アプリケーションのコンテンツ データベースも削除しません。

その後、更新したバインドを使用して、Web アプリケーションを領域に再拡張できます。これは、SSL ポートを追加する場合にも当てはまります。HTTP および SSL ホスティングに同じ IIS Web サイトを再使用しないことをお勧めします。代わりに、専用の HTTP および専用の SSL Web サイトを拡張し、それぞれを独自の代替アクセス マッピングの領域および URL に割り当てます。

間違い 5: 検索でサイトをクロールできるように環境を構成し忘れる

エンド ユーザーがサイトに到達できるように代替アクセス マッピングとネットワークを構成した場合、Windows SharePoint Services 3.0 検索に対して代替アクセス マッピングとネットワークを構成する必要もあります。Windows SharePoint Services 3.0 Search サービスは、Web アプリケーションを参照して、そのコンテンツをクロールし、パブリック URL にアクセスできる必要があります。検索インデックス サービスを実行しているコンピュータがこれらのパブリック URL に到達できることを確認します。これは、NTLM 認証を使用しているコンピュータで特に重要になります。必要に応じて、プロキシ サーバーを使用するように、Windows SharePoint Services 3.0 Search サービス アカウントのプロキシ設定を構成します。この構成は、そのアカウントとしてコンピュータにログインし、Internet Explorer で LAN 接続設定を編集することによって行えます。

Internet Explorer で LAN 接続設定を編集するには、次の手順を使用します。

Internet Explorer で LAN 接続設定を編集する

  1. [コントロール パネル] で [インターネット オプション] を開きます。

  2. [インターネット オプション] プロパティ ページの [接続] タブで [LAN の設定] をクリックします。

  3. [ローカル エリア ネットワーク (LAN) の設定] ダイアログ ボックスで LAN 接続設定を編集し、[OK] をクリックします。

間違い 6: 入力ミスをする

代替アクセス マッピングの URL が正しく入力されていることを確認します。リバース プロキシ サーバーを使用している場合は、代替アクセス マッピングの URL が公開ルールの URL と一致していることを確認します。

このドキュメントをダウンロードする

このトピックは、簡単に読んだり印刷したりできるように、次のダウンロード可能なドキュメントに収められています。

入手可能なドキュメントの詳細な一覧については、「Windows SharePoint Services 3.0 テクニカル ライブラリ」を参照してください。

関連項目

概念

代替アクセス マッピングを構成する (Windows SharePoint Services)