Hyper-V によるドメイン コントローラーの仮想化

Windows Server 2012以降では、仮想Dcでの更新シーケンス番号 (USN) のロールバックを防止するためのセーフガードと、仮想Dcを複製する機能を備えた仮想化ドメインコントローラー (Dc) がサポートされています。 仮想化は、異なるサーバーの役割を単一の物理マシンに統合します。 詳細については、「Active Directory Domain Services (AD DS) の安全な仮想化」を参照してください。

このガイドでは、Dcを32ビットまたは64ビットのゲストオペレーティングシステムとして実行する方法について説明します。

仮想化の計画

以下のセクションでは、ハードウェア要件、アーキテクチャ、構成、セキュリティとパフォーマンスの管理など、DCを仮想化するときに知っておく必要がある計画上の考慮事項について説明します。

Hyper-V の要件

Hyper-Vの役割をインストールして使用するには、ハードウェアが次の要件を満たしている必要があります。

• x64プロセッサが必要です。

• プロセッサでは、ハードウェア支援仮想化機能を有効にする必要があります。

  • 通常、この設定はIntel Virtualization Technology (Intel VT) またはAdvanced Micro Devices Virtualization (AMD-V) と呼ばれています。

• プロセッサでは、ハードウェアデータ実行保護 (DEP) がサポートされている必要があります。

  • Intel execute disable (XD) ビットまたはAMD no execute (NX) ビットを有効にしている場合にのみ、Hyper-vを使用できます。

単一障害点の回避

仮想DCの展開を計画するときは、単一障害点の作成を回避するための戦略を準備する必要があります。 システムの冗長性を実装することで、潜在的な単一障害点の導入、またはダウンタイムによってシステム全体の動作が停止する可能性がある領域を回避できます。

次の推奨事項は、単一障害点の防止に役立ちます。 ただし、これらの推奨事項に従うと管理コストが増加する可能性があることに注意することも重要です。

• ドメインごとに少なくとも 2 つの仮想化 DC を、異なる仮想化ホスト上で実行します。 この構成により、仮想化ホストが動作を停止した場合に、すべてのDCが失われるリスクが軽減されます。

• DCを実行するハードウェアを多様化します。 たとえば、異なるCPU、マザーボード、ネットワークアダプターなどを使用します。 ハードウェアを多様化することで、デバイスやハードウェアの誤動作やベンダーの構成による損害を防ぐことができます。

• 可能であれば、異なるリージョンにあるハードウェアでDCを実行します。 この方法により、Dcをホストしているサイトの1つに影響する災害の影響を軽減できます。

• すべてのドメインに物理DCを追加します。 物理DCを持つようにシステムを構成すると、ホストシステムで仮想化プラットフォームの誤動作が発生するのを防ぐことができます。

セキュリティに関する考慮事項

コンピューターがドメインに参加しているコンピューターまたはワークグループコンピューターである場合でも、仮想DCを実行するホストコンピューターは、書き込み可能なDCと同様に慎重に管理する必要があります。 この要件は、セキュリティ上の理由からです。 不適切に管理されたホストは、特権の昇格攻撃に対して脆弱です。この攻撃では、管理者が下位レベルの役割の割り当てに不適切なレベルのアクセス許可を割り当てたために、悪意のあるユーザーが必要以上に高い特権にアクセスできるようになります。 これらの攻撃は、影響を受けるコンピューターによってホストされているすべての仮想マシン (Vm) 、ドメイン、およびフォレストを侵害する可能性があります。

DCの仮想化を計画する場合は、次のセキュリティ上の考慮事項に注意してください。

• 仮想書き込み可能Dcをホストするコンピューターのローカル管理者の資格情報は、それらのDcが属するすべてのドメインとフォレストの既定のドメイン管理者と同じように扱う必要があります。

• Hyper-v以外のアプリケーションを使用せずに、Windows ServerのServer Coreインストールを実行しているホストを使用するようにシステムを構成することをお勧めします。 この構成では、サーバーにインストールするアプリケーションとサーバーの数が制限されます。 この制限により、システムのパフォーマンスが向上し、アプリケーションやサービスを介した悪意のある攻撃のエントリポイントが少なくなるため、攻撃対象領域が減少します。

• ブランチオフィスなどのセキュリティ保護が困難な場所では、読み取り専用Dc (Rodc) を使用することをお勧めします。 別の管理ネットワークがある場合は、ホストを管理ネットワークにのみ接続することをお勧めします。 Rodcの詳細については、 「Windows Server Active Directory読み取り専用ドメインコントローラー (RODC) をインストールする (レベル200) 」 を参照してください。

• BitLockerを使用してDcをセキュリティで保護できます。 Windows Server 2016以降では、システムボリュームのロックを解除するために必要なゲストキーマテリアルを提供する仮想トラステッドプラットフォームモジュール (TPM) 機能を使用することもできます。

• 保護されたファブリックとシールドされた VM では、DC を保護するための他のコントロールを提供できます。

DC のセキュリティ保護の詳細については、Active Directory インストール環境のセキュリティ保護に関するベスト プラクティス ガイドを参照してください。

ホストとゲスト構成のセキュリティ境界

仮想マシン (Vm) は、さまざまな種類のDC構成に実装できます。 そのため、これらのVmがActive Directoryトポロジの境界と信頼にどのように影響するかを慎重に検討する必要があります。 次の一覧では、Hyper-vサーバー上のActive Directory Dcとホスト、およびHyper-vサーバーで実行されているVmであるゲストコンピューターに対して設定できる2つの構成について説明します。

• DCであるゲストを持つワークグループまたはメンバーコンピューターであるホスト。
• ワークグループまたはメンバーコンピューターであるホストと、ワークグループまたはメンバーコンピューターでもあるゲスト。

次の図は、Hyper-vサーバーでホストされている3つのゲストDC Vmの構成を示しています。

前の図の構成例に基づいて、このような展開を計画するときに考慮する必要がある重要な考慮事項を次に示します。

• 管理者アクセス

  • ホストコンピューターの管理者の資格情報は、書き込み可能なDCのドメイン管理者の資格情報と同じように扱う必要があります。 RODCゲストの場合、ホストコンピューターの管理者の資格情報は、ゲストRODCのローカル管理者の資格情報と同じように扱う必要があります。

• ホストコンピューターのDC管理者権限

  • ホストを同じドメインに参加させる場合、仮想化DCの管理者はホストの管理者権限を持ちます。 ただし、このアクセス特権は、悪意のあるユーザーがVM 1にアクセスできる場合に、すべてのVMを侵害する機会を与える可能性もあります。 このシナリオでは、攻撃ベクトルが作成される可能性があります。 この攻撃ベクトルを防ぐには、複数のドメインまたはフォレストに対して構成されたすべてのDCに、すべてのドメインによって信頼されている一元管理ドメインがあることを確認し、仮想化ホストを高い特権を持つ管理ドメインのメンバーにします。 この方法により、個々のドメイン管理者がホストを制御できなくなり、他のドメインも制御できなくなります。

• 攻撃の回避

  • 悪意のあるユーザーは、VM 1をRODCとしてインストールした場合でも、VM 1を攻撃できます。 RODC管理者は明示的にドメイン管理者権限を持っていませんが、RODCを使用してホストコンピューターにポリシーを適用することができます。 これらのポリシーには、たとえば、スタートアップスクリプトが含まれている場合があります。 悪意のあるアクターがRODC管理者権限を取得する方法を見つけて、悪意のあるスタートアップスクリプトを含むポリシーを送信すると、ホストコンピューターが侵害され、それを使用してホスト上の他のVMが侵害される可能性があります。

• 仮想ハードディスク (VHD) ファイルのセキュリティ

  • 仮想DCのVHDファイルは、物理DCの物理ハードドライブに似ています。 VHDファイルのセキュリティは、ハードドライブの場合と同様に慎重に保護する必要があります。 信頼できる信頼された管理者のみがこれらのVHDファイルにアクセスできるようにしてください。

• RODC

  • RDCは、ブランチオフィスなど、物理的なセキュリティが保証されていない場所に配置できます。 Windows BitLockerドライブ暗号化を使用して、物理ディスクの盗難を伴うホストへの攻撃からVHDファイルを保護することができます。 ただし、これらの保護はRODC内のファイルシステムには適用されません。

パフォーマンスに関する考慮事項

Microkernel 64ビットアーキテクチャは、以前の仮想化プラットフォームよりもHyper-Vのパフォーマンスが優れています。

VMのパフォーマンスは、使用するワークロードによって異なります。 特定のVMトポロジをテストして、Active Directory展開のパフォーマンスに満足していることを確認することをお勧めします。 信頼性とパフォーマンスモニター (Perfmon.msc) やMicrosoft Assessment and Planning (MAP) ツールキットなどのツールを使用して、特定の期間にわたってワークロードのパフォーマンスを評価できます。 MAPツールは、現在ネットワーク内にあるすべてのサーバーとサーバーの役割のインベントリを作成するのにも役立ちます。

仮想化DCのパフォーマンスのテストがどのように機能するかを理解するために、Active Directoryパフォーマンステストツール (ADTest.exe) を使用してパフォーマンステストの例を作成しました。

ADTest.exeを使用して、物理DCでライトウェイトディレクトリアクセスプロトコル (LDAP) テストを実行しました。 同じテストを、物理DCと同じサーバーでホストされているVMで構成される仮想DCで実行しました。 このサンプルビルドでは、物理コンピューターに対して1つの論理プロセッサのみを使用し、VMに対して1つの仮想プロセッサのみを使用しました。 この構成により、展開で簡単に100%のCPU使用率に達することができます。

次の表に、物理DCと仮想DCのテスト結果を示します。 テスト名の横にあるかっこ内の文字と数字は、ADTest.exeのラベルです。 このデータは、仮想DCのパフォーマンスが物理DCのパフォーマンスの88から98%の間であったことを示しています。

テストデプロイのパフォーマンスを最大化するために、このテストビルドに統合コンポーネント (IC) をインストールして、ゲストOSがハイパーバイザー対応の統合ドライバーを使用できるようにしました。 ICをインストールする場合は、エミュレートされたIntegrated Drive Electronics (IDE) またはネットワークアダプタードライバーの使用が必要になることがあります。 運用環境では、エミュレートされたこれらのドライバーを合成ドライバーに置き換えてパフォーマンスを向上させる必要があります。

このテストに基づいて、パフォーマンスを向上させるための次の推奨事項を検討してください。

• Perfmon.mscツールを使用してVMのパフォーマンスを監視する場合、VMのCPU情報が完全に正確ではないことがあります。 この不正確さは、仮想CPUが物理プロセッサで実行されるようにスケジュールされていることが原因です。 Hyper-vサーバーで実行されているVMのより正確なCPU情報については、代わりにホストパーティションのHyper-vハイパーバイザー論理プロセッサカウンターを使用してください。 AD DS と Hyper-V の両方のパフォーマンス チューニングの詳細については、Windows Server のパフォーマンス チューニング ガイドラインに関する記事を参照してください。

• 差分ディスクVHDを使用するとパフォーマンスが低下する可能性があるため、DCとして構成されたVMで差分ディスクVHDを使用しないことをお勧めします。 差分ディスクを含む Hyper-V ディスクの種類の詳細については、仮想ハード ディスクの新規作成ウィザードに関する記事を参照してください。

• また、 「仮想ホスティング環境でActive Directory DCをホストするときの考慮事項」 を参照して、仮想ホスティング環境でAD DSを使用する方法について理解しておくことをお勧めします。

デプロイに関する考慮事項

以下のセクションでは、DC を展開するときに回避すべき一般的な VM プラクティスと、時刻同期とストレージに関する特別な考慮事項について説明します。

デプロイメントに関する推奨事項

Hyper-vなどの仮想化プラットフォームには、コンピューターの管理、保守、バックアップ、および移行を容易にする多くの機能があります。 ただし、仮想DCでこれらの機能を利用するために従う必要がある特定の推奨事項があります。

• Active Directory の書き込みが永続的であることを確認するには、NTDS.DIT Active Directory データベース、ログ、SYSVOL などの仮想 DC データベース ファイルを仮想 IDE ディスクに展開しないでください。 代わりに、仮想スモールコンピューターシステムインターフェイス (SCSI) コントローラーに接続されている2番目の仮想ハードディスク (VHD) を作成し、DCをインストールするときにデータベースファイルがVM SCSIディスクにあることを確認します。

• DCとして構成しているVMに差分ディスクVHDを実装しないでください。 この方法では、デプロイを以前のバージョンに簡単に戻すことができますが、パフォーマンスも低下します。 VHD の種類の詳細については、仮想ハード ディスクの新規作成ウィザードに関する記事を参照してください。

• 最初にシステム準備ツール (sysprep) を使用してデプロイの準備をしないで、Windows Server OSのコピーにActive Directoryドメインとフォレストをデプロイしないでください。 Sysprep の実行の詳細については、「Sysprep (システム準備) の概要」を参照してください。

  警告

  昇格されたDCでSysprepを実行することはお勧めしません。ADデータベースと関連コンポーネントに悪影響を及ぼし、次の問題が発生する可能性があるためです。

  • データ損失
  • ADデータベースの破損
  • 安定性と機能の問題
  • アプリケーション、サービス、およびドライバーの問題

• 展開したDCからVHDファイルのコピーを使用して他のDCを展開しないでください。 コピーを使用しないと、潜在的なUSNロールバックシナリオを防ぐことができます。 USN ロールバックの詳細については、USN および USN ロールバックを参照してください。

  • Windows Server 2012以降では、管理者はDCイメージを複製してより多くのDCを展開できますが、適切に準備されたイメージを使用する場合に限られます。

• DCを実行しているVMをエクスポートする場合は、Hyper-vエクスポート機能を使用しないでください。

  • Windows Server 2012以降では、DC仮想ゲストのエクスポートとインポートは、権限のない復元と同様にシステムによって処理されます。 このプロセスでは、生成IDが変更されたかどうか、およびDCが複製用に構成されていないかどうかが検出されます。

  • ゲストVMをエクスポートするときは、だれも使用していないことを確認する必要があります。 作業を簡単にするために、Hyper-Vレプリケーションを使用してDCの非アクティブなコピーを作成できます。 レプリケートされたイメージの使用を開始するときは、DCゲストイメージをエクスポートした後にソースイメージの場合と同様にクリーンアップを実行する必要もあります。

物理から仮想への変換

System Center VM Manager (VMM) を使用すると、物理マシンとVMを統一された方法で管理できます。 VMMを使用して物理マシンをVMに移行することもできます。 この移行プロセスは、物理からVMへの変換、またはP2V変換と呼ばれます。 P2V変換プロセスを開始するには、移行するVMと物理DCが同時に実行されていないことを確認する必要があります。 2 台のマシンが同時に実行されていないことを確認すると、USN および USN ロールバックで説明されているように、USN ロールバックのシナリオを回避できます。

DCを再びオンにしたときにディレクトリデータの一貫性を維持するには、オフラインモードでP2V変換を実行する必要があります。 オフラインモードは、物理サーバーの変換インストーラーで切り替えることができます。 オフラインモードの使用方法の詳細については、 「P2V: VMMで物理コンピューターをVMに変換する」 を参照してください。

変換プロセスが完了し、すべてが動作することを確認した後にのみ、ネットワークアダプターを有効にする必要があります。 その時点で、物理ソースマシンをオフにする必要があります。物理ソースマシンを再びオンにして、ハードディスクを再フォーマットするまでネットワークに再接続しないでください。USNロールバックの回避。 仮想Dcを作成する場合は、USNロールバックシナリオを作成しないようにする必要があります。 この時点で、物理ソースコンピューターをオフにする必要があります。物理ソースコンピューターをオンにして、ハードディスクを再フォーマットするまでネットワークに再接続しないでください。

USNロールバックの回避

仮想Dcを作成する場合は、USNロールバックシナリオを作成しないようにする必要があります。 ロールバックを回避するには、通常の昇格、メディアからのインストール (IfM) からの昇格、または既に1つ以上の仮想DCがある場合はDCを複製することによって、新しい仮想DCを設定できます。 この方法では、P2Vに変換された仮想ゲストで発生する可能性のあるハードウェアまたはプラットフォームの問題を回避することもできます。

テスト環境と P2V 移行

P2V移行をVMMと組み合わせて使用して、テスト環境を作成できます。 この方法では、実稼働DCを完全に停止することなく、実稼働DCを物理マシンからVMに移行してテスト環境を作成できます。 ただし、同じDCの2つのインスタンスが存在できるように、実稼働環境とは別のネットワーク上にテスト環境を構築する必要があります。 P2V移行を使用してテスト環境を作成する場合は、USNロールバックを回避することが重要です。

テスト環境の作成

P2Vを使用してテスト環境を作成する場合は、次の操作を行うことをお勧めします。

• 物理から仮想への変換に関する推奨事項に基づいて、P2Vを使用して各ドメインから1つの運用中DCをテストVMに移行します。

• 物理運用マシンとテストVMは、オンラインに戻すときに別のネットワークに配置します。

• テスト環境でUSNロールバックを回避するには、ネットワークから移行する予定のすべてのDCを切断します。 Dcを切断するには、NTDSサービスを停止するか、ディレクトリサービス復元モード (DSRM) でマシンを再起動します。

• ネットワークからDcを切断した後は、環境に新しい更新プログラムを導入しないでください。

• P2V移行中は、どのマシンもネットワークに接続しないでください。 再接続できるのは、すべてのマシンの移行が完了した後だけです。

• テスト環境では、P2V変換後に作成したテストDCのみをレプリカとして昇格させる必要があります。

タイム サービスと同期

DCとして構成したVMについては、ホストシステムとDCとして機能しているゲストOSとの間の時刻同期を無効にすることをお勧めします。 ゲストDCがホストシステムと同期しない場合は、代わりにドメイン階層と同期します。

Hyper-V 時刻同期プロバイダーを無効にするには、VM をオフにしてから VM の設定に移動し、統合サービスを選択して、 時刻同期チェックボックスをオフにします。

ストレージと最適化

DC VMのパフォーマンスを最適化し、Active Directoryの書き込みの持続性を確保するために、このセクションの記憶域に関する推奨事項に従うことをお勧めします。

• ゲスト ストレージの場合は、Active Directoryデータベース ファイル (Ntds.dit) とログ ファイルおよび SYSVOL ファイルを、OS ファイルとは別の仮想ディスクに格納します。 これらのファイルは、仮想SCSIコントローラーに接続されている2番目のVHDの仮想SCSIディスクに格納することをお勧めします。 仮想SCSIディスクは、パフォーマンスを向上させ、強制ユニットアクセス (FUA) をサポートします。 FUAを使用すると、OSはキャッシュメカニズムをバイパスして、メディアから直接書き込みと読み取りを行います。

• BitLockerを使用して仮想DCゲストをセキュリティで保護している場合は、Enable-BitLockerAutoUnlock PowerShellコマンドレットを使用して、自動ロック解除用の追加ボリュームを構成します。

• VHDファイルをホストに格納する場合は、ホストOSのシステムディスクなど、他のサービスやアプリケーションによって頻繁に使用されないディスクを使用する必要があります。 各VHDファイルは、ホストOSや他のVHDファイルとは別のパーティション (できれば別の物理ドライブ) に格納します。

• ホストの物理ディスクシステムは、仮想化されたワークロードのデータ整合性要件を満たすために、次の条件の少なくとも1つを満たしている必要があります。

  • ホストは、SCSIやファイバーチャネルなどのサーバークラスのディスクを使用します。

  • ホストは、ディスクがバッテリバックアップ式キャッシュHBAに接続されていることを確認します。

  • ホストは、ストレージデバイスとして、Redundant Array of Independent Disks (RAID) システムなどの記憶域コントローラーを使用します。

  • ホストは、無停電電源装置 (UPS) を使用してディスクに電力を供給します。

  • ホストは、ディスクの書き込みキャッシュ機能を既定で無効にします。

• VHDファイルを使用する場合は、パフォーマンスが最適化されているため、パススルーディスクまたは固定サイズのVHDを使用することをお勧めします。 ディスクを動的に拡張したり差分を取ったりすることはお勧めしません。これは、遅延が発生したり、ディスクアクティビティが多いときにパフォーマンスが低下したり、以前のスナップショットにロールバックしたときにデータが失われる可能性があるためです。

• Active Directoryデータが破損する可能性を減らすために、仮想SCSIコントローラーを使用することをお勧めします。

  • 仮想DCをホストするHyper-vサーバーでは、SCSI物理ドライブを使用する必要があります。 シナリオでSCSIドライブを使用できない場合は、代わりに使用しているAdvanced Technology Attachment (ATA) またはIntegrated Drive Electronics (IDE) ドライブの書き込みキャッシュを無効にする必要があります。 詳細については、「イベント ID 1539 – データベースの整合性」を参照してください。

VMドメインコントローラーの操作上の制限

仮想マシンで稼働しているドメイン コントローラーには、物理マシンで稼働している DC には適用されない運用上の制限があります。 仮想化DCを使用する場合は、次のガイドラインに従う必要があります。

• フォレストの廃棄 (tombstone) の有効期間よりも長い期間、VM内のDCの保存された状態を一時停止、停止、または保存しないでください。 廃棄 (tombstone) の有効期間よりも長い期間、一時停止または保存した保存された状態を再開すると、レプリケーションが妨げられる可能性があります。 フォレストの廃棄標識の有効期間を決定する方法については、「フォレストの廃棄標識の有効期間の決定」を参照してください。

• VHDをコピーまたは複製しないでください。

• 仮想DCのスナップショットを作成または使用しないでください。 代わりに、より永続的で信頼性の高いバックアップ方法を使用する必要があります。

• DC が稼働している VM でエクスポート機能を使用しないでください。

• サポートされていないバックアップ方法を使用して、DCまたはActive Directoryデータベースの内容を復元またはロールバックしないでください。

バックアップと復元の考慮事項

障害シナリオや管理エラーによるデータ損失を防ぐために、DCをバックアップする必要があります。 Active Directoryでサポートされているバックアップ方法では、バックアップアプリケーションを使用して、DCの現在のインストールから作成されたシステム状態のバックアップを復元します。 アプリケーションは、Windows Serverバックアップなど、Active Directoryと互換性のあるものである必要があります。 サポートされているバックアップ方法の詳細については、 「AD DSのバックアップと回復のステップバイステップガイド」 を参照してください。

仮想化された展開では、Active Directoryのバックアップ操作に関する特定の要件に特に注意する必要があります。 たとえば、VHDファイルのコピーを使用してDCを復元し、復元後にDCのデータベースバージョンを更新しない場合、DCレプリカ間の追跡番号が不正確であるため、レプリケーションで問題が発生する可能性があります。 ほとんどの場合、レプリケーションではこの問題は検出されず、エラーは報告されませんが、特定のシナリオでは、DC間の不整合によって問題が発生する可能性があります。

仮想化DCのバックアップと復元に推奨される方法

仮想化DCのバックアップと復元に使用することをお勧めする方法は、ゲストOSでWindows Serverバックアップを実行することです。 詳細については、 「仮想ドメインコントローラーを復元する」 を参照してください。

技術的には、VHDファイルのスナップショットまたはコピーを使用してバックアップを復元できますが、次の理由から、これらの方法を使用することはお勧めしません。

• VHDファイルをコピーまたは複製すると、復元時にデータベースのバージョン番号が自動的に更新されないため、データベースが古くなります。 この追跡番号の不整合は、VHDを通常モードで起動すると、USNロールバックが発生する可能性があることを意味します。

• Windows Server 2016以降はスナップショットと互換性がありますが、スナップショットは、障害シナリオでシステムを一貫して復元するために必要な、安定した永続的なバックアップ履歴の種類を提供しません。 Windows Server 2016 Hyper-v以降で作成できるボリュームシャドウコピーサービス (VSS) ベースのスナップショットは、潜在的なセキュリティの問題を引き起こす可能性があるBitLockerとも互換性がありません。 この問題により、Hyper-vがスナップショットボリュームをマウントしようとしたときに、Active Directoryデータベースエンジンがスナップショットを含むデータベースにアクセスできなくなります。

USN および USN ロールバック

このセクションでは、古いバージョンの VM を使用して Active Directory データベースを正しく復元できなかった結果として発生する可能性があるレプリケーションの問題について説明します。 Active Directory レプリケーション プロセスの詳細については、「Active Directory レプリケーションの概念」を参照してください。

AD DS と DC で USN を使用する方法

AD DS では、USN を使用して DC 間のデータレプリケーションを追跡します。 ディレクトリ内のデータを変更するたびに、USNは新しい変更を示すために増加します。

宛先DCは、USNを使用して、格納されている各ディレクトリパーティションの更新を追跡します。 また、USNは、これらのディレクトリパーティションのレプリカを格納するすべてのDCの状態を追跡します。 DCは、変更を相互にレプリケートするときに、DCがパートナーから受信した最後の変更よりも大きいUSNを持つ変更をレプリケーションパートナーに照会します。

USNを含むレプリケーションメタデータテーブルは、最新の状態ベクトルと高基準点で見つけることができます。 ソースと宛先の両方のDcは、これらのテーブルを使用して、宛先DCに必要な更新プログラムをフィルター処理します。

宛先DCは、すべてのソースDcから受信した元の更新プログラムを追跡するために、最新のベクターテーブルを保持します。 宛先 DC がディレクトリ パーティションの変更を要求すると、ソース DC に最新性ベクターを提供します。 次に、ソース DC はこの値を使用して、宛先 DC に送信する更新プログラムをフィルター処理します。 ソースDCは、レプリケーションサイクルが正常に完了した後、最新のベクターを宛先DCに送信します。 ソースDCは、USNを使用して、宛先DCがすべてのDCで元の更新と同期されているかどうか、および宛先への更新がソースと同じレベルであるかどうかを追跡します。

宛先DCは、特定のパーティションの特定のソースDCから受信した最新の変更を追跡するために、最高基準点テーブルを保持します。 最高基準点テーブルにより、ソースDCは、宛先DCが既に受信した変更を送信できなくなります。

ディレクトリ データベース ID

DC では、USN に加えて、ソース レプリケーション パートナーのディレクトリ データベースを追跡します。 システムは、サーバオブジェクト自体のIDとは別に、サーバで実行されているディレクトリデータベースのIDを保持します。 各 DC のディレクトリ データベース ID は、LDAP (Lightweight Directory Access Protocol) パス invocationID の下にある NTDS Settings オブジェクトの cn=NTDS Settings, cn=ServerName, cn=Servers, cn=*SiteName*, cn=Sites, cn=Configuration, dc=*ForestRootDomain* 属性に保存されます。

システムは、サーバオブジェクトのIDをオブジェクトobjectGUIDの属性NTDS Settingsに格納します。 サーバー オブジェクトの ID が変更されることはありません。 ただし、次の状況では、ディレクトリデータベースのIDが変更されます。

• サーバでシステム状態の復元手順が発生した場合。

• アプリケーションディレクトリパーティションをサーバに追加してから削除し、再度追加した場合。

• Hyper-Vインスタンスが、仮想DCのVHDを含むパーティションでVSSライターをトリガーした場合。

  このシナリオでは、ゲストによって独自の VSS ライターがトリガーされます。 このアクションは、バックアップと復元のプロセスで使用されるメカニズムと同じです。 このメソッドは、invocationID属性をリセットします。

invocationID属性は、DC上の一連の元の更新を特定のバージョンのディレクトリデータベースに関連付けます。 最新の状態ベクターと高水位標テーブルは、DC GUIDとinvocationIDそれぞれを使用するため、DCはレプリケーション情報の送信元であるActive Directoryデータベースのコピーを認識します。

invocationID属性は、repadmin /showreplコマンドの実行後に出力の上部付近に表示されるグローバル一意識別子 (GUID) の値です。 次のテキストは、コマンドからの出力例を示しています。

Repadmin: running command /showrepl against full DC local host
Default-First-Site-Name\VDC1
DSA Options: IS_GC
DSA object GUID: 966651f3-a544-461f-9f2c-c30c91d17818
DSA invocationID: b0d9208b-8eb6-4205-863d-d50801b325a9

DCでAD DSを復元すると、invocationID属性がリセットされます。 この変更により、レプリケートするパーティションのサイズに比例した期間で、レプリケーショントラフィックが増加します。

このシナリオを示すために、次の図は、仮想ドメインコントローラーVDC1とドメインコントローラーDC2が同じドメイン内の2つのDCである環境の例を示しています。 この図は、サポートされている復元シナリオでのリセット後に、DC2がVDC1のinvocationID値を検出する方法を示しています。

USN ロールバック

USNロールバックは、システムがUSNを通常どおりに更新できない場合、ユーザーがUSN更新を回避した場合、またはDCが最新の更新よりも低いUSNを使用しようとした場合に発生します。 システムがUSNロールバックを検出すると、不一致によってフォレスト内で相違が発生する前にレプリケーションを停止します。

USNロールバックは、多くの要因によって発生する可能性があります。 たとえば、古いVHDファイルを使用したり、変換後に物理マシンを完全に切断せずにP2V変換を実行したりした場合に発生する可能性があります。

USNロールバックの防止

USNロールバックを防止するには、次の予防措置を講じます。

• Windows Server 2012 以降が稼働していない場合は、DC VM のスナップショットを取得したり使用したりしないでください。

• DC VHD ファイルをコピーしないでください。

• Windows Server 2012以降を実行していない場合は、DCを実行しているVMをエクスポートしないでください。

• Windows Serverバックアップなど、サポートされているファーストパーティのバックアップソリューションを使用して、DCのみを復元するか、Active Directoryデータベースの内容をロールバックします。

レプリケーションエラーが発生する前に、システムがUSNロールバックを検出できない場合があります。 レプリケーションエラーが発生した場合は、問題の範囲を特定し、できるだけ早く対処する必要があります。 USNロールバックの結果として発生する可能性がある残留オブジェクトを削除する方法の詳細については、 「Active DirectoryレプリケーションイベントID 1388または1988:残留オブジェクトが検出されました。残留オブジェクトが検出されました。」を参照ください。

USN ロールバックの検出

ほとんどの場合、システムは、invocationID属性をリセットせずにDCを復元することによって発生する属性の不整合を追跡することによって、USNロールバックを検出できます。 Windows Server 2008は、サポートされていないDC復元操作後のレプリケーションエラーに対する保護を提供します。 これらの保護は、サポートされていない復元によって元のバージョンよりも低いUSNが作成されたときにトリガーされます。これは、レプリケーションパートナーが既に受信した変更を表します。

Windows Serverでは、宛先DCが以前に使用されていたUSNを使用して変更を要求すると、宛先DCはレプリケーションパートナーの応答を解釈して、レプリケーションメタデータが古いことを意味します。 メタデータが古いということは、ソースDC上のActive Directoryデータベースが以前の状態にロールバックされたことを意味するため、システムはそれに応じて応答します。

たとえば、VMのVHDファイルが以前のバージョンにロールバックされたとします。 この場合、宛先DCは、サポートされていない復元が行われたと識別されたDCに対して、次の検疫措置を開始します。

• AD DS は Net Logon サービスを一時停止します。これにより、ユーザーおよびコンピューター アカウントでアカウントのパスワードを変更できなくなります。 この操作により、不適切な復元後に変更が発生した場合に、その変更が失われるのを防ぐことができます。

• AD DS は、受信および送信の Active Directory レプリケーションを無効にします。

• AD DSは、発生したことを記録するために、ディレクトリサービスイベントログにイベントID 2095を生成します。

次の図は、AD DSがVDC2 (VMで実行されている宛先DC) でUSNロールバックを検出したときに発生するイベントのシーケンスを示しています。 この図では、レプリケーションパートナーが、以前に宛先DCによって確認された最新のUSN値をVDC2が送信したことを検出したときに、VDC2でUSNロールバックの検出が行われます。 この状態は、VDC2データベースでロールバックが発生したことを示します。

イベント ID 2095 の問題を解決する

ディレクトリサービスイベントログにイベントID 2095が表示された場合は、すぐに次の手順を実行します。

1. エラーを記録した VM をネットワークから分離します。

2. 報告された変更がこのDCから発生し、他のDcに反映されているかどうかを確認します。 VMのスナップショットまたはコピーを使用した結果としてイベントが発生した場合は、USNロールバックがいつ発生したかを確認してください。 時間ができたら、そのDCのレプリケーションパートナーを確認して、ロールバック後にレプリケーションが発生したかどうかを確認できます。

   Repadminツールを使用して、変更の発生元を確認できます。 Repadmin の使用方法の詳細については、Repadmin を使用した Active Directory レプリケーションの監視とトラブルシューティングに関する記事を参照してください。 判別できない場合は、Microsoft サポートにお問い合わせください。

3. DC を強制的に降格させます。 この操作には、DCのメタデータのクリーンアップと、操作マスターの役割 (柔軟な単一マスター操作 (FSMO) の役割とも呼ばれます) の強制が含まれます。 詳細については、 「USNロールバック空の復帰」 を参照してください。

4. DC の以前の VHD ファイルをすべて削除します。

検出されない USN ロールバック

次のシナリオでは、DCがUSNロールバックを検出しない場合があります。

• 複数の場所で同時に稼働している別の VM に VHD ファイルが接続されている。

• 復元されたDCのUSNが、他のDCによって受信された最後のUSNを超えて増加しました。

VHDファイルのシナリオでは、他のDcがいずれかのVMでレプリケートされる可能性があり、変更はもう一方のVMにレプリケートされずにいずれかのVMで発生する可能性があります。 フォレストのこのような分岐を検出することは困難で、予期しないディレクトリの応答が発生します。 この状況は、物理 DC と VM の両方が同じネットワーク上で稼働している場合に、P2V 移行後に発生する可能性があります。 この状況は、複数の仮想 DC が同じ物理 DC から作成され、同じネットワーク上で稼働している場合にも発生する可能性があります。

USNシナリオでは、一連のUSNが2つの異なる変更セットに適用されます。 このシナリオは、検出されずに長期間続く可能性があります。 この期間中に作成したオブジェクトを変更すると、システムは残留オブジェクトを検出し、イベントビューアーでイベントID 1988として報告します。 次の図は、このシナリオでDCがUSNロールバックを検出しない可能性がある理由を示しています。

読み取り専用 DC

読み取り専用ドメインコントローラー (RODC) は、Active Directoryデータベース内のパーティションの読み取り専用コピーをホストするDCです。 RODC では、他の DC に変更をレプリケートしないため、ほとんどの USN ロールバックの問題が回避されます。 ただし、USNロールバックの影響を受ける書き込み可能なDCからRODCがレプリケートされた場合、ロールバックはRODCにも影響します。

スナップショットを使用してRODCを復元することはお勧めしません。 Active Directoryと互換性のあるバックアップアプリケーションを使用してのみ、RODCを復元する必要があります。 また、書き込み可能なDCと同様に、廃棄 (tombstone) の有効期間を超えてRODCをオフラインにしないようにする必要があります。 この状態になると、RODC で残留オブジェクトが発生する可能性があります。

RODC の実装の詳細については、「読み取り専用ドメイン コントローラーのステップ バイ ステップ ガイド」を参照してください。

追加のコンテンツ

仮想化DCを復元する方法については、 「仮想化ドメインコントローラーを復元する」 を参照してください。