クライアント アクセス サーバーの名前空間について

  • [アーティクル]

 

適用先: Exchange Server 2010 SP2, Exchange Server 2010 SP3

トピックの最終更新日: 2011-11-08

Microsoft Exchange Server 2010 組織を計画するときの最も重要な決定事項の 1 つは、組織の外部名前空間の編成方法です。名前空間は、通常 DNS 内のドメイン名で表現される論理的な構造です。名前空間を定義するときには、さまざまな場所のクライアントとそのメールボックスを格納するサーバーについて考慮する必要があります。クライアントの物理的な場所に加え、クライアントがどのような方法で Exchange 2010 に接続するかも評価する必要があります。これらの質問に答えることで、必要となる名前空間の数を決定できます。通常、名前空間は DNS 構成と整合します。インターネットに直接接続する 1 台または複数のクライアント アクセス サーバーを含む地域の各 Active Directory サイトに、固有の名前空間を設定することをお勧めします。これは通常、mail.contoso.com や mail.europe.contoso.com などの A レコードによって DNS 内で表現されます。

Exchange 2010 組織を作成する前に、組織の構成方法および外部の名前空間の定義方法を決定する必要があります。名前空間に関する決定事項は、以下に影響を与えます。

  • DNS の構成方法。

  • Exchange 2010 を実行しているコンピューターとクライアントのコンピューターおよびデバイスとの間の通信を暗号化するために必要な証明書

  • Outlook Anywhere、Outlook Web App、POP3 クライアント、IMAP4 クライアントの使用時にクライアントがメールボックスにアクセスする方法

これらの決定を下すには、物理的および論理的ネットワーク構造の調査と、組織のトポロジの選択を行います。ここでは、さまざまなトポロジの概要および各トポロジが Exchange 組織に与える影響について説明します。

注意

ここでは内部の名前空間の計画については説明しませんが、Active Directory サイト内に負荷分散を展開する場合はこの計画が必要になることがあります。内部に負荷分散を展開することによる影響の詳細については、「プロキシとリダイレクトについて」を参照してください。

Exchange 2010 組織のモデル

ここでは、次の各トポロジの種類について説明します。

  • 統合データセンター モデル   このモデルは 1 つの物理サイトで構成されます。すべてのサーバーが 1 つの物理サイト内に配置され、mail.contoso.com などの 1 つの名前空間が設定されます。

  • プロキシ サイトを持つ単一の名前空間   このモデルは、複数の物理サイトで構成されます。1 つのサイトにのみ、インターネットに直接接続するクライアント アクセス サーバーが含まれます。他のサイトはインターネットに公開されません。このモデル内のサイトには、mail.contoso.com などの 1 つの名前空間のみが設定されます。

  • 単一の名前空間と複数のサイト   このモデルは、複数の物理サイトで構成されます。各サイトには、インターネットに直接接続するクライアント アクセス サーバーを含めることができます。また、インターネットに直接接続するクライアント アクセス サーバーを含む単一のサイトのみとなる場合もあります。このモデル内のサイトには、mail.contoso.com などの 1 つの名前空間のみが設定されます。

  • 地域別の名前空間   このモデルは、複数の物理サイトと複数の名前空間で構成されます。たとえば、ニューヨークにあるサイトは mail.usa.contoso.com、トロントにあるサイトは mail.canada.contoso.com、ロンドンにあるサイトは mail.europe.contoso.com という名前空間を持つ場合があります。

  • 複数フォレスト   このモデルは、複数の名前空間を持つ複数のフォレストで構成されます。このモデルを使用する組織は、たとえば、Contoso と ContosoOnline という 2 つのパートナー企業で構成されている可能性があります。名前空間には、mail.usa.contoso.com、mail.europe.contoso.com、mail.asia.contosoonline.com、および mail.europe.contosoonline.com が含まれる場合があります。

統合データセンター モデル

統合データセンター モデルは、ここで説明する最も単純なモデルです。このモデルは単一の物理サイトで構成されます。

統合データセンター モデルの利点は次のとおりです。

  • 複数名前空間のモデルに比べ、管理する DNS レコードは少なくなります。

  • 管理する証明書は少なくなります。Exchange クライアント アクセス サーバーとクライアントとの間の通信は、さまざまな方法で暗号化できます。暗号化方式として、サブジェクトの別名をサポートする単一の証明書を使用することをお勧めします。

    注意

    サブジェクトの別名はデジタル証明書の属性で、この属性を使用して、サイト管理者はサーバー証明書が必要なすべての名前空間を列挙する単一の証明書を構成できます。

    注意

    統合データセンター モデルの証明書を管理するその他の方法には、ワイルドカード証明書、複数の証明書、および SRV レコードの適切な構成があります。

  • エンド ユーザーは使用する名前空間を判断する必要はありません。すべてのエンド ユーザーは同じ名前空間および URL を使用して Microsoft Exchange にアクセスします。

統合データセンター モデルにはいくつかの欠点もあります。これらには次のようなものがあります。

  • このモデルは複数のデータセンターをサポートしません。

  • 帯域幅不足、大きな遅延、または使用率の高さが原因で地域のインターネット リンクが低速の場合、それらの地域のエンド ユーザーに対するパフォーマンスは低くなります。

プロキシ サイトを持つ単一の名前空間

このモデルは、単一の名前空間を使用する複数の物理サイトで構成されます。ISA Server コンピューターまたは別のファイアウォールの背後で、サイトのいずれかに、インターネットに直接接続する 1 台または複数のクライアント アクセス サーバーが配置されます。他のサイトには、インターネットに直接接続するクライアント アクセス サーバーは含まれません。

重要

境界ネットワークへのクライアント アクセス サーバーのインストールはサポートされていません。

注意

すべてのサイトがインターネット接続を持つ場合、このモデルはお勧めできません。実際のトポロジで、インターネット接続を持ち、近接してない複数の Active Directory サイトを使用している場合は、地域名前空間モデルの使用を検討します。

このモデルの利点は次のとおりです。

  • 複数名前空間のトポロジに比べ、管理する DNS レコードは少なくなります。これにより、操作の複雑さが軽減されます。

  • 管理する証明書は少なくなります。クライアント アクセス サーバーとクライアントとの間の通信は、サブジェクトの別名をサポートする単一の証明書を使用して暗号化できます。

  • エンド ユーザーは使用する名前空間を判断する必要はありません。すべてのエンド ユーザーは同じ名前空間および URL を使用して Microsoft Exchange にアクセスします。

プロキシ サイトを持つ単一の名前空間の展開にはいくつかの欠点もあります。これらには次のようなものがあります。

  • 一部のユーザーがプロキシ経由でメールボックス サーバーにアクセスします。メールボックス サーバーと同じ物理サイト内に存在しないクライアント アクセス サーバーにユーザーが接続しても、ユーザーはメールボックス サーバーと同じ物理サイト内に存在するクライアント アクセス サーバーに転送されます。プロキシが追加されるため、WAN のリンク コストが増加し、パフォーマンスは最適化されません。パフォーマンスに対する影響は、2 つの物理的なデータセンター間の距離と、転送される接続の数に応じて異なります。

    重要

    統合 Windows 認証のためには、転送先のサイト内のクライアント アクセス サーバーごとに、対象となる仮想ディレクトリを構成する必要があります。詳細については、「プロキシとリダイレクトについて」を参照してください。

複数のサイトを持つ単一の名前空間

このモデルは、単一の名前空間を使用する複数の物理サイトで構成されます。このモデルには 2 つの展開オプションがあります。1 つ以上のサイトの前面に配置されている ISA Server コンピューターを使用するか、クライアント アクセス サーバーのプロキシ サイトを使用することができます。各サイトの背後には、インターネットにアクセスできるサーバーを 1 台以上配置できます。このモデルには、着信トラフィックをインターネットに直接接続するサイト間で均等に配分する負荷分散ソリューションも必要です。

重要

境界ネットワークへのクライアント アクセス サーバーのインストールはサポートされていません。

ISA Server コンピューターを使用した展開

この構成では、クライアントのグループ メンバーシップを判断するため、ISA Server が接続の事前認証を行います。トラフィックは次に、構成されている公開ルールに基づいて、正しいサイトに転送されます。

このモデルの利点は次のとおりです。

  • 複数名前空間のモデルに比べ、管理する DNS レコードは少なくなります。これにより、操作の複雑さが軽減されます。

  • 管理する証明書は少なくなります。クライアント アクセス サーバーとクライアントとの間の通信は、サブジェクトの別名をサポートする単一の証明書を使用して暗号化できます。ISA Server コンピューターは、承認されたプロバイダーが発行する、外部の信頼された証明書を使用するように構成できます。ISA Server コンピューターとクライアント アクセス サーバーの間のトラフィックについては、内部で生成した証明書を使用してセキュリティで保護できます。

  • エンド ユーザーは使用する名前空間を判断する必要はありません。すべてのユーザーは同じ名前空間および URL を使用して Microsoft Exchange にアクセスします。

  • メールボックスは、外部の名前空間を変更しなくてもサイト間で移動できます。これにより管理者は、クライアントの構成を変更せずに、サイト間で柔軟にトラフィックの負荷を分散できます。

  • 必要に応じて、後の段階で地域別の名前空間を追加できます。異なる外部 URL を使用すれば、別の場所でこの同じモデルを繰り返し使用できます。

  • ISA Server 2006 のフォーム ベース認証は、組織固有の要件に合わせてカスタマイズできます。

このモデルを展開することには、次のような欠点があります。

  • ワイド エリア ネットワーク (WAN) の利用が増える可能性があります。増加する使用量は、ISA Server コンピューターの物理的な場所によって異なります。

  • ISA Server を正しく展開して構成する必要があります。

  • トラフィックが確実に正しいサイトに転送されるように、グループ メンバーシップを管理する必要があります。既定では、受信者管理者はセキュリティ グループを作成できないので、専任の Exchange 管理者がグループ メンバーシップを作成および更新できるように Active Directory の委任を構成する必要があります。グループを使用すると運用面のオーバーヘッドが増加します。メールボックスを作成または移動するときには、このことを考慮する必要があります。不要な認証要求が WAN 経由で送信されないようにするには、ISA Server コンピューターの近くにグローバル カタログ サーバーを配置することをお勧めします。

クライアント アクセス サーバーのプロキシ サイトを使用した展開

このモデルでは、外部から発信されたクライアント接続はすべて、ユーザー メールボックスが格納されていない Active Directory サイトに向かいます。これらの接続は次に、そのサイト内のクライアント アクセス サーバーによって、ユーザーのメールボックスが格納されているサイトに転送されます。

このモデルの利点は次のとおりです。

  • 複数名前空間のモデルに比べ、管理する DNS レコードは少なくなります。これにより、操作の複雑さが軽減されます。

  • 管理する証明書は少なくなります。クライアント アクセス サーバーとクライアントとの間の通信は、サブジェクトの別名をサポートする単一の証明書を使用して暗号化できます。ISA Server は、承認されたプロバイダーが発行する、外部の信頼された証明書を使用するように構成できます。ISA Server とクライアント アクセス サーバーとの間のトラフィックは、内部で生成された証明書を使用してセキュリティで保護されます。

  • エンド ユーザーは使用する名前空間を判断する必要はありません。すべてのエンド ユーザーは同じ名前空間および URL を使用して Microsoft Exchange にアクセスします。スプリット DNS が構成されている場合、このモデルを使用して内部の名前空間を統合することもできます。スプリット DNS が構成されていない場合、内部のクライアント要求はすべてファイアウォールに到達し、適切に転送されます。

  • メールボックスは、外部ユーザーの観点から見た名前空間を変更しなくても、サイト間で移動できます。これにより管理者は、サイト間で柔軟に負荷を分散できます。クライアントの構成を変更する必要がないため、障害が発生してサイト間でサービス全体を移動する必要がある場合にも便利です。

  • 必要に応じて、後の段階で地域別の名前空間を追加できます。異なる外部 URL を使用すれば、別の場所でこの同じモデルを繰り返し使用できます。

このモデルの欠点は次のとおりです。

  • WAN の使用率が増大することが多く、その使用率はインターネットに直接接続するサイト内のクライアント アクセス サーバーの物理的な場所によって異なります。

  • 追加のクライアント アクセス サーバーを正しく展開して構成する必要があります。

  • すべてのユーザーがプロキシ経由でメールボックスにアクセスします。ユーザーがプロキシ サイトのクライアント アクセス サーバーに接続する場合、このサーバーはメールボックス サーバーと同じ Active Directory サイト内にありません。ユーザーは、メールボックス サーバーと同じ Active Directory サイトにあるクライアント アクセス サーバーに転送されます。プロキシ処理が追加されるため、最適なパフォーマンスを得ることはできません。パフォーマンスに対する影響は、2 つの物理的なサイト間の距離に応じて異なります。

  • ユーザーがメールボックス サーバーと同じサイト内に存在しないクライアント アクセス サーバーに接続する場合、Windows SharePoint Services ライブラリおよび Windows ファイル共有にはアクセスできません。Windows SharePoint Services ライブラリおよび Windows ファイル共有にアクセスするにはユーザーのユーザー名とパスワードが必要になるためです。プロキシ シナリオでは、Windows SharePoint Services ライブラリおよび Windows ファイル共有への通信は、Exchange システム アカウントを使用して実行されます。このアカウントは、ユーザーのユーザー名とパスワードを認識しません。

    重要

    ユーザー メールボックスが格納されているサイトの各仮想ディレクトリの ExternalURL プロパティを $null に設定する必要があります。

    重要

    クライアント アクセス サーバーは、複数レベルのプロキシ処理をサポートしていません。ユーザー メールボックスを含むサイトはそれぞれ、専用のプロキシ サイト内のクライアント アクセス サーバーによってアクセスする必要があります。

    注意

    複数の場所を使用する場合は、追加のネットワーク構成が必要になることがあります。これには、ハードウェア負荷分散装置、複数の DNS レコード、ルートの冗長性の構成などが含まれます。物理的な展開は、組織のネットワーク トポロジによって異なります。

地域別の名前空間

各サイトに対して異なる名前空間を使用する複数サイトのモデルは、地域名前空間モデルと呼ばれます。このモデルの利点は次のとおりです。

  • 大部分のユーザーが、メールボックス サーバーと同じ Active Directory サイト内のクライアント アクセス サーバーに接続できるので、転送が減ります。これにより、エンド ユーザーの操作性とパフォーマンスが向上します。インターネットに直接接続するクライアント アクセス サーバーを含まないサイトにメールボックスがあるユーザーは、プロキシ処理されます。

このモデルの欠点は次のとおりです。

  • 複数の DNS レコードを管理する必要があります。

  • 複数の証明書を取得、構成、および管理する必要があります。

  • インターネットに直接接続する各サイトに ISA Server コンピューターまたはその他のファイアウォールが必要になるため、セキュリティの管理がさらに複雑になります。

  • 各ユーザーは、独自の地域名前空間に接続する必要があります。このため、ヘルプデスクへの問い合わせや必要なトレーニングが増加する場合があります。

    重要

    独自のインターネット接続を持つ複数の Active Directory サイトを含むトポロジでは、一般に地域名前空間モデルの使用をお勧めします。

複数フォレスト

このモデルは、複数の名前空間を持つ複数のフォレストで構成されます。このモデルを使用する組織は、Contoso と ContosoOnline という 2 つのパートナー企業で構成されている可能性があります。名前空間には、mail.usa.contoso.com、mail.europe.contoso.com、mail.asia.contosoonline.com、および mail.europe.contosoonline.com が含まれる場合があります。

各フォレストに地域名前空間モデルを実装して、最も高いレベルのパフォーマンスをエンド ユーザーに提供することを検討します。各フォレスト用の複数の証明書を管理する必要があります。

 © 2010 Microsoft Corporation.All rights reserved.