Exchange Server 2007 の名前空間の計画について

適用先: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1

トピックの最終更新日: 2008-11-14

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

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

• DNS の構成方法
• Exchange 2007 を実行しているコンピュータとクライアントのコンピュータおよびデバイスとの間の通信を暗号化するために必要な証明書
• Outlook Anywhere、Outlook Web Access、POP3 クライアント、IMAP4 クライアントの使用時にクライアントがメールボックスにアクセスする方法

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

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

Exchange 2007 組織のモデル

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

• 統合データ センター モデル   このモデルは、単一の物理サイトで構成されます。すべてのサーバーが 1 つの物理サイト内に配置され、mail.contoso.com などの 1 つの名前空間が設定されます。
• プロキシ サイトを持つ単一の名前空間   このモデルは、複数の物理サイトで構成されます。1 つのサイトにのみ、インターネットに直接接続するクライアント アクセス サーバーが含まれます。他の物理サイトはインターネットに公開されません。このモデル内のサイトには、mail.contoso.com などの 1 つの名前空間のみが設定されます。
• 単一の名前空間と複数のサイト   このモデルは、複数の物理サイトで構成されます。各サイトにインターネットに直接接続するクライアント アクセス サーバーが含まれる場合もあれば、インターネットに直接接続する複数のクライアント アクセス サーバーを含むサイトが 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 クライアント アクセス サーバーとクライアントとの間の通信は、さまざまな方法で暗号化できます。サブジェクトの別名をサポートする単一の証明書を使用することをお勧めします。サブジェクトの別名をサポートする証明書の詳細については、「統合通信は、Exchange 2007 と通信サーバー 2007 の Partner を証明書」を参照してください。

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

  注 :
  統合データ センター モデルの証明書を管理するその他の方法には、ワイルドカード証明書、複数の証明書、および SRV レコードの適切な構成があります。このような方法の詳細については、「White Paper: Exchange 2007 Autodiscover Service」 (英語) を参照してください。

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

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

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

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

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

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

次の図は、このモデルを示したものです。

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

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

• 複数名前空間のトポロジに比べ、管理する DNS レコードは少なくなります。これにより、操作の複雑さが軽減されます。
• 管理する証明書は少なくなります。クライアント アクセス サーバーとクライアントとの間の通信は、サブジェクトの別名をサポートする単一の証明書を使用して暗号化できます。
• エンド ユーザーは使用する名前空間を判断する必要はありません。すべてのエンド ユーザーは同じ名前空間および URL を使用して Microsoft Exchange にアクセスします。

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

• 大部分のユーザーが、プロキシ経由でメールボックス サーバーにアクセスします。メールボックス サーバーと同じ物理サイト内に存在しないクライアント アクセス サーバーにユーザーが接続しても、ユーザーはメールボックス サーバーと同じ物理サイト内に存在するクライアント アクセス サーバーに転送されます。プロキシが追加されるため、WAN のリンク コストが増加し、パフォーマンスは最適化されません。パフォーマンスに対する影響は、2 つの物理的なデータ センター間の距離と、転送される接続の数に応じて異なります。
• ユーザーがメールボックス サーバーと同じサイト内に存在しないクライアント アクセス サーバーに接続する場合、Windows SharePoint Services ライブラリおよび Windows ファイル共有にはアクセスできません。Windows SharePoint Services ライブラリおよび Windows ファイル共有にアクセスするにはユーザーのユーザー名とパスワードが必要になるため、エラーが発生します。プロキシ シナリオでは、Windows SharePoint Services ライブラリおよび Windows ファイル共有への通信は、クライアント アクセス サーバーのシステム アカウントを使用して実行されます。このアカウントは、ユーザーのユーザー名とパスワードを認識しません。
• POP3 または IMAP4 プロトコルを使用するクライアントは、接続先のクライアント アクセス サーバーがメールボックス サーバーと同じサイトにない場合、メールボックスにアクセスできなくなります。POP3 接続と IMAP4 接続は、サイト間で転送できません。

  重要 :
  統合 Windows 認証のためには、転送先のサイト内のクライアント アクセス サーバーごとに、対象となる仮想ディレクトリを構成する必要があります。

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

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

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

ISA Server を使用した展開

次の図は、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 サイトを持つトポロジの展開はお勧めしません。トポロジで複数の Active Directory サイトを使用する場合は、地域別の名前空間モデルを使用することをお勧めします。

  注 :
  複数のサイトを持つ単一の名前空間を展開する場合、リダイレクトを無効にしてプロキシを適用するには、インターネットに直接接続するクライアント アクセス サーバーで仮想ディレクトリ用の ExternalURL 値をクリアする必要があります。

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

次の図は、このモデルを示したものです。

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

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

• 複数名前空間のモデルに比べ、管理する DNS レコードは少なくなります。これにより、操作の複雑さが軽減されます。
• 管理する証明書は少なくなります。クライアント アクセス サーバーとクライアントとの間の通信は、サブジェクトの別名をサポートする単一の証明書を使用して暗号化できます。ISA Server サーバーは、承認されたプロバイダが発行する、外部の信頼された証明書を使用するように構成できます。また、ISA Server とクライアント アクセス サーバーの間のトラフィックについては、内部で生成した証明書を使用してセキュリティで保護できます。
• エンド ユーザーは使用する名前空間を判断する必要はありません。すべてのエンド ユーザーは同じ名前空間および URL を使用して Microsoft Exchange にアクセスします。スプリット DNS が構成されている場合、このモデルを使用して内部の名前空間を統合することもできます。スプリット DNS が構成されていない場合、内部のクライアント要求はすべてファイアウォールに到達し、適切に転送されます。
• メールボックスは、外部ユーザーの観点から見た名前空間を変更しなくても、サイト間で移動できます。これにより管理者は、サイト間で柔軟に負荷を分散できます。クライアントの構成を変更する必要がないため、障害が発生してサイト間でサービス全体を移動する必要がある場合にも便利です。
• 必要に応じて、後の段階で地域別の名前空間を追加できます。異なる外部 URL を使用すれば、別の場所でこの同じモデルを繰り返し使用できます。

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

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

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

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

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

• POP3 または IMAP4 プロトコルを使用するクライアントは、接続先のクライアント アクセス サーバーがメールボックス サーバーと同じサイトにない場合、メールボックスにアクセスできなくなります。POP3 アクセスと IMAP4 アクセスは、サイト間で転送できません。

  重要 :
  ユーザー メールボックスが格納されているサイトの各仮想ディレクトリの 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 が含まれる場合があります。

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

詳細情報

名前空間の計画および Exchange サーバーのセキュリティに対する影響の詳細については、以下のトピックを参照してください。

• プロキシとリダイレクトについて
• クライアント アクセス サーバーの SSL について

参照している情報が最新であることを確認したり、他の Exchange Server 2007 ドキュメントを見つけたりするには、Exchange Server TechCenter を参照してください。