Active Directoryサーバー復旧後のレプリケーション制御ガイド

複数台のActive Directoryサーバーが稼働している環境では、一台のサーバー障害が全体のドメイン運用に大きな影響を及ぼします。特にバックアップからの復旧時には、古いデータと最新データとの整合性をどう確保するかが重要です。本記事では、復旧サーバーと他サーバーとのレプリケーション制御方法を中心に解説します。

Active Directoryサーバーがクラッシュした際の課題

クラッシュしたドメインコントローラー(以下DC)が存在すると、ドメイン全体の認証やディレクトリサービスに遅延や障害が発生する可能性があります。さらに、同一ドメイン内に複数台のDCがあると、それぞれが持つデータの整合性を維持するために「レプリケーション」が行われていますが、古いバックアップから復旧したDCが誤った情報を他のDCに伝搬するリスクが生じます。とくに今回のように10日以上前のバックアップを使用した場合、新規ユーザーアカウントの追加やグループポリシーの変更、パスワードの変更など、大量の差分が生まれている可能性があります。

復旧後のレプリケーション制御の基本方針

復旧したサーバー(以下「復旧サーバー」)をいきなり複数のDCと同期させると、競合や巻き戻りが発生し、最悪の場合はドメイン全体が混乱します。そのため、以下のポイントを押さえて慎重にレプリケーションを制御する必要があります。

  • 復旧サーバーから他のサーバーへのレプリケーション送信を一時停止する
  • 必要に応じて、他のサーバーで受信レプリケーションを停止する
  • 一部のDC(今回はPDC)だけと同期を行い、復旧サーバーのデータを最新化する
  • 最新化された後で、最終的に全サーバーとのレプリケーションを再開する

こうした段階的な手順を踏むことで、ドメイン全体に悪影響を及ぼさずに、復旧サーバーを安全に再参加させることができます。

アウトバウンドレプリケーション停止の具体手順

1. 復旧サーバーのアウトバウンドレプリケーションを停止

まずは復旧サーバーから、古いデータや誤った変更情報が他のDCに伝わらないようにすることが最優先です。
管理者権限のあるアカウントで復旧サーバーにログインし、コマンドプロンプト(またはPowerShell)から以下のコマンドを実行します。

repadmin /options <復旧サーバー名> +DISABLE_OUTBOUND_REPL

+DISABLE_OUTBOUND_REPL は「このDCから他のDCに対する変更送信(アウトバウンドレプリケーション)を停止する」オプションです。これによって誤って古い状態を他のサーバーに送り込む事態を防ぎます。

2. 必要に応じたインバウンドレプリケーションの停止

もし復旧サーバーへの「受信レプリケーション」そのものを制御したい場合、逆に他のサーバー側でインバウンドレプリケーション(受信)を停止します。たとえば特定のDCが復旧サーバーからの変更を受け取らないようにするには、以下のコマンドを対象のDCで実行します。

repadmin /options <対象サーバー名> +DISABLE_INBOUND_REPL

このように受信側を停止することで、レプリケーション方向をさらに厳格に管理できます。ただし多くの場合、まずは復旧サーバー側をアウトバウンドレプリケーション停止にするだけでも十分コントロールが可能です。

PDCだけとのレプリケーションを許可する方法

1. PDCの役割を把握する

Active Directoryには複数のFSMO(Flexible Single Master Operations)ロールが存在しますが、そのうちの1つであるPDC Emulatorは、パスワード変更の即時反映や、旧式のクライアントとの互換性、時刻同期など多岐にわたる重要な役割を担っています。
このPDCを利用して復旧サーバーを最新の状態に同期させることで、最も確実かつ安全に10日分の差分を取り込むことが可能です。

2. Sites and Servicesでトポロジを調整

Active Directoryの管理ツール「Active Directory Sites and Services」を開き、ドメイン内のサイト構成と各サーバー間の接続オブジェクトを確認します。復旧サーバーからPDCへの接続オブジェクトが正しく存在しているかをチェックし、必要に応じて手動で作成または有効化します。

  • 不要な接続の無効化や削除
    他のDCとの接続オブジェクトが自動生成されている場合、現時点では誤同期のリスクがあるため一時的に無効化・削除を検討します。
  • 手動での接続作成
    もし復旧サーバーとPDCの接続がない場合、右クリックの「New Active Directory Domain Services Connection」などで手動作成が可能です。

3. レプリケーション状況の確認と強制同期

コマンドプロンプトから以下のようにして、現在のレプリケーション状況を確認します。

repadmin /showrepl

特にPDCと復旧サーバー間がどういう状態になっているか注目します。必要に応じて、以下のように強制的に同期を行います。

repadmin /syncall <PDCサーバー名> <復旧サーバー名>

これによって、PDCが持つ最新のデータを復旧サーバーへと送信し、10日分の差分を取り込むことができます。なお、この操作を行う前に、復旧サーバーのアウトバウンドレプリケーション停止を行ったままにしておくのが安全です。そうすることで、復旧サーバーから他のサーバーへの誤同期を防ぎながら、PDCからのみのデータ取り込みが可能になります。

レプリケーション再開の手順と注意点

1. 復旧サーバーのデータ整合性確認

PDCから同期を受けた後、復旧サーバー内のActive Directoryオブジェクトが最新化されていることをテストします。例えば下記のポイントを確認してください。

  • ユーザーアカウントやグループが最新状態か
  • パスワード更新情報が正しく適用されているか
  • グループポリシーの状態

Event ViewerのDirectory Serviceログや、dsa.msc(Active Directoryユーザーとコンピュータ)でオブジェクトを確認し、エラーが記録されていないかもチェックします。

2. アウトバウンドレプリケーション再開

復旧サーバーがPDCの情報を正しく反映し、最新状態になったと判断できたら、以下のコマンドでアウトバウンドレプリケーション停止を解除します。

repadmin /options <復旧サーバー名> -DISABLE_OUTBOUND_REPL

これによって、復旧サーバーは他サーバーに対して変更を送信できるようになります。このタイミングで、もし他のサーバー側でインバウンドレプリケーションを停止していた場合は、それぞれのサーバーで -DISABLE_INBOUND_REPL を実行して解除してください。

3. Active Directoryトポロジの自動調整

通常、Active DirectoryはKCC(Knowledge Consistency Checker)と呼ばれる仕組みによって、最適なレプリケーショントポロジを自動で生成・調整します。
しばらく時間を置くと、復旧サーバーが他のDCとも再度接続オブジェクトを確立し、ドメイン全体のレプリケーションが正常化されます。万が一エラーが発生した場合は、Event Viewerや repadmin /showrepl の出力を参照しながら手動で対処してください。

運用管理におけるポイント

1. 定期的なバックアップと復旧テスト

バックアップは取得していても、そのデータが古すぎると今回のように大量の差分が発生します。日次・週次など、運用ポリシーに合わせた頻度でバックアップを行い、定期的にリストアテストやDR(Disaster Recovery)テストを実施することで、いざというときの作業を円滑に行えます。

2. FSMOロールを把握しておく

PDC Emulator以外にも以下のFSMOロールがあります。

FSMOロール主な役割
Schema Masterスキーマ更新の制御
Domain Naming Masterドメイン名やフォレスト構成の変更を制御
Infrastructure Masterドメイン間参照やオブジェクトIDの整合性保持に関与
RID Masterユーザーやグループに付与されるRIDを一意に割り振り
PDC Emulatorパスワード変更の即時複製、時刻同期、旧NT4.0ドメインとの互換機能を提供

特にPDC Emulatorは今回のような復旧シナリオで重要です。どのサーバーがどのFSMOロールを保持しているかを常に把握しておくと、トラブルシュートがスムーズになります。

3. レプリケーションモニタリングの自動化

大規模環境では、手動でrepadminを都度実行するよりも、PowerShellスクリプトや監視ソフトウェアを用いてレプリケーション状況を自動監視することがおすすめです。異常が発生した際にアラートを受け取れるように設定しておけば、今回のようなDCのクラッシュをいち早く把握し、適切な対処につなげられます。

よくある質問とトラブルシュート

Q1: 復旧サーバーとPDCが同期しない場合は?

  • ネットワーク上で名前解決(DNS)が正しく機能しているかチェック
  • Active Directory Sites and Servicesでサイトやサブネット設定が適切に構成されているか確認
  • ファイアウォールやセキュリティソフトで特定ポート(LDAP、RPCなど)がブロックされていないか調査

Q2: 競合オブジェクトが大量に発生したら?

  • 競合オブジェクトは「CN=Conflict And Deleted」という特殊な場所へ移動される場合があります
  • コマンド repadmin /removelingeringobjects を使って、不要なオブジェクトを削除する作業が必要になる場合もある
  • 最悪の場合、メタデータクリーンアップを実施してドメインコントローラー情報を再度整合させる必要がある

Q3: 他のサーバーへの接続オブジェクトを削除しすぎてしまった

  • KCCが自動的に接続を再生成するまで待機するか、手動でConnectionsを作成する
  • あまりにも複雑に削除や変更を加えた場合は、Active Directoryの再構成や徹底した検証が求められる

まとめ

10日以上前のバックアップから復旧する場合、十分な注意を払わないと古い情報がドメイン全体へ波及し、ユーザー管理やグループポリシーが混乱してしまうリスクがあります。そこで、まずは復旧サーバーのアウトバウンドレプリケーションを停止したうえで、PDCなど一部の重要なDCとのみレプリケーションを行い、新しい情報を安全に取り込むことが重要です。
最終的にはすべてのDC間レプリケーションを正常に戻す必要がありますが、段階的に制御を行うことでトラブルを最小化できます。加えて、定期的なバックアップやレプリケーション監視の仕組みを整備しておくことで、将来の障害時にも迅速な復旧が可能になるでしょう。

コメント

コメントする