Active Directory Recycle Bin を ADAC（Active Directory 管理センター）で確認すると、参照するドメイン コントローラー（DC）によって「When deleted（削除日時）」が一致しないことがあります。特に削除後に昇格した新規 DC だけ、過去の削除が“最近”に見えるケースの原因と、影響範囲、削除時刻を正確に突き止める手順を整理します。
まず結論：ADACの「When deleted」は“削除イベントの真の時刻”を保証しない
最初に押さえておきたいポイントは、ADAC の Recycle Bin 画面にある「When deleted」列は、監査用途で期待するような“削除操作が発生した瞬間の時刻（いつ誰が消したかの時刻）”を、DC 間で厳密に一致させて表示することを目的にしていない、という点です。
実際に Microsoft Q&A でも、「WhenDeleted という属性はなく、ADAC の表示は whenChanged などに依存してズレて見える」という趣旨の説明や、新規 DC では tombstone を取り込んだタイミングで CN がローカル更新され、whenChanged が変わり得るという説明が提示されています。
| 見たいもの | ADACの「When deleted」 | 推奨の確認方法 |
|---|---|---|
| 削除が起きた“発生時刻” | DCによってズレる可能性がある | isDeleted のレプリケーション メタデータ（LastOriginatingChangeTime など）を見る |
| 復元可能かどうか | 判断できる（Deleted/Recycleの状態は見える） | isDeleted / isRecycled、Deleted Objects などで確認 |
| いつ物理削除（GC）されるか | 表示と一致しない場合がある | msDS-DeletedObjectLifetime / tombstoneLifetime と GC 間隔を前提に評価 |
前提知識：Recycle Bin有効時の「deleted-object」と「recycled-object」
Active Directory の削除済みオブジェクトは、Recycle Bin の有効・無効で“削除後の状態遷移”が変わります。Recycle Bin を有効にしている場合、一般に次の2段階を意識するとトラブルシュートが早くなります。
| 状態 | 主な判別 | 意味 | 期間の基準 |
|---|---|---|---|
| deleted-object（削除済み：復元可能） | isDeleted = TRUE かつ isRecycled が無い | 削除済みだが復元対象。属性が比較的多く残る | deleted-object lifetime（msDS-DeletedObjectLifetime） |
| recycled-object（リサイクル済み：復元不可） | isRecycled = TRUE | 復元不可。残る属性が大幅に少なくなる | tombstone lifetime（tombstoneLifetime） |
仕様としては、Recycle Bin が有効な場合、削除操作により通常のオブジェクトが deleted-object になり、deleted-object lifetime を超えると recycled-object に変換され、さらに tombstone lifetime を超えるとディレクトリから削除されます。
なぜDCごとに「When deleted」が変わるのか
ポイント1：whenChanged は複製されず、各DCがローカルに持つ
ズレの根本原因として最も説明力が高いのが、whenChanged 属性がレプリケーションで揃わないことです。Microsoft の属性仕様では、whenChanged は「最終変更日時」だがこの値は複製されない旨が明記されています。
つまり、同じオブジェクト（削除済みオブジェクトを含む）を DC001 と DC003 で見ても、whenChanged は“各 DC がその更新を自分のDBへ反映した時刻”として保持されやすく、結果として DC 間で一致しないことがあります。
ポイント2：削除済みオブジェクトは「DEL:<GUID>」形式へ名前が変更される
削除済みオブジェクトは、Deleted Objects コンテナー配下へ移動するだけでなく、同一階層にフラットに置かれる都合で、衝突回避のために RDN（名前）がユニークになるよう付け替えられます。具体的には、元の name に 0x0A（改行相当）と「DEL:」+ objectGUID を連結した“delete-mangled RDN”に変換されます。
この“名前が書き換わる”処理が、新規 DC が初期同期で tombstone / deleted-object を取り込むタイミングでローカル更新として扱われることがあり、whenChanged が“最近”に見える引き金になります（過去が書き換わったように見える理由）。Microsoft Q&A の事例でも、新規 DC 側で cn がローカルに書き込まれたメタデータが確認されています。
ポイント3：ADACの「When deleted」は内部的に whenChanged 等を参照している可能性が高い
AD には「whenDeleted」という単一の“絶対的な削除日時属性”が用意されているわけではないため、GUI が何らかの運用属性（whenChanged など）を元に「When deleted」列を構成していると考えるのが自然です。実際に Microsoft Q&A でも「WhenDeleted 属性はない」という説明があります。
このズレは危険？削除のレプリケーションや寿命管理への影響
結論から言うと、ADAC表示のズレ＝削除の伝播がズレる／保持期限がズレる、ではありません。削除は isDeleted によって tombstone / deleted-object としてレプリケーションされ、削除済みである事実（isDeleted=TRUE）はディレクトリに残ります。
また、Recycle Bin 有効時の「deleted-object → recycled-object → 物理削除」という状態遷移も、deleted-object lifetime と tombstone lifetime に従って進みます。msDS-DeletedObjectLifetime が未設定の場合は tombstone lifetime をデフォルトとして扱うこと、tombstoneLifetime / msDS-DeletedObjectLifetime の最小値（2日）などはプロトコル仕様で定義されています。
ガベージコレクション（物理削除）は各 DC が独立に実行し、既定では一定間隔（例：12時間）で動作します。表示列がブレても、GC は“表示列”ではなくディレクトリが保持する削除状態と寿命を元に動くため、表示だけで判断しないことが重要です。
本当に知りたい「削除時刻」を正確に確認する方法
監査や障害調査で必要なのは、ADAC の見た目ではなく、削除を起点とする属性のレプリケーション メタデータです。ここでは「isDeleted が TRUE になった起点時刻（削除が発生した時刻）」を、PowerShell と repadmin の両方で確認する実務手順を紹介します。
手順1：削除済みオブジェクトを特定し、objectGUIDを取得する
まずは対象を 1 件に絞ります。Get-ADObject は -IncludeDeletedObjects を付けることで削除済みを検索でき、例として whenChanged / isDeleted / isRecycled を組み合わせたフィルター例も公式に掲載されています。
# 例）samAccountName が分かっている場合（ユーザー/コンピューターなど）
$target = Get-ADObject -IncludeDeletedObjects `
-Filter 'isDeleted -eq $True -and samAccountName -eq "User01" -and -not (isRecycled -eq $True)' `
-Properties objectGUID,distinguishedName,whenChanged,lastKnownParent,msDS-LastKnownRDN
$target | Select-Object objectGUID,distinguishedName,whenChanged,lastKnownParent,msDS-LastKnownRDNポイントは、同じコマンドでも -Server を付けるかどうかで“どの DC 視点の値か”が変わることです。whenChanged は DC ごとに差が出る前提なので、比較するときは -Server で明示し、同条件で揃えます。
手順2：Get-ADReplicationAttributeMetadata で isDeleted の起点時刻を見る（推奨）
Get-ADReplicationAttributeMetadata は、オブジェクト（DN または objectGUID）に対する属性単位のレプリケーション メタデータを取得できます。-IncludeDeletedObjects で削除済みも対象にできます。
# 例）DC 一覧を取得して、各 DC のメタデータを比較する
$dcs = Get-ADDomainController -Filter * | Select-Object -ExpandProperty HostName
$guid = $target.ObjectGUID
$result = foreach ($dc in $dcs) {
Get-ADReplicationAttributeMetadata -Object $guid -Server $dc -IncludeDeletedObjects -Properties isDeleted,cn |
Where-Object { $_.AttributeName -in @('isDeleted','cn') } |
Select-Object @{n='DC';e={$dc}}, AttributeName, LastOriginatingChangeTime, LastOriginatingChangeDirectoryServerIdentity, Version
}
$result | Sort-Object AttributeName,DC | Format-Table -AutoSize読み取り方の目安は次の通りです。
- isDeleted：削除を示す本体。ここに表示される LastOriginatingChangeTime が「削除が起きた起点時刻」として扱いやすい
- cn：DEL:<GUID> 形式への名前変更など、DC ローカル更新を含み得る。whenChanged がズレる背景を説明する材料になる
もし現象が「新規 DC だけ When deleted が最近」でも、isDeleted のメタデータの起点時刻が全 DC で一致しているなら、レプリケーション異常ではなく“表示に使っている属性の性質”に起因する可能性が高い、と判断できます。
手順3：repadmin /showobjmeta で同じことをCLIでも確認する
GUI や PowerShell に依存したくない場合は repadmin の /showobjmeta で、同一オブジェクトのレプリケーション メタデータを DC 間で比較できます。オブジェクトは DN だけでなく GUID でも指定可能です。
# 例）特定 DC にある対象オブジェクトのメタデータ（GUID指定）
repadmin /showobjmeta DC001 "<GUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx>"
# DC を変えて比較
repadmin /showobjmeta DC003 "<GUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx>"repadmin 出力の中で isDeleted の行（属性）に付随するタイムスタンプや、originating server（起点 DC）を比較することで、「いつ・どの DC で削除が起きたか」と「新規 DC がいつその更新を取り込んだか」を切り分けられます。
“新規DCだけ過去が書き換わる”ように見える典型シナリオ
現象をタイムラインで整理すると、理解が早くなります。
| 時系列 | 起きていること | 見え方の差が出る理由 |
|---|---|---|
| T0 | DC001 でユーザーを削除 | DC001 は削除操作をローカルで処理。isDeleted が TRUE になり、削除済みオブジェクトへ |
| T0〜T1 | DC002 へ通常レプリケーション | DC002 も削除済みとして取り込み。whenChanged は各 DC の処理時刻で差が出る可能性 |
| T2 | DC003 を昇格（削除後に新規追加） | 初期同期で過去の削除済みオブジェクトも取り込む |
| T2直後 | DC003 が tombstone/deleted-object をDBへ反映 | CN/RDN の DEL:<GUID> 付与等がローカル更新扱いになり、whenChanged が“最近”に見えることがある |
このとき、ADAC が When deleted の表示に whenChanged を使っていると、DC003 だけ過去の削除が T2 付近に見えてしまう、という構図です。
保持期間（msDS-DeletedObjectLifetime / tombstoneLifetime）を安全に把握する
削除済みオブジェクトが「いつまで復元可能か」「いつ物理削除されるか」は、見た目ではなく設定値で判断します。特に環境によって既定値が揃っていないことがあるため、値を明示的に確認しておくのが安全です。
| 設定/属性 | 役割 | どこを見る | 補足 |
|---|---|---|---|
| msDS-DeletedObjectLifetime | deleted-object（復元可能）状態の保持日数 | CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,… | 未設定なら tombstoneLifetime を既定として扱う |
| tombstoneLifetime | （Recycle Bin有効時は主に recycled-object の）保持日数 | 同上 | 未設定時は 60 日が既定（プロトコル仕様） |
| garbageCollPeriod | GC（掃除処理）が走る間隔（時間） | 同上 | 既定は 12 時間 |
# 例）設定値を確認（Configuration パーティションの Directory Service オブジェクト）
$root = (Get-ADRootDSE).configurationNamingContext
$dsDn = "CN=Directory Service,CN=Windows NT,CN=Services,$root"
Get-ADObject -Identity $dsDn -Properties tombstoneLifetime,msDS-DeletedObjectLifetime,garbageCollPeriod |
Select-Object tombstoneLifetime,msDS-DeletedObjectLifetime,garbageCollPeriodここで値を把握しておくと、「ADAC の When deleted 表示がズレているのに、復元できる/できないが変わった」などの誤解を避けやすくなります。
運用で困らないための実務的な対策
レポートや監査に ADAC の「When deleted」を使わない
ADAC は復元操作の入口として便利ですが、日時の整合性を担保する設計ではありません。削除時刻をレポート化するなら、以下の優先度がおすすめです。
- 監査ログ（誰が・いつ削除したか）：Windows の「Directory Service Changes」監査で、削除イベント（例：5141）を取得する
- AD の事実（いつ削除状態になったか）：isDeleted のレプリケーション メタデータ（LastOriginatingChangeTime）
- 復元可否：isRecycled の有無、deleted-object lifetime の範囲
複数DCの比較は「同じものを同じ取り方」で
今回のような“DC によって値が違う”系の調査では、次のルールで情報を揃えると判断がブレません。
- PowerShell は -Server <DC> を必ず付け、どの DC の値かを固定する
- 「見た目の列」ではなく、isDeleted/isRecycled とメタデータ（showobjmeta / Get-ADReplicationAttributeMetadata）で比較する
- DC の時刻同期（NTP）も念のため確認する（時計ずれがあると“最近に見える”が誇張される）
「復元できるのに見つからない」を避ける検索フィルター
削除済みオブジェクト検索では、Deleted Objects コンテナー自体がヒットしたり、recycled-object（復元不可）まで混ざったりして混乱することがあります。Get-ADObject の公式例にもある通り、次の条件を入れておくと実務上安全です。
- isDeleted -eq True
- -not (isRecycled -eq True)
- name -ne “Deleted Objects”
まとめ：ズレの正体を知れば、焦らず安全に判断できる
- ADAC の「When deleted」は、DC 間で一致しないことがある（特に削除後に昇格した新規 DC で“最近に見える”現象が起きやすい）
- 背景には whenChanged が複製されないこと、削除時に DEL:<GUID> 形式へ名前が変わること、そして新規 DC の初期同期でローカル更新が発生し得ることがある
- 削除の伝播や寿命管理を判断するなら、isDeleted / isRecycled とレプリケーション メタデータ（Get-ADReplicationAttributeMetadata / repadmin）で確認する
表示のズレ自体は“よくある罠”ですが、見るべき場所をメタデータに切り替えるだけで、仕様と異常を切り分けられるようになります。
コメント