Share via

組織単位の構成の設計および実装

  • [アーティクル]

このシナリオでは、多国籍企業において Active Directory™ ディレクトリ サービス内で組織単位 (OU) を使用して、各部門内の情報リソースと、各部門の機能するインフラストラクチャの双方を効率的に管理する方法を紹介します。

トピック

目的
設計のロジック
設計の原理
noam.reskit.com OU の構造
実装した方法
セットアップ手順
その他の参考資料

目的

このシナリオの目的は以下のとおりです。

  • ドメインの Active Directory オブジェクトを OU 構造内にグループ化することによって、このオブジェクトを効率的に管理します。

  • OU に関する権限を適切な管理セキュリティ グループに委任します。

  • OU 構造内に含まれるユーザーおよびコンピュータにグループ ポリシー設定を適用します。

次の「設計のロジック」では、このシナリオのインフラストラクチャで上記の目的をどのようにして達成したか説明します。

設計のロジック

このシナリオで想定する多国籍企業 Reskit は、北米、ヨーロッパ、アジアに Windows 2000 ドメインを含むエンタプライズネットワーク構造を持ちます。図 1 は、Reskit の各オフィスの地理的な位置を示したものです。

domain01-01
図 1: Reskit のオフィスの地理的な位置

このシナリオでは、北米ドメイン noam.reskit.com の Active Directory OU 構造に注目します。noam.reskit.com ドメインには、Seattle にある Reskit の本社と、法務を担当する Boston 支社、そしてカナダの販売および顧客サポート業務を担当する Vancouver, B.C. 支社が含まれます。

このシナリオでは、noam.reskit.com ドメインを集中管理モデルで運用し、ユーザーとコンピュータのアカウントの作成や削除など、管理機能を Seattle にある IT 組織によって厳重に管理することが求められています。しかし、Boston および Vancouver には少人数の IT スタッフが常駐し、ローカル ユーザーのサポートと、サーバーおよびデスクトップ コンピュータの保守を担当しています。したがって、地理的に分散した IT スタッフ職員によってドメインを管理する場合に適した OU 構造が必要になります。

このような OU 設計の中心になるのは、noam.reskit.com ドメイン全体で管理権限の委任を容易にする構造です。既定の設定では、Domain Admins ビルトイン セキュリティ グループにドメインに対する完全な管理権限が与えられています。このグループには広範な権限が与えられているので、そのメンバシップは一般的に少数の管理担当ユーザーに制限されます。しかし、noam.reskit.com のような大規模なドメインでは、Domain Admins ですべての管理作業を実行するのは非実用的かつ非能率的であるという判断が得られました。そこで、ドメイン内で数十万に達する場合もあるオブジェクトを管理するために、以下の手段を取ることにしました。

  • OU 構造の全体に Active Directory オブジェクトを分散します。必要に応じて、オブジェクトをその固有の管理要件に基づいて分散します。

  • ビルトイン セキュリティ グループと、ドメインのオブジェクトの管理用に作成したセキュリティ グループを組み合わせて使用します。このために、各 OU の管理権限を適切な管理セキュリティ グループに委任します。

さらに、グループ ポリシー オブジェクト (GPO) を対象にした、ドメインに対応する OU 構造が必要です。グループ ポリシーを使用することによって、サイト、ドメイン、または組織単位内のユーザーおよびコンピュータの構成を標準化することができ、それによって個々のユーザーおよびコンピュータの構成に伴う管理面の負担が低減します。noam.reskit.com では、グループ ポリシーの対象をサイト レベルまたはドメイン レベルよりも細かく設定する必要があります。このために、OU 構造を使用します。

最後に、IT 部門によって管理されるリソース (ユーザーやコンピュータなど) と、個々の部門で保持されるリソース (部門のファイルなど) を論理的に分離する OU 構造が必要です。したがって、ドメイン内で表された各部門で内部活動を管理しながら、ドメインの IT スタッフが各部門のインフラストラクチャを管理することを可能にする構造を構築することが目標になります。

設計の原理

このシナリオの OU 構造は、次の設計の原理に従っています。

  • OU **を作成する確固とした理由があります。**OU を作成する主な理由は、管理権限を委任し、グループ ポリシー設定を適用することにあります。noam.reskit.com ドメイン内のオブジェクトに関する管理権限を委任するために、親レベルまたは子レベルのいずれかで、OU 構造全体を使用します。現在のドメインの管理要件に基づいて、ドメインのサーバーおよびクライアントに対する管理用ユーザー アカウントおよびコンピュータ アカウントを含む OU に GPO を適用しました。OU 構造全体で、委任およびグループ ポリシーをどのように使用したかについては、「実装した方法」を参照してください。

  • **安定した構造を設計します。**管理作業を容易にするために、OU を使用してオブジェクトをグループ化します。OU 構造内では、比較的安定していて、コア ビジネス ユニットであり、その地理的な属性から、noam.reskit.com を基準にしてオブジェクトをグループ化します。プロジェクトごとにオブジェクトをグループ化することは避けました。この理由としては、大半のプロジェクトが短期的な性質を持つことなどが挙げられます。OU 設計では、OU 構造自体を変更しなくても、ドメイン内の組織変更に対応できる構造を実現することが目標になります。

  • OU **構造をできる限り簡単にします。**OU 構造が過度に複雑な場合、アクセス許可と GPO の追跡作業が手に負えなくなる場合があります (特にセキュリティ グループ フィルタ処理を使用する場合) 。OU 構造の設計が不完全だと、OU を使用してもドメインを効率的に管理できず、OU の管理にかかる時間を短縮できないケースもあります。

noam.reskit.com OU の構造

図 2 に、noam.reskit.com ドメインの OU 構造を示します。

ou-hierarchy
図 2: noam.reskit.com の OU 構造

注意
上記の図は、noam.reskit.com 用に実装した OU 階層だけを示しています。ほかのコンテナ オブジェクトは含まれていません。

OU 構造をよりわかりやすく表すために、最初のレベルの (親) OU を図 3 に示します。

ou-first-tier
図 3: 最初のレベルの OU

最初のレベルの各 OU と、その子 OU の詳細については、以降の節で説明します。

Domain Controllers OU
Domain Controllers OU は、Active Directory 内に既定で存在します。この OU には、ドメイン内のすべてのドメイン コントローラのコンピュータ アカウントが含まれます。この OU に適用されているアクセス許可と GPO を変更する理由は特にないため、そのまま使用します。

Admins OU
ドメイン全体の管理権限がさまざまなセキュリティ グループに分散されるので、このようなグループのメンバシップを常に厳密に管理することが重要です。したがって、Admins OU を作成し、この OU に含まれるすべての管理用のユーザー アカウント、コンピュータ アカウント、およびセキュリティ グループに対するフル コントロールを Noam Administrator Account Admins セキュリティ グループに委任します。

Admins OU には、以下のものが含まれます。

  • ドメイン IT スタッフを含める一連のセキュリティ グループ。ドメイン IT スタッフは、ドメイン内のすべてのユーザーとコンピュータを管理します。

  • ドメインの IT スタッフの個々のユーザーおよびコンピュータ アカウント。

  • ドメインの各部門のリソースを管理する非 IT 部門の管理者。

    メモ ドメインの IT スタッフのユーザー アカウントとコンピュータ アカウントを個別に Admins OU 内に配置すれば、GPO を OU に適用することによって、GPO の対象を管理ユーザーに限定できます。

Admins OU に含まれる各セキュリティ グループを以下に示します。

ビルトイン セキュリティ グループ
以下のWindows 2000 ビルトイン グループを Active Directory の Users コンテナ内の既定の場所から Admins OU に移動させます。

  • Domain Admins
    このビルトイン グループのメンバは、ドメイン内のすべてのオブジェクトに対するフル コントロールを持ちます。

  • Group Policy Creator Owners
    このビルトイン グループのメンバは、ドメインの GPO を作成できます。

作成するセキュリティ グループ
以下を管理するためのセキュリティ グループを作成しました。

  • ユーザー アカウント

  • コンピュータ アカウント

  • コンピュータ

    注意
    Windows 2000 では、用語 "ユーザー アカウント" および "コンピュータ アカウント" は、"ユーザー オブジェクト" および "コンピュータ オブジェクト" と同義に使用されます。たとえば、コンピュータ "アカウント" を作成すると、そのアカウントはコンピュータ "オブジェクト"として Active Directory 内に発行されます。"コンピュータ" は、物理的なコンピュータを表します。コンピュータ "アカウント" (したがって "オブジェクト") の作成権限を有する管理者とは異なる管理者がコンピュータを保守する権限 (たとえばサーバーのバックアップ) を持つ場合もあります。

作成した各セキュリティ グループをドメイン ローカル グループにして、権利およびアクセス許可の割り当てを noam.reskit.com ドメイン内のみで有効にすることができます。

ドメイン ユーザーおよびコンピュータ アカウントを管理する IT 管理者のための以下のセキュリティ グループを作成します。各グループには、担当するアカウントの作成、削除、変更を行う権限を与えます。

  • Noam Administrator Account Admins
    Admins OU に含まれるすべてのユーザー アカウントおよびコンピュータ アカウントに対するフル コントロールと、すべてのセキュリティ グループのメンバシップに対するフル コントロールをこのグループに委任します。

  • Noam User Account Admins
    Noam Users OU のユーザー アカウントに対するフル コントロールをこのグループに委任します。

  • Noam Service Account Admins
    Service Accounts OU のユーザー アカウントに対するフル コントロールをこのグループに委任します。

  • Noam Computer Account Admins
    Seattle Computers、Boston Computers、および Vancouver Computers の各 OU の子 OU (Servers および Clients) 内のすべてのコンピュータ アカウントに対するフル コントロールをこのグループに委任します。

ドメインのコンピュータを管理する IT 管理者のための以下のセキュリティ グループを作成します。各グループにそれぞれの管理権限を与えるには、ドメインのすべてのサーバーまたはすべてのクライアントのいずれかで、ローカル Administrators グループのメンバとして各グループを追加します。noam.reskit.com のコンピュータを管理するためにどのようにして OU 構造を使用したかについては、このシナリオの「実装した方法」の「グループ ポリシーによるドメインのコンピュータの管理」を参照してください。

  • Noam Server Admins
    ドメイン全体のサーバーを集中的に管理するために Noam Server Admins グループを作成します。このグループは、サーバーの起動とシャットダウン、ドライバおよび Windows コンポーネントのインストール、サーバーのバックアップおよび復元などの作業を実行するための管理権限を持ちます。

  • Noam Help Desk
    クライアント コンピュータをインストール、保守する場合や、ハードウェアまたはソフトウェアに関連する問題を抱えるユーザーを支援する場合に役立つ Noam Help Desk グループを作成します。

  • Boston Admins
    Boston 内のすべてのコンピュータを管理するために Boston Admins グループを作成します。

  • Vancouver Admins
    Vancouver 内のすべてのコンピュータを管理するために Vancouver Admins グループを作成します。

    注意
    Boston Admins グループおよび Vancouver Admins グループは、それぞれの場所でコンピュータ アカウントを作成、管理する権限を持ちません。コンピュータ アカウントに対する集中的な管理を行うために、このための権限を Noam Computer Account Admins に委任します。

noam.reskit.com ドメイン内で表される各部門のリソースを管理する部門管理者のために以下のセキュリティ グループを作成します。

  • Human Resources Admins

  • Accounting Admins

  • Finance Admins

  • Legal Admins

  • Sales and Support Admins

  • Engineering Admins

  • Research and Development Admins

  • Facilities Admins

  • Manufacturing Admins

これらのセキュリティ グループに委任された権限をどのように行使するかについては、このシナリオの「Departmental Resources OU」で後述します。また、「実装した方法」の「部門間のリソースの共有」も参照してください。

注意
部門管理者のセキュリティ グループのメンバにはドメインの IT スタッフは含まれません。それでも、これらのグループを Admins OU に配置します。これによって、グループのメンバシップを Noam Administrator Account Admins グループによって管理できるようになります。部門管理者グループのメンバの個々のユーザー アカウントを Noam Users OU に配置します。

管理者のワークステーションをパスワード付きのスクリーン セーバーで保護するように Admins OU に GPO を適用します。この措置は、管理者がワークステーションから離れているときに、他人がネットワークへの管理アクセス権限を獲得することを抑止するために役立ちます。

Microsoft Windows 2000 管理ツールを発行する GPO をドメイン レベルで適用し、Admins OU 内のグループのみを対象にするように GPO にフィルタを適用します。この対象グループのメンバは、ドメイン内の任意のワークステーションにログオンし、通常はサーバーにのみインストールされる管理ツールを使用できます。以下の目的のために、このGPOを適用しました。

  • ネットワークの任意の場所で発生する可能性のある問題を管理者が容易にトラブルシューティングできます。

  • 部門管理者がそれぞれの部門の OU 内でグループや共有フォルダを作成するために必要になる [Active Directory ユーザーとコンピュータ] スナップインを使用できます。

    注意
    セキュリティ グループごとにフィルタを GPO に適用する方法について詳しくは、「実装した方法」の「グループ ポリシーによるソフトウェアの配布」を参照してください。

Noam Users OU
ドメイン内のセキュリティを強化するために、主要なドメイン ユーザーのアカウントを管理するのと同じセキュリティ グループで管理者のユーザー アカウントを管理することは避けることにします。したがって、Noam Users OU を作成し、この OU に含まれるすべての非管理用ユーザー アカウントに対するフル コントロールを Noam User Account Admins セキュリティ グループに委任します。

管理用ユーザー アカウントと非管理用ユーザー アカウントを分離する以外に、使用者のユーザー アカウントと、サービスの動作するユーザー アカウントを分ける必要があります。したがって、Noam Users OU 内にすべての非管理者のユーザー アカウントを配置し、Service Accounts OU を作成してすべてのサービス アカウントを Accounts OU に含めます (以下で説明します) 。

Service Accounts OU
ネットワーク リソースへのアクセスを必要とするサービスのうちのいくつかは、ユーザー アカウントの下で動作します。Noam Users OU に含まれる使用者のユーザー アカウントからサービス ユーザー アカウントを分離して識別するために、Service Accounts OU を作成します。さらに、各種のユーザー アカウントを個別の OU に配置することによって、そのユーザー アカウントの管理要件に合わせた管理を行うことができます。

Service Accounts OU を管理するために、Noam Service Account Admins セキュリティ グループを作成し、Service Accounts OU 内に含まれるすべてのユーザー アカウントに対するフル コントロールを このセキュリティ グループに委任します。

Departmental Resources OU
各部門で独自のリソースを管理できるように、Departmental Resources OU を作成します。図 4 で示すように、この OU には 9 つの子 OU が含まれ、そのそれぞれが noam.reskit.com ドメイン内の各部門を表します。各子 OU には、それぞれの部門の管理グループによって管理される共有フォルダとセキュリティ グループが含まれます。

ou-second-tier
図 4: 部門のリソースと子 OU

このシナリオの「Admins OU」で前述したように、各部門の部門管理者用のセキュリティ グループを作成しました。そして各グループに、それぞれの OU の境界内のグループ オブジェクトおよび共有フォルダ オブジェクトに対するフル コントロールを委任しました (たとえば、Accounting Admins グループは、Accounting OU 内の共有フォルダ オブジェクトに対するフル コントロールを持ちます) 。部門管理者は、部門サーバー上の共有フォルダに含まれるファイルへのアクセスを管理するために、グループ メンバシップを操作できます。このようにして、それぞれの部門では内部ファイルを管理し、部門管理者の判断でほかの部門とファイルを共有できます。

注意
部門管理者は、共有フォルダおよびグループ オブジェクトに対してのみフル コントロールを持ちます。ユーザー オブジェクトなど、その他のクラス オブジェクトを作成することはできません。 部門間で情報を共有する方法については、このシナリオの「実装した方法」の「部門間のリソースの共有」を参照してください。

Seattle 、 Boston 、および Vancouver Computer の OU
コンピュータ オブジェクトを地理的な位置によってグループ化することによって、Boston および Vancouver のローカル IT スタッフに制御を委任でき、したがって、ローカル IT スタッフが Seattle の中央 IT スタッフに依存せずにコンピュータの日常の保守作業を実行できます。たとえば、Boston で午前 8 時にプリント サーバーに障害が発生した場合、Seattle のサーバー管理者が出社するまで 3 時間待つことなく、Boston のサーバー管理者が問題をトラブルシューティングできます。しかしそれと同時に、ドメイン内ですべてのコンピュータ アカウントに対する集中的な管理を維持する必要もあります。

これらの管理要件を満たすために、Seattle、Boston、および Vancouver Computer OU を作成しました (図&nbsp5 を参照) 。

ou-computers
図 5: Seattle、Boston、および Vancouver のコンピュータの親 OU と子 OU

各親 OU には 2 つの子 OU があり、一方の子 OU にはそれぞれの場所のクライアントコンピュータのアカウントが含まれ、もう一方の子 OU にはサーバー コンピュータのアカウントが含まれます。子 OU Servers をすべて合わせると、ドメイン内のサーバー アカウントが、Domain Controllers OU に含まれるアカウントを除いてすべて含まれます。子 OU Clients をすべて合わせると、Admins OU 内のクライアント コンピュータ アカウントが、Admins OU に含まれるアカウントを除いてすべて含まれます。

子 OU に含まれるコンピュータ アカウントに対するフル コントロールを Noam Computer Account Admins セキュリティ グループに委任します。

ドメインのサーバー コンピュータを管理するために、各 Servers 子 OU に個別に、以下を許容する GPO を適用します。

  • Noam Server Admins セキュリティ グループにドメイン内のすべてのサーバーに対するフル コントロールを与えるために、ドメイン内のすべてのサーバー上のローカル Administrators グループに Noam Server Admins を追加します。

  • Boston Admins および Vancouver Admins の各セキュリティ グループに、それぞれの場所のサーバーに対するフル コントロールを与えるために、それぞれの場所のすべてのサーバーのローカル Administrators グループに Boston Admins および Vancouver Admins を追加します。

ドメインのクライアント コンピュータを管理するために、各子 OU Clients に同様の GPO を適用します。この GPO では、Noam Help Desk セキュリティ グループでクライアント コンピュータに対する集中管理を可能にし、Boston Admins および Vancouver Admins の各セキュリティ グループでそれぞれの地域の管理を可能にします。

このシナリオで適用した GPO について詳しくは、このシナリオの「実装した方法」の『グループ ポリシーによるドメインのコンピュータの管理』を参照してください。

実装した方法

このシナリオの各作業を実行するために、適切なセキュリティ グループのメンバとして、Microsoft Windows 2000 リソース キット導入実験で使用している Seattle の Windows 2000 Professional ベースのコンピュータにログオンします。

注意
最善の慣行に従えば、ドメイン コントローラではないワークステーション コンピュータまたはサーバー コンピュータから Active Directory を管理する必要があります。ドメイン コントローラは通常、IT 管理者のみが直接管理するセキュリティで保護されたコンピュータです。リソース キット導入実験では、各ドメインの管理用ワークステーション コンピュータに管理ツールをインストールしました。Windows 2000 ベースのコンピュータに管理ツールをインストールする方法の詳細については、Windows 2000 Server ヘルプ の「ユーザーとコンピュータ」の「サーバーをリモートで管理する」を参照してください。

表 1 に、リソース キット導入実験のこのシナリオを開発するために使用したハードウェアおよびソフトウェアのリストを示します。

表 1 リソース キット導入実験で使用したコンポーネント

コンポーネント

ハードウェア

ソフトウェア

Noam.reskit.com ドメイン コントローラ

SEA-NA-DC-01

Compaq サーバー

Windows 2000 Server

Seattle の Noam.reskit.com ファイル サーバー

SEA-NA-FP-03

Compaq サーバー

Windows 2000 Server

ファイル/プリント サーバー

Seattle の Noam.reskit.com 管理クライアント

W2P

Compaq Desktop コンピュータ

Windows 2000 Professional

Windows 2000 Server 管理ツール (adminpak.msi)

Boston の Noam.reskit.com 管理クライアント

W2P

Compaq Desktop コンピュータ

Windows 2000 Professional

Vancouver の Noam.reskit.com 管理クライアント

W2P

Compaq Desktop コンピュータ

Windows 2000 Professional

注意
このシナリオでは、すべての手順を Windows 2000 Server 管理ツール (adminpak.msi) を使用して、Seattle 内の Noam.reskit.com 管理クライアント (W2P) から実行しました。Boston および Vancouver のクライアント コンピュータは、テスト目的のためだけに使用しました。

注意
このシナリオにおいてコンピュータおよびデバイスを構成するために使用した手続きはサンプルとして示したものです。実際の各ネットワークでは、類似したコンピュータおよびデバイスを構成する場合でも、必要になる手順はそれぞれのケースで異なります。さらに各シナリオでは、そのシナリオの機能を実現するために必要な手順だけを示しています。運用ネットワークにおいて必要になるその他の手順については取り上げていません。

このセットアップ手順では、以下のことを仮定しています。

  • このシナリオで示した OU 構造は、OU 構造の目的とその実装手順を説明することを意図して設計されています。この構造は、任意のドメインに汎用的に適用できるテンプレートあるいは動作モデルとしてではなく、単なるサンプルとして掲載しています。この OU 構造は、noam.reskit.com ドメイン独自の管理要件を基準に構築されています。noam.reskit.com 以外のドメインの OU 構造の場合には、そのドメインの独自の管理要件を基準にして決定することになります。

  • このシナリオでは、Windows 2000 の新規インストールの一環として OU 構造を構築しました。つまり、以前のバージョンの Windows から Windows 2000 への移行作業は行っていません。したがって、2 つのビルトイン セキュリティ グループ (Domain Admins と Group Policy Creator Owners) を除いて、既存のオブジェクトを既定の場所 (たとえば Users コンテナや Computers コンテナ) から移動しませんでした。そして、ユーザー、コンピュータ、およびグループのオブジェクトを作成したときに、これらのオブジェクトを適切な OU に格納しました。

  • 前述したように、リソース キット導入実験では OU 構造の実装およびテストを Seattle 内のクライアント コンピュータ (W2P) から行いました。必要な作業を実行するために、通常はサーバーにのみインストールされる管理ツールを W2P クライアントにインストールしました。しかし、このシナリオで記述した noam.reskit.com の構成では、管理セキュリティ グループのメンバが委任された作業を個人のワークステーションから実行することを仮定しています。したがって次の節では、この作業のための機能を用意する手順を説明します。

セットアップ手順

このシナリオをセットアップするために、以下の作業を実施しました。

  1. 親 OU と子 OU の作成

  2. ビルトイン セキュリティ グループの Admins OU への移動

  3. Admins OU への新しいセキュリティ グループの追加

  4. セキュリティ グループへの管理権限の委任

  5. セキュリティ グループへのメンバの追加

  6. グループ ポリシーによるソフトウェアの配布

  7. 管理者のワークステーションのパスワードによる保護

  8. OU 構造への格納

  9. グループ ポリシーによるドメインのコンピュータの管理

  10. 部門間のリソースの共有

その他の参考資料

このシナリオに関係する情報について、以下の資料が参考になります。

導入実験のシナリオ

Windows 2000 リソース キット
以下は、『Microsoft Windows 2000 Professional リソース キット』および『Microsoft Windows 2000 Server リソース キット』の参考資料です。オンラインで概要を参照できる章もあります。

  • Active Directory 組織単位については、『Microsoft Windows 2000 Server リソース キット 3 分散システムガイド 上』の「第 1 章 Active Directory の論理構造」を参照してください。

  • 組織単位の計画の作成については、『Microsoft Windows 2000 Server リソース キット 1 導入ガイド』の「第 9 章 Active Directory 構造の設計 (概要紹介) 」 (英語) を参照してください。

ホワイト ペーパー

  • グループ ポリシーの応用例については、『Implementing Common Desktop Management Scenarios』 (英語) を参照してください。

  • グループ ポリシーの機能に関する技術的な情報については、『Step-by-Step Guide to Understanding the Group Policy Feature Set』 (英語) を参照してください。

  • グループ レベルのポリシーによって IntelliMirror 機能で Windows 2000 ベースのユーザー データ、設定、およびソフトウェアを管理する方法については、『IntelliMirror Lets Your Information 'Follow' You 』 (英語) を参照してください。

導入実験の詳細と協力企業について

リソース キット導入実験シナリオの凡例

  • Microsoft Windows 2000 リソース キット導入実験シナリオのネットワーク図で使用されている略語や記号について詳しくは、『導入実験シナリオの凡例』を参照してください。

リソース キット導入実験のネットワーク図

  • ネットワークの設計、ネットワーク ルーティング設計、ドメイン ネーム システム (DNS) 設計、および Active Directory 階層の高水準の編成については、『導入実験のネットワーク図』を参照してください。

関連資料

注意

このシナリオにおいて、コンピュータおよびデバイスを構成するために使用した手続きは、サンプルとして紹介したものです。実際のネットワークでは、類似したコンピュータおよびデバイスを構成する場合でも、必要になる手順はそれぞれのケースで異なります。さらに各シナリオでは、目的とする機能を実現するために必要な手順だけを示しています。運用ネットワークにおいて必要になる、その他の手順については取り上げていません。すべてのシナリオは、特に表記しない限り Windows 2000 を使用してテストされています。また、ブラウザとして Microsoft Internet Explorer 5 以上を推奨します。