Active Directory で「子オブジェクトが無い OU なのに削除できない」「右クリックに Delete / Move / Rename が出ない」「GPMC からは Access is denied」と困ったら、誤削除保護だけを疑うのは早計です。既定のコンピューター格納先に設定された OU が削除できなくなるケースを、確認方法と安全な解除手順付きで解説します。
「OU が削除できない／Delete が表示されない」現象の特徴
OU を整理していて「この OU はもう使っていないから削除したい」と思っても、次のような状態だと手詰まりになりがちです。
| 見えている症状 | よくある具体例 | ポイント |
|---|---|---|
| 削除系メニューが出ない | ADUC（Active Directory ユーザーとコンピューター）で OU を右クリックしても Delete / Move / Cut / Rename が表示されない | 「誤削除防止」や「権限不足」と見分けが付きにくい |
| 誤削除防止は無効 | OU のプロパティで Protect from accidental deletion（誤削除保護）をオフにしている | チェックを外したのに消せない場合は別原因を疑う |
| 別ツールでも拒否される | GPMC から削除すると Access is denied、PowerShell の Remove-ADOrganizationalUnit -Recursive でも失敗（“requested delete operation could not be performed”） | GUI だけの問題ではなく AD 側でブロックされている可能性 |
この組み合わせは、ACL（アクセス制御）や誤削除防止の典型パターンと似ています。しかし、OU 自体が「既定の格納先」として参照されている場合、管理者権限でも削除・移動・名称変更が制限されることがあります。
結論：その OU が「既定のコンピューター格納先（Default Computer OU）」になっている
原因として特に多いのが、対象の OU が 既定のコンピューター格納先（ドメイン参加時にコンピューター アカウントが作成される場所）に設定されているケースです。
多くの環境では、既定はドメイン直下の CN=Computers（コンテナー）です。ただし、運用上の理由で redircmp を使って「コンピューターは専用 OU に入る」よう変更していることがあります。もしその変更先 OU をあとから削除しようとすると、ドメイン側の参照が残っているため削除が通らず、結果として次のような現象につながります。
- ADUC のコンテキスト メニューから Delete / Move / Rename が消える（または実行できない）
- GPMC や PowerShell でも削除が拒否される
- メッセージが Access is denied や “requested delete operation could not be performed” になる
なぜ「既定の格納先」だと削除できなくなるのか
既定のコンピューター格納先（および既定のユーザー格納先）は、ドメイン ルート オブジェクトが保持する「既知の参照（well-known object）」として保存されます。つまり、ドメインが「ここが既定の配置先です」と参照しているオブジェクトを消してしまうと、ドメイン全体の整合性が崩れるため、Active Directory は削除や移動を強く拒否します。
この挙動は「誤削除防止（Protect from accidental deletion）」とは別軸です。誤削除防止は OU に対して ACL（削除拒否の ACE）を追加する仕組みですが、既定の格納先の問題は ドメインが持つ参照の整合性に起因します。そのため、誤削除防止を外しても、権限が十分でも、削除できないという状況が起きます。
まずは確認：既定の格納先がどこを指しているか
原因の切り分けはシンプルです。現在の「既定のコンピューター格納先」「既定のユーザー格納先」を PowerShell で確認します。
Get-ADDomain | Select-Object ComputersContainer, UsersContainer出力例のイメージ：
ComputersContainerがCN=Computers,DC=domain,DC=localなら標準ComputersContainerがOU=Computers,DC=domain,DC=localのように OU を指していれば、redircmpで変更済み
削除したい OU の DN（Distinguished Name）と ComputersContainer（または UsersContainer）が一致していないかを確認してください。一致していれば、削除できない本命原因です。
より確実に確認：wellKnownObjects を直接チェックする
変更履歴が追えない環境や、何が既定に設定されているか確信が持てない場合は、ドメイン ルートの wellKnownObjects 属性を直接見ると判断が速くなります（値には GUID が含まれます）。
$domain = Get-ADDomain
Get-ADObject $domain.DistinguishedName -Properties wellKnownObjects |
Select-Object -ExpandProperty wellKnownObjects対象 OU が参照されているかだけを絞り込みたいときは、DN 文字列でフィルターします。
$targetDn = "OU=OldComputers,DC=domain,DC=local"
$domain = Get-ADDomain
(Get-ADObject $domain.DistinguishedName -Properties wellKnownObjects).wellKnownObjects |
Where-Object { $_ -like "*$targetDn" }解決手順：既定の格納先を変更してから OU を削除する
対処は「参照を別の場所へ移す」→「OU を削除」の 2 段階です。先に既定の格納先を変更して参照を外すことで、OU の削除が通るようになります。
手順の全体像
| ステップ | やること | 目的 |
|---|---|---|
| 既定の格納先を確認 | Get-ADDomain で ComputersContainer/UsersContainer を確認 | 対象 OU が参照されているか判定 |
| 既定の格納先を変更 | redircmp（または redirusr）で別 DN を指定 | ドメインの参照を外す |
| OU を削除 | ADUC / GPMC / PowerShell で削除 | 不要 OU を整理 |
既定のコンピューター格納先を戻す（redircmp）
まずは、既定を標準の CN=Computers コンテナーへ戻す例です。単一ドメインの小規模環境でも、安全策として「一旦標準へ戻す」→「必要なら別 OU へ再設定」という流れが分かりやすいです。
# 例：既定を標準の Computers コンテナーへ戻す
redircmp "CN=Computers,DC=domain,DC=local"既定を別の OU にする場合は、OU の DN を指定します。
# 例：別の OU を既定にする場合
redircmp "OU=Computers,DC=domain,DC=local"実行後、念のため再確認します。
Get-ADDomain | Select-Object ComputersContainer既定のユーザー格納先が原因なら redirusr を使う
「削除できない OU」がユーザー作成の既定格納先（Default Users Container）に設定されていた場合は、redirusr を使います。
# 例：既定を標準の Users コンテナーへ戻す
redirusr "CN=Users,DC=domain,DC=local"ユーザー既定を OU にしたい場合も同様に OU DN を指定します。
既定の格納先を変更したら、OU を削除する
参照が外れたら、目的の OU を削除できます。普段使い慣れた方法で構いません。
| 方法 | 操作 | 向いている場面 |
|---|---|---|
| ADUC | OU を右クリックして Delete | 手動で整理する、少数の OU を削除する |
| GPMC | OU を選択して削除（必要に応じて GPO リンクも確認） | OU と GPO の関係を見ながら整理したい |
| PowerShell | Remove-ADOrganizationalUnit や Remove-ADObject | 複数 OU を一括整理する、再現性を重視する |
PowerShell で削除する例：
# 例：OU を削除（子オブジェクトがある可能性がある場合は -Recursive）
Remove-ADOrganizationalUnit -Identity "OU=OldComputers,DC=domain,DC=local" -Recursive削除対象が本当に空かを確認してから実行したい場合は、事前チェックも有効です。
# OU 配下の子オブジェクトを確認（1階層）
Get-ADObject -Filter * -SearchBase "OU=OldComputers,DC=domain,DC=local" -SearchScope OneLevel |
Select-Object Name, ObjectClass削除前に確認しておくと安全なこと
既定の格納先を変更する操作自体はシンプルですが、運用面での影響を最小化するために、次の点を押さえておくと安心です。
- ドメイン参加の動線：今後 PC をドメイン参加させたとき、コンピューター アカウントがどこに作成されるかが変わります。ヘルプデスク手順書やスクリプトが OU を前提にしているなら更新します。
- GPO のリンク先：グループ ポリシーは OU/ドメイン/サイトにリンクします。
CN=Computersのようなコンテナーにはリンクできません。既定を標準コンテナーへ戻す場合、意図的に「参加直後は未適用にする」のか、「別 OU に再設定する」のかを決めておきます。 - 委任（Delegation）：PC 作成を特定グループに委任している場合、既定の変更先 OU にも同等の権限が必要です。
- 複数 DC の場合の反映：変更は AD の属性更新なので複数 DC ではレプリケーションを待つ必要があります。操作する管理ツールが別 DC に接続していると「変えてないように見える」ことがあります。
「まだ削除できない」場合の追加トラブルシュート
既定の格納先を変更しても削除できない場合、別要因が重なっている可能性があります。ありがちな原因と確認方法をまとめます。
| 疑うポイント | 確認方法 | 対処の方向性 |
|---|---|---|
| 誤削除防止が実は有効 | OU の属性 ProtectedFromAccidentalDeletion を確認 | Set-ADOrganizationalUnit -ProtectedFromAccidentalDeletion $false で解除 |
| OU 配下に隠れた子オブジェクトがある | Get-ADObject で OneLevel/Subtree を検索 | 不要オブジェクトを先に削除、または -Recursive を利用 |
| ACL に Deny が入っている | dsacls や Get-Acl で権限を確認 | Deny を外す／権限を付与する（慎重に） |
| 管理ツールが RODC や別 DC に接続している | ADUC の「ドメイン コントローラーの変更」で接続先確認 | 書き込み可能な DC に切り替える |
| 削除対象が「重要な既定 OU」 | OU=Domain Controllers など、標準で作成される OU か確認 | 削除は避け、必要なら名称変更や権限設計を見直す |
誤削除防止の状態確認と解除例：
# 状態確認
Get-ADOrganizationalUnit -Identity "OU=OldComputers,DC=domain,DC=local" -Properties ProtectedFromAccidentalDeletion |
Select-Object Name, ProtectedFromAccidentalDeletion
# 解除
Set-ADOrganizationalUnit -Identity "OU=OldComputers,DC=domain,DC=local" -ProtectedFromAccidentalDeletion $falseACL（Deny）の有無をざっくり確認したい場合は、次のように dsacls を使うと現場では早いことが多いです。
dsacls "OU=OldComputers,DC=domain,DC=local"運用でハマらないためのポイント
このトラブルは「既定の格納先を OU に変えたこと自体が悪い」という話ではありません。むしろ、次の理由で OU へのリダイレクト（redircmp/redirusr）は多くの組織で採用されています。
- OU は GPO をリンクできる（コンテナーはリンクできない）
- OU 単位で委任や監査を設計しやすい
- 将来の OU 設計（部署別・端末種別）へ移行しやすい
一方で、「既定にしている OU を将来削除する可能性がある」なら、次の運用ルールを決めておくと事故を減らせます。
| 運用ルール例 | 狙い |
|---|---|
| 既定格納先 OU は “Default” と分かる名前にする | 削除候補になりにくく、参照の存在に気付きやすい |
| OU を統廃合するときは「redircmp / redirusr → 削除」の順序を手順書に明記 | 今回のような「消せない OU」を発生させない |
既定変更後は Get-ADDomain で必ず記録（チケットや変更履歴に残す） | 後任が原因追跡しやすい |
よくある質問
redircmp を実行すると、既存のコンピューター アカウントは移動しますか？
移動しません。 既定の格納先の変更は「新規に作成されるコンピューター アカウントの配置先」が変わるだけです。すでに存在するコンピューター オブジェクトは元の場所に残ります。整理が必要なら、別途 Move（移動）やスクリプトでの移動を行います。
標準の CN=Computers に戻すべきですか？それとも別 OU にすべきですか？
ドメイン参加直後から GPO を適用したい、委任や分類をしやすくしたい場合は 専用 OU を既定にする方が運用しやすいです。一方で、切り分け目的で一旦標準へ戻すのは安全で簡単です。最終的には、GPO 設計とヘルプデスク運用（誰が参加作業をするか）に合わせて決めるのが現実的です。
PowerShell の Remove-ADOrganizationalUnit が “requested delete operation could not be performed” になるのはなぜ？
誤削除防止や権限不足のほか、今回のように「ドメインが参照しているオブジェクト」を消そうとしている場合にも起こります。まずは Get-ADDomain の ComputersContainer/UsersContainer を見て、対象 OU が参照されていないかを確認してください。
まとめ：Delete が出ない OU は「既定格納先」を疑う
- 誤削除防止がオフでも、OU が削除できないことがある
- Delete / Move / Rename が表示されない、Access is denied になる場合は 既定のコンピューター（またはユーザー）格納先の参照が原因になり得る
redircmp/redirusrで既定の格納先を変更して参照を外し、その後に OU を削除する- 変更後は
Get-ADDomainで確認し、必要なら運用手順書も更新する
「削除できない OU」に遭遇したときは、まず既定の格納先を確認し、参照を外す手順を試すことで、無駄な権限調査や再起動に時間を取られずに解決できることが多いです。
コメント