概要
この章では、Microsoft® Windows® 2000 Active Directory® サービスの論理構造を設計するにあたっての検討事項について説明します。こうした検討事項には、フォレストとドメインを分割するかどうか、サイトをどのように計画すべきかなどが含まれます。また、ドメイン コントローラ、グローバル カタログ サーバー、操作マスタ、DNS サーバー、ブリッジヘッド サーバーの配置についても説明します。この章を読み終えると、どのような場合にフォレストとドメインを分割すべきかがわかり、各種サーバーをブランチとハブ サイトのどちらに配置するかを判断する方法も理解できます。

この文書に記載されている情報は、発行時点で議論されている問題点に関する Microsoft Corporation の最新の見解を示しています。Microsoft は変化する市場状況に対処しなければならないため、本書の内容を Microsoft の確約事項として解釈してはならず、Microsoft は発行日以降に提示された情報の精度についてはいかなるものであれ保証いたしません。

この文書は、情報の通知のみを目的としており、Microsoft は本書に記載されている情報について明示的にも暗黙的にも一切の保証をいたしません。

適用し得るすべての著作権法を順守する責任はユーザーにあります。本書中のいかなる部分も、Microsoft の書面による許可なしには、いかなる目的のためであれ、いかなる形態、手段 (電子的、機械的、コピー機の使用、記録など) によっても複製、検索システムへの格納、または伝送してはなりません。ただしこれは、著作権法上のお客様の権利を制限するものではありません。

この文書の内容に関する特許、特許出願、商標、著作権、およびその他の知的財産は、Microsoft が所有します。Microsoft との書面によるライセンス契約に明記されていない限り、本書の提供が、以上の特許、商標、著作権、あるいはその他の知的財産権の利用を認めるものではありません。

© 2002 Microsoft Corporation. All rights reserved.

Microsoft、Windows、Active Directory は、米国およびその他の国または地域における Microsoft Corporation の登録商標または商標です。

トピック

 はじめに
 プロセス フローチャート
 構造の設計
 ドメイン コントローラとグローバル カタログの配置
 DNS 設計時の推奨事項
 まとめ

はじめに

この章では、フォレスト構造、ドメイン構造、サイト構造を決定するために必要な検討プロセスについて説明します。また、これらの構造によって、ドメイン コントローラ、グローバル カタログ サーバー、ドメイン ネーム システム (DNS) サーバー、ブリッジヘッド サーバー、操作マスタ (FSMO (Flexible Single-Master Operations) ともいう) の配置がどのような影響を受けるかについても説明します。

リソース要件

このフェーズでは、以下のチームから選ばれたメンバの参加が必要となります。

• Windows 2000 Active Directory アーキテクチャ

• Windows 2000 Active Directory 管理

• インフラストラクチャ管理

• ネットワーク管理 － DNS およびその他のネットワーク情報を提供

必要事項
使用しているサブネット、ハブサイトへの接続、接続の種類および速度など、社内ネットワークに関する詳細な情報が必要となります。システム関連の作業の委任に関する社内の管理体系についても詳しい知識が必要です。

ジョブ ヘルパ 1 を利用すると、ネットワーク情報を簡単に集めることができます。

ジョブ ヘルパ 1 を使用して収集したネットワーク情報に加え、各フェーズで計画の内容を図式化するためにMicrosoft® Visio® のようなツールも必要となります。

前提知識
このガイドは、Microsoft® Windows® 2000、Windows 2000 Active Directory® サービス、および DNS に関する基本的な知識を備えた方を対象としています。詳細については、第 1 章「ブランチ オフィス環境での Active Directory 展開計画の概要」の最後にある「参考資料」の項を参照してください。

プロセス フローチャート

構造の設計

構造設計では、Active Directory ブランチ オフィス環境の 2 つの要素、フォレストとドメインの分割について計画します。

フォレストの分割

Active Directory 環境をフォレストに分割する理由には、経営、組織、および法律上の制約とオブジェクト数が過剰であることの 2 つがあります。前者は分割の正当な理由となることが多いのに対し、後者が理由となることは多くありません。

経営 / 組織 / 法律上の制約
多くの組織には複数の独立したビジネスユニットがあり、それらの間では共通の枠組みや全社的なリソース管理方針を設けることが不可能であったりします。このような組織では、複数のフォレストを配置するのが一般的です。複数のフォレストを管理することになると、必要な管理業務やが激増し、要求事項は予想のつかない増え方をします。Microsoft メタディレクトリ サービスなどのメタディレクトリを使用しなければ、単一ディレクトリ サービスの利点を引き出すことはできません。社内ネットワークに複数の異なるセキュリティを設定する必要性がある場合は、フォレストに分割するのではなくドメインに分割することで、セキュリティ境界を設定でき、単一フォレスト環境の利点を失うことなく複数のフォレストを実装できます。

過剰なオブジェクト
オブジェクト数が 1 つのフォレストの容量を超えることはほとんどありません。実際のところ、フォレストのオブジェクト数を制限するのは、メモリやディスク容量です。

ドメインの分割

次の表は、複数のドメインを作成すること (このガイドでは "ドメインの分割" といいます) の長所と短所をまとめたものです。

長所	短所
セキュリティ境界が定義される。	複数のドメインを管理することによって業務上の負担が増加する。
ドメイン コントローラ データベースのサイズが縮小される。	グローバル カタログのサイズが大きくなる。
ファイル複製のトラフィックが減少する。	ドメイン間でユーザーを移動する場合、組織単位 (OU) 間でユーザーを移動するより手間がかかる。
複製が必要な変更が少なくなるため、ドメイン ネットワークのトラフィックが減少する。	ドメイン数の増加により、GC 複製の量が増加する。
グループ ポリシー、セキュリティ、委任の定義が 1 回だけで済む。	グループ ポリシー、セキュリティ、委任をドメインごとに定義しなければならない。

前に説明したとおり、1 つのドメインでは要求を満たすことができず、複数のセキュリティ設定が必要となることがあります (組織の一部が通常より長いパスワードを必要とする場合など)。

Active Directory 環境のオブジェクト数に基づいて、ドメインを分割するかどうかを決定する場合もあります。

複数ドメインの使用がネットワークに与える影響
ネットワークを複数のドメインに分割すると、ドメイン名前付けコンテキストの 複製で複製されるデータの量は減少しますが、複製の対象となるグローバル カタログ データは増加します。複数のドメインを使用した場合、オブジェクトの生成および変更に伴うネットワーク トラフィックは減少します。どれくらい減少するかを確認するためには、オブジェクトの生成による複製トラフィックとオブジェクトの変更によるトラフィックを区別する必要があります。

複数ドメイン環境でオブジェクトを作成すると、各オブジェクトのコピーが、同じドメイン内のほかのドメイン コントローラと、同じフォレスト内のほかのドメインに属すグローバル カタログ サーバーに複製されます。ネットワーク トラフィックの増加を抑制するには、属性のサブセットだけをグローバル カタログ サーバーに複製します (オブジェクトを作成するドメインのドメイン コントローラであるグローバル カタログ サーバーがオブジェクトの完全なコピーを受け取ります)。目安として、ドメイン名前付けコンテキストのデータの約 50% がほかのドメインのグローバル カタログ サーバーに複製されると見ることができます。(Active Directory 複製トラフィックの詳細については、Microsoft Press 社の「Notes from the Field」シリーズに含まれる『Building Enterprise Active Directory Services』を参照してください。)

オブジェクトの作成
あるブランチ オフィス展開において、10,000 人のユーザーを作成し、各ブランチ オフィスにドメイン コントローラがあると仮定します。シングルドメイン モデルを採用した場合、10,000 人のユーザーすべてが低速リンクを介して全ブランチ オフィスに複製されます。したがって、ここでは 10,000 人のユーザーの複製が基準となります。これが単一ドメイン ネットワーク トラフィックの 100% に当たります。

しかし、5 つのドメインを作成し、それらのドメインに 10,000 人のユーザーを均等に分散すると、ブランチ オフィスにグローバル カタログ サーバーを配置しない場合、ブランチ オフィスには低速リンクを介して 2,000 人のユーザーしか複製されません。これによって、ドメイン ネットワークのトラフィックは最初のシナリオの 20% にまで減少します。

一方、5 つのドメインを作成し、ブランチ オフィスにグローバル カタログ サーバーを配置すると、ドメイン ユーザー 2,000 人のネットワーク トラフィック (ドメイン コントローラ トラフィック) に同じフォレストのほかのドメインからのユーザー 8,000 人 (小さな属性セットのグローバル カタログ トラフィック) が加わり、トラフィックはシングルドメインの場合の 60% にまで減少します。この計算は次のような式に基づいています。((10000 人のユーザーのうちブランチ オフィス ドメインに属す 2000 人) = 20 %) + ((残り 4 つのドメインに属す 8000 人 x 50%) = 40%) = 60%

オブジェクトの変更
オブジェクトの変更に伴う複製トラフィックの場合は、違いがさらに大きくなります。パスワードの変更やユニバーサル グループ メンバシップ以外のグループ メンバシップなど、ほとんどのオブジェクト変更操作はグローバル カタログ サーバーには複製されません。(ただし、メッセージング システムが使用する簡易メール転送プロトコル (SMTP) など、ディレクトリ対応のアプリケーションが使用し、値があまり変化しない一部の属性を除きます。)

例として、100 人のユーザーが同じ日にパスワードを変更したことによって発生するトラフィックについて考えてみます。このとき、パスワードは低速リンクを介してすべてのブランチ オフィスに複製されると仮定します。この場合、約 120 KB のネットワーク トラフィックが発生します。(この計算は、『Building Enterprise Active Directory Services』の 161 ページにある「同時に変更されるパスワードの数を P とすると、複製されるバイト数は 943 x P + 29,345 である」という公式に基づいています。) ドメインを 5 つに分割し、ユーザーを均等に分散すると、ドメイン コントローラには 20 のパスワードだけが複製されることになり、トラフィックは約 45 KB となります。この場合、パスワードの変更はグループ カタログ サーバーには複製されないため、ブランチ オフィスにグローバル カタログがあっても関係ありません。

ブランチ オフィス環境を地域的なドメインに分割すると、ネットワーク トラフィックの減少にはつながりますが、新しいドメインを追加するたびに管理および構成の作業が必要となります。複数のドメインを使用することには、次のようなデメリットがあります。

• すべてのドメインでグループ ポリシーを定義しなければなりません。

• セキュリティおよび委任の設定がドメイン間で伝達されません。

• ブリッジヘッド サーバーの構成および選択が複雑になります。

プランニングの基本原則 : 簡潔さを保つこと
プランニングの基本原則「簡潔さを保つこと」は、ブランチ オフィス環境の構造設計にも当てはまります。ワイド エリア ネットワーク (WAN) によってドメインをサポートできる場合は、シングルドメインの配置をお勧めします。WAN の容量に余裕がない場合は、ドメインの数を必要最小限にとどめてください。

構造上の検討事項の 1 つとして、ドメイン内のサイト数を決定することがあります。サイトを識別することによって、管理者はドメイン コントローラ間およびグローバル カタログ サーバー間の複製トラフィック パターンを制御することができます。どのサブネットがどのサイトに属しているかを確認するためには、ドメイン コントローラ、グローバル カタログ サーバー、および DNS サーバーがある場所を特定する必要があります。

ドメイン コントローラとグローバル カタログの配置

ブランチ オフィスなどの分散型環境では、ドメイン コントローラとグローバル カタログ サーバー (GC) の配置と、それによって形成される複製トポロジを決定することが、最大の検討事項となります。ドメイン コントローラを配置する場所の数によって、必要な計画および構成の作業内容が変わります。このような場所の数が非常に多い (100 を超える) 場合には、サーバーと接続オブジェクトを構成するときに、知識整合性チェッカー (KCC) のトポロジ自動生成機能ではなく、スクリプトやサードパーティのツールを使用する必要があります。したがって、ドメイン コントローラを配置する場所とその数を決定することは、プランニング プロセスにおける最初の重要な作業の 1 つといえます。

この決定の基準となるのは、1 つの場所のユーザー数と必要なサービスです。複製トラフィック、ログオン プロバイダの有無、セキュリティ上の問題を考慮に入れると、通常はドメイン コントローラを各ブランチ オフィスに配置することになります。後で説明するように、場合によってはブランチ オフィスにドメイン コントローラを配置しないことがあります。その場合、追加的な構成および管理の作業が必要となることがあります。

プロセス フローチャート

セキュリティ上の問題

どの Active Directory ドメイン コントローラにもドメイン データベースの読み取りおよび書き込み可能なコピーがあり、このデータベースには、ユーザー、グループ、その他の機密性が高いセキュリティ情報が保存されています。ドメイン コントローラにおいては、権限のある担当者だけが物理的にアクセスできるように、物理的なセキュリティを確保することが重要です。ブランチ オフィス環境では、このようなセキュリティを保証できない場合もあります。物理的なセキュリティを保証できない場所にドメイン コントローラを配置するのは、賢明ではありません。

ブランチ オフィスのユーザー数が 10 人未満の場合

ユーザー数が 10 人に満たないブランチ オフィスには、ドメイン コントローラを配置する必要はありません。ただし、このようなブランチ オフィスの計画に Microsoft Exchange 2000 Server のサービスが含まれていないことを前提とします。この場合、ログオン トラフィックは WAN リンクを経由することが必要です。その他の方法については、後の「ブランチ オフィスにドメイン コントローラを配置しない場合の代替ソリューション」を参照してください。

ブランチ オフィスのユーザー数が 10 ～ 50 人の場合

ユーザー数が 10 ～ 50 人のブランチ オフィスには、1 つ以上のドメイン コントローラを配置します。台数は、そのブランチ オフィスで必要とされるサービスの種類に基づいて決定します。アプリケーションが LDAP (Lightweight Directory Access Protocol) に基づく検索または Active Directory に強く依存しているブランチや、クライアントの構成にグループ ポリシーを使用しているブランチには、ドメイン コントローラを最低でも 1 台は必ず配置してください。

通常、ドメイン コントローラのサービスは、DNS、DHCP、ファイルと印刷 (F&P) サービス、Microsoft インターネット インフォメーション サービス (IIS) などの役割と組み合わせることができます。役割を組み合わせるときには、予想される負荷とドメイン コントローラ間の負荷分散を必ず考慮に入れます。

ブランチ オフィスのユーザー数が 50 人を超える場合

前に説明したように、ブランチ オフィスにドメイン コントローラを配置する主な目的の 1 つは、ログオン トラフィックをブランチ内にとどめ、WAN に送り出されないようにすることです。ドメイン コントローラがグローバル カタログ サーバーを兼ねている場合は、アドレス帳の検索もブランチ内で処理され、トラフィックが WAN へ出ていくことはありません。

ユーザー数が 50 人を超えるブランチ オフィスでは、通常、ドメイン サービス (ドメイン コントローラ、グローバル カタログ、DNS、DHCP など) を実行する 1 台のドメインコントローラと、アプリケーションやファイルと印刷 (F&P) サービスを実行する 1 台以上のサーバーが必要となります。複製スケジュールや変更の頻度および規模によっては、1 台のドメイン コントローラで F&P などのサービスを十分実行できる場合もあります。

複製トラフィック

ドメイン コントローラは、正しく動作するために、ドメイン名前付けコンテキスト、スキーマ コンテキスト、および構成コンテキストを複製する必要があります。これらのコンテキストに対する変更がドメイン コントローラからネットワークへ送り出される複製トラフィックに及ぼす影響は、各コンテキストによって異なります。

ドメイン名前付けコンテキスト
ドメイン名前付けコンテキストには、ドメイン内のすべてのユーザー オブジェクト、グループ オブジェクト、コンピュータ オブジェクトと、グループ ポリシー オブジェクトの情報が含まれます。Active Directory での変更は、属性単位で複製されます。グループ メンバシップは複数値の属性で、一度にすべて複製されることを考慮に入れてください。グループ ポリシー オブジェクトを変更すると、Active Directory での複製が発生するだけでなく、ファイル複製サービス Sysvol の複製トラフィックも増加します。

スキーマ名前付けコンテキスト
スキーマには、グローバル カタログ サーバーに複製される属性の部分的なリストが定義されています。グローバル カタログ サーバーに複製される属性を追加すると、グローバル カタログ全体の複製が発生します。このような変更がきわめて頻繁に行われる可能性がある場合は、グローバル カタログ サーバーがある場所へのネットワーク接続を入念に調べ、リモート グローバル カタログ サーバーでの部分的な名前付けコンテキストの完全再構築をサポートできるかどうかを確認する必要があります。また、スキーマをロックダウンし、スキーマ変更の担当者が定義したバッチでのみスキーマ拡張を可能にするという方法もあります。

構成名前付けコンテキスト
構成名前付けコンテキストには、フォレストの構造および構成に関するすべての情報が含まれます。フォレストが正しく機能するためには、このコンテキストの変更をフォレスト全体に複製する必要があります。したがって、たとえばグループ ネストの変更はフォレスト内のすべてのグローバル カタログ サーバーに複製されます。

ログオン サーバの可用性

ユーザーまたはアプリケーションがブランチ オフィスでログオンする必要がある場合は、そのブランチにドメイン コントローラを配置し、WAN リンクが使用できない場合でもブランチオフィスが自律的に動作できるようにする必要があります。ブランチ オフィスのドメイン コントローラがなければ自律的な運用を実現することはできません。これは、キャッシュ内の資格情報がワークステーション ログオンでのみ使用され、サーバー上の共有フォルダへのアクセスやアプリケーション ログオンには使用されないからです。ブランチ オフィスの少数のユーザーをサポートする方法はほかにもあります。それについては次の節で説明します。より望ましいのは、ブランチに 2 台のドメイン コントローラを配置した構成です。1 つのドメイン コントローラではブランチ オフィスの負荷に対応できないため、ハードウェアを新たに購入する場合は、フェールオーバー方式の導入を検討してください。既存のドメイン コントローラの処理能力を拡張するためではなく、障害が発生した場合に処理を引き継ぐ予備のサーバーとして 2 台目のドメイン コントローラを導入する方が望ましいと言えます。

ブランチ オフィスにドメイン コントローラを配置しない場合の代替ソリューション

ブランチオフィスにドメインコントローラを配置ない場合、ローカルではログオン サービスが提供されておらず、さらにWAN リンクも使用できない場合、ユーザーはドメイン コントローラの認証を受けたり、ドメインユーザ アカウントを使用してローカルにあるファイルサーバやプリント サーバーにアクセスしたりすることはできません。このような場合にローカルのファイルと印刷 サービスへのアクセスを保証するには、次の 2 つの方法があります。ブランチオフィスのメンバ サーバーにローカル ユーザー アカウントとローカル グループ アカウントを作成する方法と、ターミナル サービスを使用する方法です。

メンバ サーバー上のローカル ユーザーとローカル グループ
ブランチ オフィスにドメイン コントローラを配置しない場合は、そのブランチのメンバ サーバーにローカル ユーザー アカウントとローカル グループ アカウントを作成します。ドメイン ユーザーのグローバル グループをメンバ サーバーのローカル グループに追加します。さらに、メンバ サーバーにローカル ユーザー (メンバ サーバーに作成されたユーザー) をメンバとするオフライン 用のユーザーグループを作成します。このグループには、グローバル グループを含むローカル グループと同じアクセス許可を与えます。ドメイン コントローラがあれば、ユーザーはそのドメイン コントローラからチケットを取得できます。WAN リンクがダウンした場合でも、ユーザーはオフライン ユーザーグループ内のローカル アカウントを使用してローカル サーバー上のリソースにアクセスできます。

この解決策の欠点は、管理者が重複したユーザー アカウントとグループ アカウントを管理しなければならず、ユーザーはドメイン ユーザー アカウントとメンバ サーバーのローカル ユーザー アカウントの間でパスワードを手動で同期させる必要があることです。通常、ユーザーはこうした面倒な操作を必要とする環境を敬遠します。もう 1 つの解決策として、Windows ターミナル サービスのクライアント/サーバー構成があります。

ターミナル サービス
Windows ワークステーションを使用し、ネットワークを介してサーバーにアクセスするのではなく (この場合はサーバーへのログオンとドメイン コントローラが必要です)、ユーザーが Windows ターミナル サービス クライアントからローカルにあるターミナル サーバーに接続します。ターミナル サーバーは、ログオン要求をハブ サイト内の次に使用可能なドメイン コントローラに WAN 経由で送ります。何らかの理由でハブ サイトとのリンクがダウンした場合でも、ユーザーはキャッシュに保存された資格情報でログオンし、サーバー上のリソースにアクセスできます。

この方法では、ユーザーは常にローカルにあるターミナル サーバー上で操作を行うことができます。ドキュメントを印刷したり、ローカルのターミナル サーバーのネットワーク共有にファイルを保存する場合でも、それはローカルにおける操作です。これらのリソースのアクセス チェックには追加のログオンは必要ありません。ネットワークが使用できない場合でも、ユーザーはキャッシュ内の資格情報を使用してターミナル サーバーにログオンし、Windows ベースのターミナル上でサーバーにインストールされたアプリケーションを実行でき、サーバー上のすべてのリソースを使用できます。

どちらの方法でも、ユーザーにはある程度のオフライン操作が可能になりますが、管理が容易でサーバーのハードウェア仕様に応じて拡張できることから、ターミナル サービスを使用したソリューションの方が望ましいと言えます。

グローバル カタログ サーバーの配置

原則として、各サイトのドメイン コントローラのうち少なくとも 1 台はグローバル カタログ サーバーとして指定します。ドメイン コントローラに適用したのと同じフェールオーバーと負荷分散の規則に基づいて、各サイトに複数のグローバル カタログ サーバーが必要かどうかを判断します。

シングルドメイン環境
シングルドメイン・シングルサイト環境では、ログオン要求の処理にグローバル カタログ サーバーは必須ではありません。どのドメイン コントローラも 1 つのグローバル サーバーしか認識していないからです。それでも複数のグローバル カタログ サーバーを指定することは必要です。クライアントは、検索処理においてグローバル カタログ サーバーを探します。また、グローバル カタログ サーバーが存在していると、新たなドメインを追加したときにシステムがスムーズに適応できます。

推奨事項 : ハブサーバがあるシングルドメイン複数場所環境では、各ハブ サイトに 1 台以上のグローバル カタログ サーバーが必要です。さらに、ユーザー数が 50 人を超えるブランチ オフィスにもグローバル カタログ サーバーを配置してください。この構成でシングルドメイン環境の稼働には十分ですが、最善の方法は、すべてのドメイン コントローラをグローバル カタログ サーバーとして指定することです (ただし、インフラストラクチャ マスタ役割を持つ操作マスタを除きます)。これによってデータベースのサイズや複製トラフィックが増加することはないからです。

ネイティブ モード ドメイン

すべてのドメイン コントローラが Windows 2000 ドメイン コントローラであり、ドメインがネイティブ モードに設定されている場合は、ユニバーサル グループを使用することができます。ネイティブ モード ドメインでユーザーのログオン要求を処理するときには、ドメイン コントローラがグローバル カタログ サーバーにクエリを送信し、そのユーザーがユニバーサル グループに所属しているかどうかを確認します。この設定ではリソースへのグループ アクセスを明示的に拒否できるため、アクセス制御を適切に実施するには、ユーザーやグループの設定 に関する詳細な知識が必要となります。ユーザーがログオンを要求したときに、ネイティブ モード ドメインのドメイン コントローラがグローバル カタログ サーバーにアクセスできず、ユニバーサル グループ メンバシップを確認できなかった場合には、ログオン要求は拒否されます。

次のレジストリ キーを設定すると、ユニバーサル グループを展開するときにドメイン コントローラがグローバル カタログ サーバーのエラーを無視します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\IgnoreGCFailures

ドメイン コントローラはグローバル カタログ サーバーに接続しようとしますが、クエリの実行がタイムアウトとなります。このレジストリ キーの詳細については、Microsoft Knowledge Base の記事 Q241789 (英語) を参照してください。

マルチドメイン環境
マルチドメイン環境では、ユーザー ログオン要求を処理するためにグローバル カタログ サーバーが必要です。サイトにグローバル カタログ サーバーがない場合は、そのサイト内のドメイン コントローラがハブ サイトのグローバル カタログ サーバーにアクセスし、ユニバーサル グループの情報を取得しなければなりません。この場合、次のような 2 つの問題が発生します。1) WAN が使用できない場合、ログオンは失敗します。2) WAN が使用可能である場合は、ブランチオフィスとハブサイトの間で余計なネットワーク トラフィックが発生します。ユーザーが常にドメインにログオンできるようにすることが必須条件である場合は、ローカルサイトにグローバル カタログ サーバーを配置することが必要です。つまり、複数ドメインのハブ アンド スポーク型ネットワーク環境では、グローバル カタログ サーバーで障害が発生したときのために、各ハブサイトに少なくとも 2 台のグローバル カタログ サーバーを配置します。さらに、使用するアプリケーションによって、またブランチ サイト内およびブランチ サイトへの接続のネットワーク帯域幅によっては、ブランチ内にグローバル カタログ サーバーを指定することも必要になります。ユーザー数が 50 人を超えるサイトには、最低でも 1 台のグローバル カタログサーバーを必ず配置しなければなりません。

ドメイン コントローラとグローバル カタログ サーバーをどこに配置すべきかが明らかになったので、ここでサンプル環境においてドメイン コントローラとグローバル カタログ サーバーをどのように配置することになったかを見ます。

上の図を見ると、すべてのサーバーがドメイン コントローラであることがわかります。さらに、1 台のルート サーバー (Root1)、試験運用のためのステージング サイト サーバー (Staging)、すべてのブリッジヘッド サーバー (BH1、BH2、BH3) は、グローバル カタログ サーバーです。ブランチ オフィスにグローバル カタログ サーバーがないのは、どのブランチ オフィスもユーザー数が 50 人未満で、Microsoft Exchange 2000 などの Active Directory 対応アプリケーションが使用されていないからです。

ドメイン コントローラとグローバル カタログ サーバーをどこに配置するかを決定したら、次に DNS サーバーの配置について検討します。

DNS 設計時の推奨事項

DNS サーバーの可用性は Active Directory の可用性に直接的な影響を及ぼします。クライアントはドメイン コントローラの検索において DNS に依存し、ドメイン コントローラも複製時にほかのドメイン コントローラを検索するために DNS に依存します。既に DNS サーバーをネットワークに配置している場合でも、Active Directory クライアントやドメイン コントローラの必要に応じてサーバーの数や配置を調整しなければならないことがあります。

原則として、各サイトに 1 台以上の DNS サーバーを配置します。DNS サーバーは、同じサイト内のドメイン コントローラに対応するドメインのロケータ レコードに対するアクセス権限を持っていなければなりません。これによって、クライアントは同じサイト内のドメイン コントローラを検索するために、サイト外の DNS サーバーにクエリを送信する必要がなくなります。

したがって、すべての要件を満たす推奨構成は、Active Directory に統合された DNS を使用し、ドメインのゾーンのロケータ レコードをそのドメイン自体に格納し、各サイトの 1 つ以上のドメイン コントローラで Windows 2000 の DNS サービスを実行することです。

コンピュータが DNS 名前解決を実行すると予想される各ネットワーク接続の構成には、優先 DNS サーバーと少なくとも 1 台の代替 DNS サーバーを指定しなければなりません。優先 DNS サーバーと代替 DNS サーバーは接続するコンピュータと同じサイト、または (コンピュータのサイトに DNS サーバーがない場合は)低コストで接されるサイトに存在している必要があります。ドメイン コントローラそれ自体を優先 DNS サーバーまたは代替 DNS サーバーとして指定することもできます。

ドメイン コントローラは、それぞれのロケータ レコード (SRV レコードなど) に誤りがないことを定期的にチェックします。そのためにドメイン コントローラは、対応する DNS ゾーンに対して権限を持つ DNS サーバー上の固有のロケータ レコードと、Active Directory ルート ドメイン (またはルート ドメインが使用する DNS ゾーン) 内のフォレスト全体のレコードを検証します。

フォレスト全体のロケータ レコードの分散

フォレスト内の各ドメイン コントローラは 2 つのロケータ レコード セットを登録します。1 つは <DNS domain-name> で終わるドメイン特有のレコードで、もう 1 つは _msdcs.<DNS-forest-name> で終わるフォレスト全体のレコードです。フォレスト全体のレコードは、フォレストのあらゆる部分のクライアントおよびドメイン コントローラに関連します。フォレスト全体のレコードには、グローバル カタログ サーバー ロケータ レコードや複製システムが複製パートナの検索に使用するレコードなどが含まれます。

2 つのドメイン コントローラ間で複製を行う場合は、どちらも同じドメインに属していても、フォレスト全体のロケータ レコードを検索できなければなりません。新たに作成されたドメイン コントローラが複製に参加するためには、そのフォレスト全体のレコードを DNS に登録でき、それらのレコードをほかのドメイン コントローラが検索できなければなりません。このような理由から、フォレスト全体のロケータ レコードは各サイトのどの DNS サーバーにも使用可能であることが必要です。

DNS サーバーと _msdcs.<DNS forest-name> ドメインに対して権限を持つ DNS サーバーとの間に高速接続がある場合は、特別な構成は必要ありません。そうでない場合は、2 つの方法が可能です。_msdcs.<DNS-forest-name> DNS ドメインの独立したゾーンを作成し、それを標準のゾーン転送ですべての DNS サーバーに複製する方法と、_msdcs.<DNS-forest-name> という名前のゾーンを作成し、それをすべての DNS サーバーに複製する方法です。Active Directory に統合された DNS を使用している場合は、このゾーンのプライマリ コピーを <DNS-forest-name> ゾーンとともにフォレスト ルート ドメインに配置できます。さらに、このゾーンを標準の DNS 複製によってドメイン外のセカンダリ DNS サーバーに複製できます。ルート ドメイン以外のドメイン コントローラまたは DNS サーバーは、ソース ゾーンの読み取り専用コピーを管理します。

ブランチ オフィスがダイヤルアップ回線でハブ サイトに接続され、グローバル カタログ サーバーが 1 台、同じドメインのドメイン コントローラが 2 台以上配置されている場合、このブランチ オフィスには、セカンダリ _mscdcs<DNS-forest-name> ゾーンをホストする DNS サーバーが必要です。これによって、ローカル サーバー上でフォレスト全体のレコードにアクセスでき、WAN トラフィックが発生しなくなります。

一般に、ゾーンを各サイトの 1 つの DNS サーバーに複製するだけでは不十分です。_msdcs.<DNS-forest-name> ゾーンのローカル コピーがなく、クエリを転送するように設定されていない DNS サーバーは、このゾーンに属す名前を検索するために 再帰を使用しなければなりません。DNS サーバーが再帰を実行するには、名前空間のルートに対する権限を持つ DNS サーバー (DNS ルート サーバー) にアクセスし、目的のレコードが見つかるまで DNS 内の委任を下位へと進みます。サイト内に DNS ルート サーバーまたはフォワーダがなく、そのサイトとほかのサイトを接続するリンクがダウンしている場合、DNS サーバーは再帰またはフォワードを実行できません。したがって、_msdcs.<DNS-forest-name> に対して権限を持つ DNS サーバーを見つけることはできません。このような DNS サーバーが同じサイトにあっても同じです。この問題を解決するには、ゾーンをサイト内の 2 台の DNS サーバーに複製し、それぞれを他方のサーバーが優先 DNS サーバーとなり、自らが代替 DNS サーバーとなるように設定します。

" アイランド" 問題

プライマリ DNS サーバーであるドメイン コントローラにおいて、それ自体が _msdcs.<DNS Forest-name> ゾーンの優先 DNS サーバーまたは代替 DNS サーバーとして指定されている場合に、いわゆる "アイランド" 問題が発生します。この構成の代表的なものは、Active Directory 統合モードの DNS サーバーを兼ねた、フォレスト ルート ドメイン内のドメイン コントローラです。このようなドメイン コントローラの IP アドレスの変更などの構成変更を行った場合には、ローカルのドメイン コントローラでのみフォレスト全体のロケータ レコードが更新されます。通常、この変更はほかのすべてのドメイン コントローラに複製されます。

複製パートナとなるサーバーの IP アドレスを検索するときには、ドメイン コントローラ ロケータ レコードの 1 つ CNAME レコード (エイリアス) が使用されます。複製プロセスでは、内部的にドメイン コントローラのグローバル一意識別子 (GUID) を使用して、複製先のサーバーを検索します。ドメイン コントローラの CNAME レコードでは、ドメイン コントローラのFQDN 名にマップされたエイリアスとして GUID が使用されます。

ドメイン コントローラの構成に対して CNAME レコードに影響するような変更を行い、それに基づく更新がローカル DNS サーバーでのみ行われれば、その変更がほかのドメイン コントローラへ伝達されることはありません。その理由は、Active Directory に統合された DNS ゾーンを使用すると、DNS は複製によって DNS ゾーン情報を更新するからです。ただし、ドメイン コントローラが DNS の変更によって複製先のサーバーを見つけられない場合、変更を複製することはできません。

この問題を回避するには、フォレスト ルート ドメイン コントローラが _msdcs.<DNS forest-name> に対して権限を持つ DNS サーバーである場合に、フォレスト ルート ドメイン内のプライマリ サーバーでそれ自身を優先 DNS サーバーとして指定しないでください。別のフォレスト ルート DNS サーバーを優先 DNS サーバーとして指定します。これ以外の場合、ドメイン コントローラで "アイランド" 問題が発生することはありません。ドメイン コントローラでそれ自体が優先 DNS サーバーとして指定されていても、必ずルート ゾーンに対して権限のある DNS サーバー上の複製に必要なレコードを更新するからです。

" アイランド " 問題の例
Root1.corp.hay-buv.com はフォレスト内の最初のドメイン コントローラです。このドメイン コントローラでは、それ自体が優先 DNS サーバーとして指定されています。優先 DNS サーバーは、Active Directory に統合されたゾーン corp.hay-buv.com のプライマリ DNS サーバーです。このゾーンには _msdcs.corp.hay-buv.com が含まれています。

2 番目の Windows 2000 サーバー Root2 は DNS サービスを実行しており、ドメイン コントローラに昇格することになっています。Root2 もそれ自体が優先 DNS サーバーとして指定されています。

昇格の際には、Active Directory に統合されたゾーン corp.hay-buv.com が Root2 に複製されます。この新しいドメイン コントローラ Root2.corp.hay-buv.com を再起動すると、DNS サーバーが Active Directory の固有のコピーからゾーン corp.hay-buv.com のコピーをロードします。昇格後、Root2 が初めて DNS エントリを登録するときに、Root2 の Net Logon サービスが Root2 の SRV レコードをそれ自身の DNS サーバー サービスに登録します。Root2 は Root1 には登録せず、必ずそれ自体に登録します。また、レコードは Root1 には複製されません。Root1 が保持する DNS のコピーには、Root2 がドメイン コントローラであることを示すレコードがないからです。そのため、Root2 から Root1 への複製は発生しません。

説明 : Root2 の Net Logon サービスが DNS レコードを登録するときには、優先 DNS サーバー (Root2.corp.hay-buv.com 自体) がゾーン corp.hay-buv.com に対する権限を持っていることを認識し、レコードをローカル DNS サーバーに登録します。こうしたレコードの 1 つに <DsaGuid>._msdcs.<ForestName> の CNAME レコードがあります。Root2 から複製しようとするほかのドメイン コントローラ (ここでは Root1) は、この CNAME レコードを検索します。しかし、どちらのドメイン コントローラもそれ自体が DNS サーバーであり、ゾーン corp.hay-buv.com. に対する権限を持っているため、いずれもこの CNAME レコードを見つけることはできません。したがって、これらのドメイン コントローラは Root2.corp.hay-buv.com に登録されたレコードを複製することはできません。

" アイランド " 問題を回避する構成
ドメイン コントローラでそれ自体が優先 DNS サーバーまたは代替 DNS サーバーとして指定されており、しかもローカル DNS サーバーが DNS ドメイン _msdcs.<DNSForest-Name> のプライマリ サーバーである (つまりルート ドメイン内にある) 場合は、必ず優先 DNS サーバーを再構成してから再起動します。昇格後、再起動する前に、ドメイン コントローラの優先 DNS サーバーおよび代替 DNS サーバーをそのドメイン コントローラ自体ではなくドメイン _msdcs.<DNSForest-Name> のプライマリ サーバーに指定する必要があります。フォレスト内のほかのドメイン コントローラでは、それ自体を DNS サーバー として構成できます。

Net Logon によって公開された DNS SRV レコードの構成
クライアントは、サイト固有のドメイン コントローラ ロケータ レコードを使用して近接したドメイン コントローラを検索します。クライアントのサイトのドメイン コントローラ エントリが存在しない場合のみ、クライアントはほかのドメイン コントローラを検索し、受け入れます。既定では、各ドメイン コントローラがサイト固有の SRV レコードと汎用 SRV レコードを公開します。

ハブサイト内のドメイン コントローラの検索
ブランチ オフィス環境では、クライアントが同じサイト内でドメイン コントローラを見つけられなかった場合に、別のブランチやハブサイトではなく、そのクライアントが属するハブ サイトで見つけられるようにすることが重要です。多くの場合、ネットワークが完全にはルーティングされていないため (一方向のダイヤルアップ回線を使用しているなど)、あるブランチのクライアントが別のブランチ内のコンピュータに接続することはできません。ただし、接続環境が整っていたとしても、ブランチ間でネットワーク接続を確立することは望ましくありません。このようなネットワーク トラフィックは必ずハブ サイトを経由するからです。したがって、トラフィックはブランチとハブサイト間のトラフィックだけに制限した方がよいと言えます。

あるブランチのクライアントが別のブランチのドメイン コントローラに接続することを防ぐには、ブランチ オフィスの各ドメイン コントローラの Net Logon サービスを構成するときに、サイト固有のロケータ レコードだけを公開し、汎用ドメイン コントローラ ロケータ レコードを公開しないように指定します。その結果、ハブサイトの ドメイン コントローラだけがサイト固有のレコードに加えて汎用ロケータ レコードを公開するようになります。これによって、クライアントが同じサイト内でドメイン コントローラを見つけられない場合には、ハブ ドメイン コントローラの汎用ドメイン コントローラ ロケータ レコードだけを検索します。検索によって取得されるドメイン コントローラを制限するには、以下のファイルとレジストリの編集によって Net Logon を設定します。

Net Logon 構成ファイル
Net Logon を構成する際に登録するドメイン コントローラ ロケータ レコードを指定する機能が Windows 2000 の SP2 に追加されました。

Net Logon レジストリの編集
ドメイン コントローラ上の Net Logon が特定の DNS レコードを動的に更新しないようにするには、Regedt32.exe を使用して次のレジストリ値を設定します。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

レジストリ値 : DnsAvoidRegisterRecords

データの種類 : REG_MULTI_SZ

この値では、ドメイン コントローラによる登録の対象外とする DNS レコードに対応するニーモニックのリストを指定します。指定できるニーモニックを次の表に示します。

ニーモニック	種類	DNS レコード
Dc	SRV	_ldap._tcp.dc._msdcs.<DnsDomainName>
DcAtSite	SRV	_ldap._tcp.<SiteName>._sites.dc._msdcs.<DnsDomainName>
DcByGuid	SRV	_ldap._tcp.<DomainGuid>.domains._msdcs.<DnsForestName>
Pdc	SRV	_ldap._tcp.pdc._msdcs.<DnsDomainName>
Gc	SRV	_ldap._tcp.gc._msdcs.<DnsForestName>
GcAtSite	SRV	_ldap._tcp.<SiteName>._sites.gc._msdcs.<DnsForestName>
GenericGc	SRV	_gc._tcp.<DnsForestName>
GenericGcAtSite	SRV	_gc._tcp.<SiteName>._sites.<DnsForestName>
GcIpAddress	A	_gc._msdcs.<DnsForestName>
DsaCname	CNAME	<DsaGuid>._msdcs.<DnsForestName>
Kdc	SRV	_kerberos._tcp.dc._msdcs.<DnsDomainName>
KdcAtSite	SRV	_kerberos._tcp.dc._msdcs.<SiteName>._sites.<DnsDomainName>
Ldap	SRV	_ldap._tcp.<DnsDomainName>
LdapAtSite	SRV	_ldap._tcp.<SiteName>._sites.<DnsDomainName>
LdapIpAddress	A	<DnsDomainName>
Rfc1510Kdc	SRV	_kerberos._tcp.<DnsDomainName>
Rfc1510KdcAtSite	SRV	_kerberos._tcp.<SiteName>._sites.<DnsDomainName>
Rfc1510UdpKdc	SRV	_kerberos._udp.<DnsDomainName>
Rfc1510Kpwd	SRV	_kpasswd._tcp.<DnsDomainName>
Rfc1510UdpKpwd	SRV	_kpasswd._udp.<DnsDomainName>

ブランチ オフィスへ展開する際の推奨構成は次のとおりです。

• ブランチ オフィスのすべてのドメイン コントローラにおいて、DsaCname を除き、ニーモニックに "AtSite" が含まれないエントリをすべて上記のレジストリ キーの値に追加する。

ハブサイトのドメイン コントローラでは、このレジストリ キーは使用しないでください。これによって、ドメイン コントローラはすべてのレコードを登録できます。

DNS 登録における保存可能な値の制限
ドメイン コントローラが SRV レコードを登録する方法に関して制限があることは既に説明しましたが、大規模な環境で Active Directory に統合された DNS ゾーンを使用する場合には、保存可能な属性値の数に関しても制限が発生します。DNS 登録は複数値属性に保存されます。Active Directory には、リンクされていない複数値属性に関し、保存可能な値の数をオブジェクトあたり最大 850 とする制限があります。これに対し、グループなどのリンクされた複数値属性は、もっと多くの値 (Windows 2000 では最大 5,000) を保存できます。小規模な環境では、Net Logon の設定は任意であり、サービスの検索を最適化します。ドメイン コントローラの台数が 800 を超える環境では、リンクされていない複数値属性の値の数に制限があることから、Net Logon の構成は必須です。

たとえば、850 台を超えるドメイン コントローラが同じドメインのサービスを登録すると、属性値の制限に達してしまいます。Net Logon を正しく (ブランチ オフィスのドメイン コントローラがエントリをドメイン レベルではなく必ずサイト レベルで登録するように) 設定すると、この制限がドメイン レベルからサイト レベルに変わり、数千のドメイン コントローラがサービスを登録できるようになります。1 つのサイトに 800 台を超えるドメイン コントローラが必要となるような構成は

意味をなしません。

この解決策を適用する前の DNS 構成は次のようになります。

解決策を適用した後の DNS 構成とレジストリ エントリは、次のようになります。

DNS の AutoSiteCoverage 登録を無効にする
特定のサイトにドメイン コントローラがない場合にも、SRV レコードの設定が必要となります。このような状況が発生するのは、頻繁にログオン アクセスを必要とするユーザーがいない場合や、サイトへの複製が非常に高コストまたは低速になる場合です。クライアント コンピュータと同じサイトではなくても近接するサイトにドメイン コントローラが配置されるように、Windows 2000 は "autositecoverage" アルゴリズムを使用して、すべてのサイトにドメイン コントローラを登録しようとします。このアルゴリズムは、サイトがドメイン コントローラのない別のサイトを "カバー" できるかどうか判定します。既定では、このプロセスに複製トポロジが使用されます。

このアルゴリズムは次のように動作します。各ドメイン コントローラがフォレスト内のすべてのサイトをチェックし、次に複製コスト マトリックスをチェックします。ドメイン コントローラが対応するドメインのドメイン コントローラがないサイトを見つけ、そのサイトに最低コストの接続がある場合は、自らをアドバタイズします (DNS にサイト関連の SRV レコードを登録します)。このプロセスによって、ドメイン コントローラが実際に配置されていないサイトを含め、すべてのサイトがドメイン コントローラを持つことになります。DNS に公開されたドメイン コントローラは、近接したサイト (複製トポロジによって決まる) のドメイン コントローラです。

ブランチ オフィス環境では、ほかのサイトのコンピュータがブランチ オフィスのドメイン コントローラを検出してはなりません。クライアントは必ずローカル ドメイン コントローラに接続し、ローカル ドメイン コントローラが使用できない場合はハブ サイトのドメイン コントローラを使用しなければなりません。そのためには、次の処置を行います。

1. ブランチ オフィスのドメイン コントローラだけでなく、ハブのドメイン コントローラを含め、すべてのドメイン コントローラで AutoSiteCoverage を無効にします。

2. 上述のとおり、汎用レコードを登録しません。

これら 2 つの設定をどちらも行うと、すべてのサイトのクライアントがローカル ドメイン コントローラまたは (ローカル ドメイン コントローラが使用できない場合は) ハブのドメイン コントローラを検出します。

まれな例ですが、あるドメインのドメイン コントローラが配置されたサイトがあり、ハブサイトまでの距離より近い場所に別のサイトがある場合は、SiteCoverage と GcSiteCoverage の 2 つのレジストリ値を使用して、そのドメイン コントローラが特定の (近くの) サイトをカバーするように設定できます。あるいは、次のようなグループ ポリシー設定を使用することもできます。

• ドメイン コントローラ ロケータ DNS SRV レコードによってカバーされるサイト

• グループ カタログ サーバー ロケータ DNS SRV レコードによってカバーされるサイト

• NDNC ロケータ DNS SRV レコードによってカバーされるサイト

ただし、物理的な近接性やネットワーク パフォーマンスだけが基準ではありません。ファイアウォールやダイヤルオンデマンド回線によって、この方向のトラフィックが許されない場合は、誤ったサイトカバレッジを適用すると、クライアントに悪影響を及ぼします。クライアントがハブではなく通信不能なドメイン コントローラに接続しようとするからです。

ネーム サーバー レコードの登録

DNS サーバーは、SRV レコードに加え、ネーム サーバー (NS) レコードも自動登録します。これらのレコードによって、クライアントは特定のドメインに対して権限を持つ DNS サーバーを見つけることができます。ただし、多くの企業は隠し DNS サーバーを使用しています。隠し DNS サーバーを検出したり使用したりできるのは、その DNS サーバーを明示的に指定しているクライアントだけです。隠し DNS サーバーは、NS レコードではドメインに対して権限のある DNS サーバーとしては指定されません。ブランチ オフィス環境では、NS レコードによって登録される DNS サーバーが多すぎないことが重要です。NS レコードに指定されたサーバーのリストが大きすぎると、クライアントの NS クエリへの応答トラフィックが多くなりすぎます。ブランチ オフィスのクライアントは、NS レコードを使用して DNS サーバーを検索する必要があり、ブランチ内に DNS サーバーが存在しない場合は、データ センターの DNS サーバーだけを検索できなければなりません。

DNS サーバーが NS レコードを自動登録しないように構成するには、次のレジストリ キーを使用します。

HKLM/System/CCS/Services/DNS/Parameters

REG_DWORD DisableNSRecordsAutoCreation

このエントリには、次の 2 つの値のいずれかを指定できます。

0x0 - サーバーは、Active Directory からゾーンを転送するときに、そのサーバー自体に対応する NS レコードを自動的に追加します。

0x1 - サーバーは、Active Directory からゾーンを転送するときに、そのサーバー自体に対応する NS レコードを追加しません。

既定では、この値は存在せず、機能は 0x0 を選択した場合と同じになります。

DNS 登録とダイヤルオンデマンド リンク

Active Directory をブランチ オフィスに展開する際に、DNS の配置と構成に影響するもう 1 つの要素として、ブランチとハブサイト間のダイヤルオンデマンド リンクがあります。ダイヤルオンデマンド接続は、ブランチとハブサイトの一般的な接続構成です。この接続構成では、DNS 登録がダイヤルアップ リンクを経由しなければならないため、そうした低速リンク上のネットワーク トラフィックが増加します。また、その時点で回線を使用するアプリケーションがほかに存在しなくても、回線を開くことになります。ドメイン コントローラが DNS レコードを更新する頻度を調整するには、SOA (Start of Authority) レコードの DNS 更新間隔を使用します。

最初の DNS 登録だけでなく、一定の期間を過ぎた古いレコードを DNS から削除する DNS アンチエイジング機能も、登録されたレコードに対応するクライアントが存在するかどうかをときどきチェックする必要があります。この処理でも再帰的なネットワーク トラフィックが発生します。

ダイヤルオンデマンド回線のトラフィックを抑制する良い方法として、ブランチ オフィスに DNS サーバーを配置し、ドメイン コントローラがエントリをローカル サーバーに登録できるようにすることがあります。ただし、上に示すように、_msdcs.<DNS forest-name> ドメインに登録しなければならないレコードもあります。これが可能であるのは、このドメインのプライマリ DNS サーバーだけです。ほとんどのブランチ オフィス展開では、_msdcs.<DNS forest-name> ドメインのプライマリ DNS サーバーはデータセンターまたはハブサイトにしか存在しません。_msdcs.<DNS forest name> ドメインがあるゾーンをセカンダリ ゾーンとしてローカル DNS サーバーに転送したとしても、ローカル DNS サーバーをレコードの登録に使用することはできません。レコードの登録はプライマリ DNS サーバーで行うことが必要だからです。ここでも、ドメイン コントローラが SOA レコードの DNS 更新間隔を使用して、ドメイン コントローラが DNS レコードを更新する頻度を調整します。

DNS クライアント構成

クライアントとドメイン コントローラには、優先ローカル サーバーと代替サーバーという最低でも 2 つのサーバーの DNS サーバー IP アドレスを構成する必要があります。代替サーバーは、ローカル サイト内のサーバーでも、ネットワークがフェールオーバーを処理できる場合はリモート サイト内のサーバーでもかまいません。もう一度サンプル シナリオを検証すると、それ自体が優先 DNS サーバーであるルート ドメイン コントローラは存在せず、ほかのどのドメイン コントローラでも別の DNS サーバーが代替サーバーとして指定されていることに気付きます。

Active Directory をサポートする DNS サーバーの配置および構成の詳細については、『Windows 2000 Server リソース キット 分散システム ガイド』を参照してください。

サイト数の決定

サイト数は、以下の 3 つの条件によって決まります。

• 独立した場所の数

• ドメイン コントローラ間のネットワーク接続 (これは新しいサイトを作成するかどうかを決定する直接の判断基準となります)

• ドメイン コントローラがある場所の数とドメイン コントローラがない場所の数

以下に挙げる特殊な状況では、ローカル ドメイン コントローラが配置されていない場合でもサイトを作成する意味がありますが、通常はローカル ドメイン コントローラが配置されている場合のみサイトを作成します。ユーザーには、ネットワークにローカルにログオンし、ファイル/プリント サービスなどのネットワーク サービスを使用するために、ドメイン コントローラが必要です。ドメイン コントローラが使用できない場合でも、自分のワークステーションにはキャッシュ内の資格情報を使用してログオンできます。ただし、ファイル サーバーなどのネットワーク サービスには、キャッシュ内の資格情報を使用してアクセスすることはできません。

次のような場合には、ブランチ オフィスにドメイン コントローラを配置する必要はありません。

• ユーザーがすべての作業を自分のワークステーションで行うため、ネットワーク サービスを必要としない。

• ブランチオフィスでターミナル サービスを使用できるため、そのサーバー上でアプリケーションを実行でき、ホーム ディレクトリ、共有、プリンタ サービスなどのサーバー サービスを使用できる。ターミナル サービスを使用している場合は、ログオンにキャッシュ内の資格情報を使用できます。

• WAN の信頼性が 100% であり、WAN 上のユーザー ログオン トラフィックが Active Directory の複製トラフィックより少ないと考えられる。

ユーザー数が少ない場合は (10 人くらいでも)、ログオン トラフィックが複製トラフィックより多くなることがあります。この状況が発生するのは、Active Directory の複製トラフィックが非常に効率的で、データ圧縮 (元のデータ サイズの約 10% ～ 15% に圧縮) や複製スケジュールなどの WAN との親和性に優れたコンポーネントを使用している場合です。

次のような管理上の条件についても検討する必要があります。

• ローカル ドメイン コントローラの配置および構成を正しく行わなければならない。

• ブランチ オフィスへ向かう複製トラフィックの量をきわめて厳密に監視しなければならない (Active Directory 複製と FRS 複製の両方)。

全体として、配置するドメイン コントローラと作成するサイトの数が多いほど、環境はより複雑になります。それに伴い、ブランチ オフィスのドメイン コントローラだけでなく、ミッション クリティカルなブリッジヘッド サーバーにおいても、全体的な管理および監視タスクが増加します。ブランチ ドメイン コントローラの物理的なセキュリティに要するコストも考慮に入れる必要があります。

多くの場合、ドメイン コントローラをデータ センターに集中させると、一見したところネットワーク トラフィックにかかるコストが増加するように思えますが、すべての場所にドメイン コントローラを配置するより対費用効果が高くなります。最善の結果を得るためには、Active Directory 名前空間の適切な設計と徹底的なコスト分析が不可欠です。

Exchange Server の配置
Exchange 2000 やその他のサービスを実行するためにブランチ オフィス内にドメイン コントローラが必要である場合には、FRS、ドメイン コントローラ、およびグローバル カタログ サーバーの複製について検討する必要があります。小規模なブランチ オフィスではグローバル カタログ サーバーの配置が検討事項となります。グローバル カタログ サーバーのサイズが大きければ、多くの場合、複製トラフィックはクライアントによるグローバル カタログ サーバーの検索に伴うトラフィックより大きくなります。検索の頻度が低い小規模のブランチ オフィスで、グローバル カタログ サーバーの規模が大きい場合は、グローバル カタログ サーバーをハブに配置し、ブランチ オフィスには配置しない方がよい場合があります。ブランチ オフィスの規模が非常に小さく、ハブとのリンク速度が適正である場合は、Exchange を搭載したサーバーもハブに配置するのがきわめて妥当と言えます。

まとめ

この章では、フォレストとドメインを分割すべきかどうかを判断し、ドメイン コントローラ、グローバル カタログ サーバー、DNS サーバー、および操作マスタをどのように配置したらよいかを決定する際に役立つ情報を提供しました。さらに、どのサーバーをどのサイトに配置すべきかと、ブランチ オフィスとハブサイトの間でトラフィックを最適化するために必要な構成についても説明しました。このガイドで使用したサンプル シナリオの図には、サンプル環境において、ドメイン コントローラ、グローバル カタログ サーバー、DNS サーバー、操作マスタをどのように配置したかを示しました。ハブサイトとブランチオフィスの論理的な構造は完成しました。次の章では、設計した構造に伴う複製の問題と構成について説明します。

ページのトップへ

3 of 7