Clever Geek Handbook

操作の達人について知りたいが、尋ねることを恐れていたすべて



企業環境のほとんどのシステム管理者は、Active Directoryドメインサービスを使用します。ActiveDirectoryドメインサービスは、エンタープライズインフラストラクチャ全体の中心と安全に呼ばれ、ユーザーを識別してエンタープライズリソースにアクセスするシステムを提供します。 多くの人が知っているように、組織のドメインサービスの構造には、信頼範囲の制限、ネットワークの完全な分離などの要因に応じて、1つまたは複数のフォレスト（ネットワーク構成の説明とディレクトリの単一コピーを含むドメインのセット）を含めることができます管理分離を受け取るデータ。 次に、各大規模フォレストをドメインに分割して、管理とデータ複製を簡素化する必要があります。 各ドメインは、ドメインコントローラーを使用してドメインサービスを管理し、認証、 Kerberosキー配布センターサービスの開始、アクセス制御などのタスクを実行します。 そして、オフィス間のネットワークトラフィックを管理するために、サイトを開発しました。

もちろん、フォレスト、ドメイン、およびサイトに関するすべての情報は、ビジネス要件、機能要件、法的要件、セキュリティ要件、ドキュメントの設計制限などの企業要件に従って、Active Directoryドメインサービスを設計するときに合意する必要があります。 多くの場合、ドメインサービスの展開前のこれらすべてのポイントは、企業自体のIT部門または企業のインフラストラクチャに関与するプロジェクトチームによって慎重に計画され、提供されるサービスの速度と品質の予想レベルを決定する特別なサービスレベル契約に記録されます。

設計後、またはほとんどの場合、Active Directoryドメインサービスの展開後に取得した情報は、慎重に文書化する必要があります。 そのようなドキュメントには、ドメインサービスの論理的および物理的な構造、管理モデル、名前解決インフラストラクチャ、組織の環境で計画されているすべての変更、Microsoft Exchangeメールサーバー、System Centerサーバーの実装などの追加のインフラストラクチャコンポーネントに関する情報を含める必要がありますはるかに。 ほとんどの場合、組織のITスタッフは文書化プロセスを無視し、ITスタッフを変更する場合、新しい管理者は組織の現在のインフラストラクチャを完全にナビゲートするのに時間がかかる場合があります。

また、ディレクトリサービスでは、ほぼすべてのドメインコントローラーが等しいことを理解する必要があります（このコンテキストでは、読み取り専用ドメインコントローラー、RODCは考慮しません）。つまり、すべてのドメインコントローラーがデータベースへの書き込みアクセス権を持ち、このデータを他のコントローラー。 このトポロジは、Active Directoryのささいな操作のほとんどを処理し、多くのピア（マルチマスター）とのレプリケーションと呼ばれます。 ただし、それでも、そのような操作のために直接指定された許可サーバーで実行する必要がある操作がいくつかあります。 つまり、ドメイン内で特定の操作または役割を実行するドメインコントローラーは、操作のマスター（または所有者）と呼ばれます。 災害復旧、更新、または移行の場合、最も重要な役割の1つを果たすことができるのは操作マスターの役割を果たすドメインコントローラーであるため、操作マスターのすべての役割の目的を知って理解する必要があります。 したがって、この記事で説明する操作の達人についてです。

この記事から次のことを学びます。



現在の記事では考慮されないもの：



操作のマスターがいなかったらどうなるでしょう



特定の操作を実行するドメインコントローラーと他のドメインコントローラーを区別しないActive Directoryドメインコントローラーの状況を想像する前に、操作ウィザードの役割を備えたドメインコントローラーの利点を検討します。

まず、この記事の入門セクションで既に示したように、ドメインコントローラは操作のウィザードと呼ばれ、Active Directoryで整合性を保証し、競合を回避するように設計された特別な役割を果たします。 この目的のために、このようなドメインコントローラーに特別な役割が割り当てられます。これらの役割は1つのドメインコントローラーへの厳密なバインドを持たないため、そのような役割は操作マスター（Flexible Single Master Operation、FSMO、fizz-moと発音）と呼ばれます。 実際、他のドメインコントローラーはこれらの役割を実行できますが、各役割は1つのドメインコントローラーにのみ割り当てる必要があり、同時に、操作マスターのドメインコントローラーで実行する必要があるアクションを1つのドメインで実行することはできません。

ウィザードが使用するプロトコルを知ることは役立つと思います。 操作ウィザードは3つのプロトコルを使用します。





ここで、Active Directoryドメインサービスに操作ウィザードがなかった場合、つまりすべてのドメインコントローラーが同じアクションを同時に実行できる場合に何が起こるかを想像してください。

1つのフォレストと5つのドメインを持つ組織があるとします。 各ドメインで、システム管理者はMicrosoft Exchangeメールサーバーを同時にインストールすることを決定し、1つのドメインでは、管理者がこのメールサーバーの2007バージョン、2番目-2000、3番目のMicrosoft Exchange Server 2010 SP1をインストールします。 ドメインスキームのすべての変更、したがってフォレスト全体は、管理者が接続したドメインコントローラーに記録され、しばらくすると、Active Directoryスキームに加えられたすべての変更が組織のフォレスト内の各ドメインコントローラーに複製されます。

誰かがRendom.exeシステムユーティリティを使用してドメインの名前を変更したい場合、別のドメインが既に名前が付けられていて、対応するFSMOの役割がエンタープライズにない場合、管理者は「何をしていますか-それから？ すでにそのようなドメインがありますが、すべてを壊しますか？」そして、ドメインの名前が変更されます。複製後、致命的な問題を回避することは不可能になります。

別の例を挙げましょう...繰り返しますが、自然界には操作の達人はいません。 クライアントマシンでは時間が失われ、ユーザー自身が誤って時間を変更する可能性がありますが、デフォルトドメイン内のすべてのクライアントは、最も近いドメインコントローラーと時間を同期する必要があります。 この場合、特定のドメインコントローラー、いわゆるリーディングタイムソースがない場合、ドメイン全体の各ユーザーの時間が異なる可能性があり、これは一部のビジネスアプリケーションにとって重要な場合があります。

実際、経営者が不足しているため、企業の黙示録の例は無限にあります。 一番下の行は、操作マスターは単純にアクセス可能でなければならず、アクセス可能でなければならず、それらを対象とする操作のみを実行する必要があるということです。

合計で、Active Directoryドメインサービスには、操作ウィザードの5つの異なるロールが含まれます。つまり、フォレストレベルで2つのロールが使用されます。 ドメインネーミング ウィザードとスキーマウィザードです 。各フォレストは、各ロールが割り当てられたドメインコントローラーを1つしか持つことができません。 各ドメインには、操作のマスターに対して3つの役割のみがあります。 相対RID識別子 ウィザード、インフラストラクチャウィザード 、およびPDCマスタードメインコントローラーのエミュレーターです 。 つまり、フォレストに最初のドメインコントローラーをインストールすると、操作マスターの5つの役割すべてが同時に割り当てられ、既存のフォレストに新しいActive Directoryドメインを作成すると、3つのドメインレベルの役割が新しいドメインコントローラーに割り当てられます。 フォレスト内のFSMOおよびこれらの役割の潜在的な所有者の数は、「（ドメイン数* 3）+ 2」という式を使用して計算できます。

たとえば、メインドメインの1つに子ドメインと孫娘ドメインがある4つのドメインを持つActive Directoryフォレストがある場合、そのようなフォレストには14個のFSMOロールが含まれます。 つまり、1つのスキーママスター、1つのドメイン名前付けマスター、4つのPDCエミュレーター（1つの役割を持つ2つのプライマリ、子、孫ドメイン）、各ドメインに4つのRIDホスト、各ドメインに4つのインフラストラクチャウィザード。

この段階で、フォレストレベルとドメインレベルで運用マスターの各役割を検討する時が来たと思います。



フォレストレベルの操作ウィザードの役割



上で書いたように、Active Directoryフォレストレベルのオペレーションウィザードには2つの役割があります。



スキーマウィザードの役割



スキーママスターの役割について少し説明する前に、 「Active Directoryスキーマ」とは正確には何であるかを一言で言うのは理にかなっていると思います。

-ホリネを見る？

-いいえ。

-そして、私は見ていません。 しかし、彼はそうです！

K.F. 「DMB」



多くの初心者管理者にとって、Active Directoryスキーマは、有名な映画の上記の表現に関連付けることができます。 回路のようなものがあるので、どうやらそれが必要であり、それが何であり、実際にそれが何であるか、誰もそれを知りませんし、急いでそれを知ることはありません。

用語によると、スキーマには、Active Directoryフォレストで作成および保存される各属性とクラスの定義が含まれます。 Active Directoryドメインサービスが多くのエンタープライズアプリケーションから必要な情報を適切なタイミングで保存および取得するというニュースをだれも見つけることはまずないと思います。 これは、必要に応じて、アプリケーションがエンタープライズインフラストラクチャのさまざまなコンポーネントにアクセスするのではなく、Active Directoryドメインサービスにアクセスし、その情報がすべてのドメインコントローラーに複製されるようにするためです。 各Active Directoryフォレストには、フォレスト内の各ドメインコントローラーに複製できるスキームが1つしかないことに注意してください。 したがって、Active Directoryスキーマで競合を引き起こす可能性のある複数のアプリケーションを組織に展開する場合は、2つの別個のフォレストを展開して維持することをお勧めします。

スキーマ自体はclassSchemaおよびattributeSchemaオブジェクトで構成され、ドメインサービスで必要なオブジェクトを定義するときに要求されます。 クラス自体はスキームにあるいくつかの定義であり、定義は属性のグループを定義します。 各クラスは多くの属性を使用できることに注意してください。 最後に、Active Directoryドメインサービスにある各属性について、スキーマは属性自体の構文としてデータ型を示します。 もちろん、クラスインスタンスに含まれる各属性の値は、現在の属性の構文要件に準拠する必要があります。

Active Directoryスキーマの詳細な説明はこの記事の範囲を超えているため、上記の定義は十分すぎると思います。 Active Directoryの詳細については、次のいずれかの記事をご覧ください。 ここで、マスター回路の役割を構成するものを見てみましょう。

スキーママスターであるドメインコントローラーは、Active Directoryフォレストのスキーマに加えられたすべての変更を担当します。 この役割を担当するドメインコントローラーはフォレスト全体で唯一である必要があり、他のすべてのドメインコントローラーにはフォレストスキーマの読み取り専用レプリカのみが含まれることを覚えておく必要があります。 つまり、Active Directoryスキーマを手動で変更する場合、またはスキーマを変更するアプリケーションをインストールする場合、管理者はこの役割を管理するドメインコントローラーを変更する必要があります。 変更を行うには、管理者はスキーママスターに接続し、Schema Adminsセキュリティグループのメンバーである必要があります。 スキーマが更新されると、スキーママスタから他のすべてのドメインコントローラに複製されます。 スキームマスターとして機能するドメインコントローラー上ではないスキームを変更しようとすると、通常、アクションは失敗し、スキームを変更した後、スキームマスターの役割を持つドメインコントローラーに送信します。 したがって、無効なスキーマウィザードを使用してActive Directoryスキーマを変更しようとすると、常にエラーが発生するため、この役割は重要です。 同様に、スキーママスタの役割は、フォレスト内でこの目的に割り当てられた任意のドメインコントローラーに配置できます。

既定では、スキーママスタの役割は、フォレストにインストールされている最初のドメインコントローラーに割り当てられます。この役割は、1つのドメインコントローラーで、後述するドメイン名前付けウィザードの役割と一緒に配置することをお勧めします。 推奨事項にもかかわらず、 Active DirectoryスキーマスナップインまたはNtdsutilコマンドラインユーティリティを使用して、いつでもこの役割を任意のドメインコントローラーに移動できます。 この記事では、他のドメインコントローラーへの役割の転送についても学習します。 スキーママスターは、スキーマセクションのルートオブジェクトのfSMORoleOwner属性の値によって識別されます。



ドメイン名前付けウィザードの役割





次に考慮される役割は、ドメイン名前付けウィザードと呼ばれます。 この役割は操作ウィザードであるため、この役割を含むことができるフォレスト内の唯一のドメインコントローラーは、主にフォレスト階層内のドメインとすべてのディレクトリセクションを追加および削除するために使用されます。 ドメイン名前付けウィザードの役割を持つドメインコントローラーは、次の4つの操作を実行するように設計されています。



既定では、新しいフォレストの最初のドメインコントローラーはドメイン名前付けウィザードの役割を受け取りますが、Active Directoryドメインと信頼スナップインまたはNtdsutil.exeコマンドラインユーティリティを使用して、いつでもこの役割を移動できます。 スキーママスターとドメイン名前付けウィザードの役割を同じドメインコントローラーに配置することをお勧めします。 ドメイン名前付けマスターの役割が割り当てられているドメインコントローラーもグローバルカタログサーバーである必要があります。 そうしないと、一部の操作が失敗する場合があります。 回線のマスターは、パーティションコンテナのfSMORoleOwner属性の値によって識別されます。

前の操作ウィザードと同様に、操作ウィザードが使用できないときに上記の操作のいずれかを実行しようとすると、アクションは失敗します。 ただし、これらのすべてのアクションは長期間にわたってほぼ1回実行されるため、ドメインネーミングウィザードが使用できない状態にあることがわかります。したがって、フォレスト操作ウィザードの可用性を定期的に確認してください。



ドメインレベルウィザードの役割



フォレストレベルとは異なり、各Active Directoryドメインには、操作ウィザードに対して次の3つの役割があります。



これらの各操作マスターを詳細に検討してください。



RIDマスター





この記事で説明する最初のドメインレベルの操作ウィザードは、相対識別子（RID）ウィザードです。 RIDウィザードを使用してRIDのプールを管理し、ユーザー、グループ、コンピューターなどのセキュリティプリンシパルのセキュリティ識別子（SID）を生成したり、オブジェクトをあるドメインから別のドメインに移動したりします。 セキュリティプリンシパルのSIDはドメイン全体で一意である必要があるため、各セキュリティプリンシパルには、ドメイン識別子と各セキュリティプリンシパルに一意の相対RIDを含む一意のSIDが割り当てられます。 すべてのSIDには4つの異なる要素があります。 たとえば、Microsoftのドキュメントによると、S1-5-Y1-Y2-Y3-Y4識別子要素は次の表に記載されています。

表1. identifierエレメントの構造

SID要素 説明
S1 SIDのリビジョンを示します。 現在、SIDには1つのリビジョンのみが使用されています
5 セキュリティプリンシパル発行センターを示します。 5の値は、Windows NT、Windows 2000、Windows 2003、Windows 2008、およびWindows 2008 R2ドメインに対して常に指定されます。
Y1-Y2-Y3 ドメインSIDの一部。 ドメインで作成されたセキュリティプリンシパルの場合、この識別子要素は同一です。
Y4 ユーザーまたはグループの名前を表すドメインの相対識別子（RID）。 この項目は、オブジェクトの作成中にドメインコントローラーのRIDプールから生成されます。


ドメインコントローラーはセキュリティプリンシパルを作成できるため、ドメインコントローラーによって生成されるSIDの一意性を保証するメカニズムが必要です。したがって、RIDウィザードは、2つのドメインコントローラーが同じRIDを割り当てないようにします。 RIDウィザードは、RIDプールと呼ばれる相対RIDのブロックをドメイン内の各コントローラーに割り当てます。 つまり、RID操作ウィザードは、ドメイン内のドメインコントローラーを使用するための相対識別子のプールを維持し、各ドメインコントローラーに相対識別子のグループを提供します。 新しいドメインコントローラーがドメインに追加されると、RIDマスターは500の相対RID要求のプールをこのドメインコントローラーに割り当てます。 ドメインコントローラで新しいセキュリティプリンシパルが作成されるたびに、新しいオブジェクトに識別子を割り当てるために、ドメインコントローラはそのプールから相対識別子を割り当てます。 ドメインコントローラ上のこのRIDプール内の相対RIDの数が100を下回る、つまりゼロラインに近づくと、RIDマスターは別のRIDブロックを照会します。 要求の完了後、RIDウィザードは500の相対RIDの別のドメインプールをドメインコントローラーに割り当てます。

具体的には、RIDウィザードはプール番号を追跡しませんが、最後に割り当てられた範囲の最高値を提供します。 新しい要求を受信すると、新しいプールの値が1つ増加し、新しい値が499増加します。 その後、2つの値が要求されたドメインコントローラーに送信され、新しい相対RIDが使用されます。 ドメインコントローラーのローカルRIDプールが空であるか、RIDマスターがしばらく使用できない場合、一部のドメインコントローラーでアカウントを作成するプロセスが中断され、イベントコード16645がこのドメインコントローラーのイベントログに記録されます。ドメインコントローラーとドメインコントローラーに割り当てられたアカウント識別子は、RIDマスターから新しい識別子プールを受信できませんでした。 同様に、ドメインに新しいオブジェクトを追加すると、コード16650でイベントが生成され、ディレクトリサービスが相対識別子を割り当てられなかったためにオブジェクトを作成できなかったことを示します。RIDの新しいブロックの要求メカニズムは、プール内の使用可能なすべてのRIDが使い果たされる前に要求が実行されるため、このような中断を防ぐように設計されています。アカウント作成プロセスを再度有効にするには、RIDマスターの役割を管理するドメインコントローラーをネットワークに接続するか、この役割を別のドメインコントローラーに移動する必要があります。

また、ドメイン間でActive Directoryオブジェクトを移行するプロセスでは、RIDウィザードが必要です。つまり、RIDウィザードがドメインで利用可能な場合にのみオブジェクトを移行できます。アクティブな現在の操作ウィザードが存在するため、異なるActive Directoryドメインで同一の識別子を持つ2つのオブジェクトを作成できません。あるドメインから別のドメインにオブジェクトを移行する場合、MicrosoftはAcrive Directory Migration Toolの使用を推奨します。既定では、フォレストに最初にインストールされたドメインコントローラーがRIDウィザードの役割を受け取ります。Active DirectoryユーザーとコンピュータースナップインまたはNtdsutil.exeユーティリティを使用して、いつでもこの役割を移動できます。 RIDマスターは、属性値によって識別されます。DomainセクションのrIDManagerクラスオブジェクトのfSMORoleOwner。



PDCエミュレーター





指定されたPDCエミュレーター操作ウィザードを備えたドメインコントローラー（プライマリドメインコントローラーはプライマリドメインコントローラーです）プライマリドメインコントローラーとして機能し、Windows 2000以下のオペレーティングシステムとの下位互換性を提供します。メンバーサーバーおよびWindows NT 4.0クライアントコンピューターの時点では、プライマリPDCドメインコントローラーのみがディレクトリを変更できます。 Windows NT 4.0をサポートする以前のツール、クライアント、およびユーティリティは、すべてのActive Directoryドメインコントローラーがディレクトリに書き込みできるように設計されていないため、このようなアプリケーションにはPDC接続が必要です。 PDCエミュレーターの役割を持つドメインコントローラーは、特にさまざまな低レベルアプリケーションが書き込みドメインコントローラーをローカライズできるように、自身をマスターPDCドメインコントローラーとして登録します。にもかかわらず私たちの時代には、Windows 2000より下のオペレーティングシステムを搭載したサーバーやクライアントコンピューターを見つけることはほとんど不可能でしたが、PDCエミュレーターは依然として操作ウィザードの最も重要な役割のままです。 Windows NT 4.0で実行されるアプリケーションとの下位互換性に加えて、PDCエミュレーターは次の重要な機能を実行します。



既定では、フォレストに最初にインストールされたドメインコントローラーがPDCエミュレーターウィザードの役割を受け取ります。Active DirectoryユーザーとコンピュータースナップインまたはNtdsutil.exeユーティリティを使用して、いつでもこの役割を移動できます。PDCエミュレーターウィザードは、ドメインパーティションのルートにあるrIDManagerクラスオブジェクトのfSMORoleOwner属性の値によって識別されます。



インフラストラクチャマスター





複数のドメインに基づく組織では、一部のドメインのオブジェクトは他のドメインのオブジェクトを参照することがよくあります。インフラストラクチャマスタードメインのグループメンバーを追跡するデバイスに似ています。インフラストラクチャウィザードは、ドメイン間のグループユーザーリンクを更新し、オブジェクト名の変更がドメインにローカライズされたグループメンバーシップ情報に反映されるようにします。インフラストラクチャウィザードは、そのようなリンクの更新されたリストを維持し、この情報をドメイン内のすべてのコントローラーに複製します。別のドメインのメンバーをターゲットドメインのグループに追加すると、新しいメンバーの識別名がメンバー属性に追加され、そのようなグループのメンバーのドメインコントローラーが使用できない場合、実際にそのようなグループのメンバーを表すファントムオブジェクトがドメインサービスに作成されることに注意する必要があります。このようなオブジェクトには、メンバーSID、識別名（DN）、およびオブジェクトのGUIDのみが含まれる場合があります。インフラストラクチャウィザードが利用できない場合、ドメイン間のグループユーザーリンクは更新されません。インフラストラクチャウィザードは定期的にドメインアカウントをスキャンし、グループメンバーシップを確認します。ユーザーアカウントが新しいドメインに移動されると、インフラストラクチャウィザードはユーザーアカウントの新しいドメインを識別し、それに応じてグループを更新します。

インフラストラクチャウィザードの役割は、グローバルカタログサーバーであるドメインコントローラーによって実行されるべきではないことに注意してください。そうでない場合、インフラストラクチャウィザードはオブジェクトに関する情報を更新しません。これは、保存されないオブジェクトへの参照が含まれていないためです。これは、グローバルカタログサーバーがフォレスト内のすべてのオブジェクトの部分的なレプリカを格納するためです。その結果、このドメインのクロスドメインオブジェクトリンクは更新されず、対応する警告がこのドメインコントローラーのイベントログに表示されます。既定では、フォレストに最初にインストールされたドメインコントローラーがインフラストラクチャウィザードの役割を受け取ります。Active Directoryユーザーとコンピュータースナップインまたはユーティリティツールを使用して、いつでもこの役割を移動できます。Ntdsutil.exe。インフラストラクチャウィザードは、ドメインセクションのインフラストラクチャコンテナのfSMORoleOwner属性の値によって識別されます。



どのドメインコントローラーにFSMOの役割があるかを確認する方法



原則として、私たちはすでに理論的な部分を扱ってきましたが、今では実践するのがいいでしょう。組織には1つのドメインしか持てないという事実にもかかわらず、多数のドメインコントローラーをインストールでき、管理者がどのドメインコントローラーに運用マスターの役割が割り当てられているかを常に把握できるとは限りません。たとえば、ドメインを再構築する場合、どのドメインコントローラにこの役割またはその役割が割り当てられているかを調べる必要があります。各役割は、グラフィカルインターフェイスまたはコマンドラインツールを使用して定義できます。両方の方法を検討してください。



GUIツールを使用した操作ウィザードロールの所有者の定義



まず、Active Directoryドメインサービスの操作のウィザードを識別するために、さまざまな管理スナップインが使用されることを覚えておく必要があります。識別するのが最も難しいのは、回路のマスターです。彼から始めましょう。スキーマウィザードの役割を持つドメインコントローラーを確認するには、次の手順を実行します。

  1. 管理者権限を持つアカウントでドメインコントローラーにログオンします。
  2. [ ファイル名を指定して実行 ]ダイアログボックスを開き、regsvr32.exe schmmgmtコマンドを使用してActive Directoryスキーマダイナミックスナップインライブラリを登録します。
  3. 次に、MMC管理コンソールウィンドウを開き、[新しいスナップインの追加]ダイアログを呼び出します。スナップインのリストで、次の図に示すようにActive Directory Schemaを選択します。





    図 1. Active Directoryスキーマスナップインの追加
  4. 開いているActive Directoryスキーマスナップインで、スナップインのルートノードを右クリックし、以下に示すように、コンテキストメニューから[ 操作マスタ]コマンドを選択します。





    図 2.スキーマ操作ウィザード


残りの操作マスターを識別するには、実行するアクションを大幅に減らす必要があります。どのドメインコントローラーがドメイン名前付け操作ウィザードの権限を持っているかを見つけるには、次のものが必要です。

  1. Active Directoryドメインと信頼スナップインを開きます。
  2. « » , :





    図 3.


そして、残りの3つのドメインレベルの役割を識別するには、最小限の作業を行う必要があります。つまり、操作ウィザードの残りの役割はすべて1つのダイアログボックスで確認できます。これを行うには、Active Directoryユーザーとコンピュータースナップインを開き、ドメインを右クリックして、コンテキストメニューから[ 操作マスター ]コマンドを選択します。表示されるダイアログボックスの対応するタブで、現在の役割が割り当てられているドメインコントローラーの名前を表示できます。次の図に、[ 操作ホスト ]ダイアログボックスを示します。



図 4.ドメインレベルの運用ホスト



コマンドラインを使用したオペレーションウィザードロールの所有者の定義



Windowsオペレーティングシステムで提供されるほとんどの機能と同様に、特別なコマンドラインユーティリティを使用して、操作ウィザードの役割の所有者をすべて決定できます。Active Directoryドメインサービスは、Ntdsutilコマンドラインユーティリティを使用して、特定の変更を監視します。このユーティリティを使用して操作ウィザードの役割を備えたすべてのドメインコントローラーを表示するには、次の手順を実行します。

  1. コマンドプロンプトウィンドウを開きます。
  2. Ntdsutilコマンドを実行します。
  3. rolesコマンドを入力して、NTDSロール管理所有者トークンに移動します。
  4. Active Dirctory. connections ;
  5. «server connections» connect to server , «Enter» ;
  6. fsmo management , quit ;
  7. «Select operation target» , , , , ;
  8. , List roles for connected server , :





    図 5.コマンドラインツールを使用した操作マスターの定義


/ test：Knowsofroleholders / vコマンドでDcdiagユーティリティを使用して、FSMOの役割を表示することもできます。このコマンドの出力の一部を以下に見ることができます。





図 6. Dcdiagユーティリティを使用したFSMOロールの定義



操作マスターの役割の取得と転送



Active Directoryには、操作ウィザードの役割の転送とキャプチャ（失効とも呼ばれる）などの概念があります。まず第一に、それが何であり、これらの概念の違いは何かを知る必要があります。

前述のように、最初は、操作マスターの5つの役割すべてがフォレスト内の最初のドメインコントローラーにインストールされます。通常、生産性とフォールトトレランスを向上させるために、同じドメイン内の組織内にいくつかの追加のドメインコントローラーを展開するのが一般的です。したがって、将来の競合を回避するために、操作マスターの役割をすぐに別のドメインコントローラーに配布することをお勧めします。また、操作ウィザードとして機能するドメインコントローラーを無効にするか、使用停止にする必要がある場合は、すべてのFSMOの役割を他のドメインコントローラーに転送する必要があります。

次に、操作マスターの特定の役割を付与されたドメインコントローラーに障害が発生し、時間内にこのDCから役割を転送することができなかった場合、役割のキャプチャが必要です。操作のマスターの役割を持つドメインコントローラーに障害が発生した場合に直面するリスクについては、この記事で少し前に説明しました。この場合、FSMOの役割を好みの役割の転送方法に転送する方法はありません。したがって、ロールを取り消すことで操作トークンをキャプチャするだけで済みます。ただし、役割を奪取することが最も根本的な方法であり、操作のマスターの役割の所有者が失敗した場合にのみ実行する必要があることを覚えておく価値があります。操作ウィザードの役割をキャプチャするプロセスが実行されると、オブジェクトのfsmoRoleOwner属性が既存のコンピューターで変更され、これは、データのルートディレクトリであり、いかなる種類のデータ同期も実行しません。変更が複製されると、他のドメインコントローラーはFSMO役割の新しい所有者について自然に学習します。

運用マスターの役割を転送および取得するプロセスを検討してください。

FSMOの役割を転送するには、次の手順を実行します。

  1. この記事の前のセクションで説明した操作ウィザードの役割を特定できるスナップインを開きます。たとえば、PDCエミュレーターの役割を転送するには、Active Directoryユーザーとコンピュータースナップインを開きます。
  2. 現在のスナップインを使用して、操作ウィザードの役割が転送されるドメインコントローラーに接続します。これは、ルートスナップインノードのコンテキストメニューから呼び出される[ ドメインコントローラーの変更 ]ダイアログボックスを使用して実行できます。ドメインコントローラーの変更ダイアログボックスは次のとおりです。





    図 7.ドメインコントローラーを変更して、操作ウィザードの役割を転送する
  3. [ 操作マスター ]ダイアログボックスを開き、目的のタブに移動して、[ 編集 ]ボタンをクリックします。操作ウィザードの役割は、別のドメインコントローラーに移されます。


操作マスターの役割をキャプチャするプロセスは、転送よりも少し複雑です。これには、前のセクションで説明したNtdsutilユーティリティを使用する必要があるためです。障害が発生したドメインコントローラーから役割を強制するには、次の手順を実行します。

  1. コマンドプロンプトを開き、その中でntdsutilユーティリティに移動します。
  2. rolesコマンドを使用してNTDSロール管理に移動します。
  3. , . connections ;
  4. «server connections» connect to server ;
  5. fsmo management , quit ;
  6. fsmo management seize Enter ;
  7. , , FSMO-, .


注意深い読者は次の質問をするかもしれません：死んだドメインコントローラーが復活した場合、どうすればよいですか？キャプチャされたロールの所有権をこのドメインコントローラーに戻すにはどうすればよいですか？ここではすべてが比較的単純です。まず、PDCエミュレーターまたはインフラストラクチャの役割が取り消された場合、操作ウィザードの役割を復元されたドメインコントローラーに簡単に転送できることを知っておく必要があります。

ただし、スキームのマスター、ドメインの命名、または相対RIDの役割がキャプチャされた場合は、次の手順を実行する必要があります。

  1. そのようなドメインコントローラーをネットワークから物理的に切断します。
  2. Dcpromo / forceremovalコマンドを使用して、ドメインコントローラーをメンバーサーバーに降格します。
  3. . Ntdsutil Metadata Cleanup ;
  4. , , ;
  5. .






このセクションでは、操作ウィザードのすべての役割をドメインコントローラーに配置するための推奨事項について少し説明します。そのため、このような推奨事項はあまり多くないため、できるだけ早くこのセクションを簡素化するようにします。

まず、1つのフォレスト、1つのドメイン、および1つのドメインコントローラーがある場合、操作ウィザードの5つの役割すべてがこのドメインコントローラーに配置されますが、負荷を分散するために、役割を他のドメインコントローラーに転送することをお勧めします。

FSMOの役割を配置するための主な推奨事項は次のとおりです。



これらの3つのルールに従って、最適な方法で運用ウィザードをフォレストに配置できます。



結論の代わりに



この記事は終わりに近づいています。この記事では、オペレーションマスターの役割と、それらが必要な理由について学びました。Active Directoryドメインサービスに操作ウィザードがなく、すべてのドメインコントローラーがピアである場合に何が起こるかを説明するいくつかの例を調べました。5つのFSMOの役割すべてについて詳細に説明し、ドメインコントローラー上の役割を識別する方法について説明しました。また、運用マスターの役割の転送と取得、およびこれらのアクションの実行方法についても学びました。これに加えて、組織内のドメインコントローラーに操作ウィザードを配置するためのオプションを選択する際に従う必要がある3つのルールを理解しました。


More articles:


All Articles