複数台の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間レプリケーションを正常に戻す必要がありますが、段階的に制御を行うことでトラブルを最小化できます。加えて、定期的なバックアップやレプリケーション監視の仕組みを整備しておくことで、将来の障害時にも迅速な復旧が可能になるでしょう。
コメント