残留オブジェクトを安全に掃除する基本は、古い DC をいきなり再同期させず、正しい参照 DC を決めて dry-run から入ることです。Active Directory の残留オブジェクトは、削除済みのはずのオブジェクトが長期の複製停止後に残り続けたり再登場したりする状態で、Strict Replication Consistency が無効だと再導入されることがあります。安全に進めるなら、tombstone lifetime とレプリケーション停止期間を確認し、repadmin /removelingeringobjects を /advisory_mode で実行してから本削除に進みます。(Microsoft Learn)
この記事では、残留オブジェクトの見分け方、掃除前の前提条件、実際の repadmin 手順、やってはいけない操作、戻し方と代替策までを、現場でそのまま使える順序で整理します。特に Event ID 1388 / 1988 / 2042 / 8614 の見分け方 と、+allowDivergent を入れるタイミング は、事故を減らすうえで重要です。(Microsoft Learn)
残留オブジェクト掃除の結論
安全に進める流れは、次の5つです。
repadmin /showrepl * /csv > showrepl.csvで、どの DC とどのパーティションで複製が止まっているかを先に把握する。(Microsoft Learn)- 最新の変更を持つ 参照 DC を決め、その DC の GUID を確認する。参照 DC には対象パーティションの書き込み可能なコピーが必要です。(Microsoft Learn)
repadmin /removelingeringobjects <DestDC> <SourceDCGUID> <LDAPPartition> /advisory_modeを先に実行し、削除候補を確認する。(Microsoft Learn)- 問題なければ
/advisory_modeなしで本削除する。2042/8614 で隔離されている場合だけ、削除後に+allowDivergentで複製を再開し、安定後に-allowDivergentへ戻す。(Microsoft Learn) - 再発防止として、全 DC で
Strict Replication Consistencyを有効にする。(Microsoft Learn)
まずイベント番号で方針を分ける
残留オブジェクト対応で迷うときは、最初にイベント番号を見ます。ここを間違えると、同じ repadmin でも打つ順番が変わります。
- Event ID 1988 は、
Strict Replication Consistencyが有効な宛先 DC が、存在しないはずのオブジェクト更新を受け取り、対象パーティションの受信複製をブロックした状態です。イベント本文にはソース DC、オブジェクト、ディレクトリ パーティションが出るので、対象の切り分けに使えます。(Microsoft Learn) - Event ID 2042 と replication error 8614 は、最後の複製から
tombstone lifetimeを超えたことで複製が停止している状態です。Microsoft の手順でも、まず lingering objects を確認・削除し、その後に複製を再開する流れが示されています。(Microsoft Learn) - Event ID 1388 は、
Strict Replication Consistencyが無効な宛先 DC に残留オブジェクトがすでに再導入された状態です。このケースはRepadminや LoLv2 をそのまま当てる前提ではなく、Microsoft の手動削除手順か、DC の降格・再構築を含めて判断したほうが安全です。(Microsoft Learn)
掃除前に確認する前提条件
戻し方は「undo」ではなく復元だと考える
repadmin /removelingeringobjects に元へ戻すスイッチはありません。変更前には、AD 互換の方法で System State バックアップを取ってください。Microsoft は DC の復元手段として System State バックアップを前提にしており、仮想 DC ではスナップショット、コピーした VHD、保存状態を安易な戻し方として使わないよう注意しています。これらは USN rollback や複製不整合の原因になり得ます。(Microsoft Learn)
tombstone lifetime を把握する
残留オブジェクトは、DC が tombstone lifetime より長く複製できなかったときに起きやすくなります。現在サポートされている Windows Server で新規作成されたフォレストの既定値は 180 日ですが、古いフォレストでは 60 日のまま残っていることがあります。さらに、DC を新しい Windows Server に更新しても、既存の TSL は自動では変わりません。(Microsoft Learn)
2042 のイベント本文には、現在構成されている Tombstone lifetime (days) が出ます。イベントが出ていない環境では、repadmin /showattr で CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,... を確認して、想定より短い TSL になっていないか見ておくと安全です。(Microsoft Learn)
repadmin /showattr <DC名> "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=<forest-root>,DC=<tld>"この確認を省くと、「数週間止まっただけだから大丈夫」と思い込んで誤判定しやすくなります。(Microsoft Learn)
参照 DC は「近い DC」ではなく「最新で正しい DC」を選ぶ
参照 DC は、対象パーティションの最新かつ書き込み可能なコピーを持つ DC でなければいけません。RODC や、たまたま疎通があるだけの DC を参照にすると、消してはいけないオブジェクトまで削除候補として扱う危険があります。LoL/LoLv2 の説明でも、参照 DC は書き込み可能コピーを持つ必要があり、RODC は適切な参照 DC ではないとされています。(Microsoft Learn)
必要権限を確認する
対象 DC で基本手順を実施するには、少なくとも Domain Admins 相当の権限が必要です。フォレスト全体で +strict を有効にするなら、Enterprise Admins 相当で進める前提で考えてください。(Microsoft Learn)
残留オブジェクトを安全に掃除する基本手順
まず showrepl で停滞箇所を見つける
最初にやるべきことは、削除ではなく複製状況の棚卸しです。
repadmin /showrepl * /csv > showrepl.csvMicrosoft も showrepl.csv を Excel で開き、Last Success を古い順に並べて失敗箇所を洗い出す手順を案内しています。ここで長期間止まっている接続を見つけずに削除だけ進めると、掃除後に別パーティションで同じ問題が再発しやすくなります。(Microsoft Learn)
参照 DC の GUID を取得する
次に、最新の変更を持つと判断した参照 DC の GUID を確認します。
repadmin /showrepl <AuthDCName> | moreこの出力にある最初の DSA object GUID を、後続の repadmin /removelingeringobjects の SourceDCGUID に使います。参照 DC を決め打ちできない場合は、複数 DC で同じ確認を行い、最も新しい変更を持つ DC を見極めてから進めます。(Microsoft Learn)
advisory_mode で dry-run する
本削除の前に、必ず dry-run します。
repadmin /removelingeringobjects <DestDC> <SourceDCGUID> <LDAPPartition> /advisory_modeLDAPPartition には、対象の名前付けコンテキストを入れます。代表例は次のとおりです。(Microsoft Learn)
- ドメイン パーティション:
DC=contoso,DC=com - 構成パーティション:
CN=Configuration,DC=contoso,DC=com - スキーマ パーティション:
CN=Schema,CN=Configuration,DC=contoso,DC=com
イベント 1988 の本文には、ソース DC とディレクトリ パーティションが含まれるので、まずはその情報と一致するパーティションから着手すると迷いにくくなります。(Microsoft Learn)
問題なければ本削除する
dry-run の結果が妥当で、参照 DC の選定にも自信が持てたら、同じコマンドを /advisory_mode なしで実行します。
repadmin /removelingeringobjects <DestDC> <SourceDCGUID> <LDAPPartition>削除は DC 単位・パーティション単位で進めるのが基本です。いきなり広い範囲へ一括実行するより、対象を絞って確認しながら進めたほうが事故を抑えられます。GUI で一覧を見ながら進めたいなら、Microsoft が推奨する LoLv2 も選択肢です。LoL/LoLv2 は検出と削除を一つのインターフェースで扱えますが、.NET Framework 4.5.2 や Remote Event Log Management (RPC) の許可が前提になります。(Microsoft Learn)
2042 / 8614 なら、削除後に複製を再開する
2042 または 8614 で複製が隔離されている場合は、残留オブジェクトを取り切ってから 複製を再開します。
repadmin /regkey <hostname> +allowDivergent複製が正常化したら、保護を戻します。
repadmin /regkey <hostname> -allowDivergent+allowDivergent を先に入れると、古いオブジェクトを再び流し込む側に回る危険があります。Microsoft も、すべての lingering objects を削除した後 にだけこの設定を使うよう案内しています。(Microsoft Learn)
最後に Strict Replication Consistency を有効にする
Strict Replication Consistency は再発防止の要です。設定場所は HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters 配下ですが、Microsoft は直接レジストリを触るより repadmin を使う方法を推奨しています。(Microsoft Learn)
repadmin /regkey * +strictこの設定が無効だと、宛先 DC がソース DC に完全オブジェクトを要求し、削除済みオブジェクトがフォレストに再導入される可能性があります。有効なら、問題のあるパーティションの受信複製を止めて拡散を防げます。(Microsoft Learn)
失敗しやすいポイント
/advisory_mode を省略していきなり削除する
もっとも多い失敗です。dry-run は「削除候補の確認」と「参照 DC 選定の最終チェック」を兼ねています。ここを飛ばすと、操作ミスがそのまま削除になります。(Microsoft Learn)
参照 DC を誤る
近い DC、応答が速い DC、たまたま空いている DC ではなく、最新かつ書き込み可能な DC を参照にしてください。特に RODC を参照側に使うのは不適切です。(Microsoft Learn)
ドメイン パーティションだけ見て終わる
残留オブジェクトはドメイン パーティションだけとは限りません。構成やスキーマなど、名前付けコンテキスト単位で対象を見ます。大規模環境で LoL/LoLv2 を使う場合も、全スキャンは時間がかかるので、まず対象パーティションとターゲット DC を絞るのが実務向きです。(Microsoft Learn)
時刻ずれを見落とす
8614 や 2042 は、長期停止だけでなく 大きな時刻ジャンプ でも見かけ上発生します。オフライン DC が見当たらないのに症状が合わないときは、W32Time 設定、仮想基盤との時刻同期、BIOS 時計、イベントログの不自然な日時を先に確認してください。(Microsoft Learn)
VM スナップショットや保存状態を「戻し方」に使う
仮想 DC を TSL より長く停止・保存したり、スナップショットや複製した VHD で戻したりすると、複製の整合性をさらに崩すことがあります。特に DC では、通常のサーバーより「巻き戻し」が危険です。(Microsoft Learn)
Event ID 1388 を 1988 と同じ流れで処理する
1388 は、残留オブジェクトがすでに再導入されたケースです。1988 や 2042/8614 の「dry-run → 削除 → 再開」と同じ感覚で進めると、方針がずれます。1388 を見たら、まず手動削除手順か DC の再構築まで含めて見直してください。(Microsoft Learn)
戻し方と代替策
変更を戻す一番現実的な方法はバックアップからの復元
削除後に「やっぱり違った」と気づいても、repadmin 自体に元へ戻す機能はありません。確実な戻し方として考えるべきなのは、変更前の System State バックアップからの復元です。Microsoft も、DC の復元では AD 互換のバックアップ手段を使う前提で案内しています。(Microsoft Learn)
AD Recycle Bin が有効なら、ドメイン パーティションの戻しやすさは上がる
すでに Active Directory Recycle Bin が有効な環境なら、ドメイン パーティションで削除されたオブジェクトは Active Directory 管理センターから復元できます。一方、構成パーティションなどのオブジェクト復元は Restore-ADObject が必要です。つまり、Recycle Bin は便利ですが、どのパーティションで何を消したか まで把握していないと、戻し方としては不十分です。(Microsoft Learn)
迷うなら「掃除」より「降格・再構築」が安全なこともある
次の条件に当てはまるなら、古い DC を無理に救うより 降格・再構築 を選んだほうが結果として安全です。
- 対象 DC が TSL を大きく超えて止まっており、ローカルに残したい固有データがない。(Microsoft Learn)
- 参照 DC を自信を持って決められない。(Microsoft Learn)
- Event ID 1388 で、すでに再導入が起きている。(Microsoft Learn)
- 仮想基盤のスナップショット運用や時刻ジャンプが絡み、DC 自体の信頼性が低い。(Microsoft Learn)
ただし、強制降格はその DC 上の 未複製の更新を失う可能性 があるため、「とにかく消して作り直せばよい」とは言い切れません。ローカル発生の更新が残っていそうな DC では、先にその有無を見てから判断してください。(Microsoft Learn)
再発防止でやるべきこと
Strict Replication Consistencyを有効にしたまま運用する。(Microsoft Learn)repadmin /showrepl * /csvを定期確認し、Last Successが古い接続を放置しない。(Microsoft Learn)- 仮想 DC を TSL より長く保存状態にしない。スナップショット、VHD コピー、クローンを安易に使わない。(Microsoft Learn)
- DC のバックアップは定期的に取り、少なくとも TSL を意識した周期で維持する。Microsoft は System State の定期取得を前提にしており、仮想 DC でも guest OS 内のバックアップを推奨しています。(Microsoft Learn)
- 遠隔地配備や一時保管で DC が長期間ネットワークから外れる運用を避ける。長期切断は lingering objects の典型原因です。(Microsoft Learn)
残留オブジェクト対応で本当に大切なのは、削除コマンドを知っていることではありません。どの DC を正とするかを誤らないこと、dry-run を省略しないこと、複製を再開するタイミングを誤らないこと の3つです。まずは repadmin /showrepl * /csv > showrepl.csv で停滞箇所を確認し、Event ID 1988 / 2042 / 8614 なのか、1388 なのかを切り分けてください。そこまで整理できれば、掃除すべきか、DC を作り直すべきかの判断はかなりしやすくなります。(Microsoft Learn)
コメント