Exchange Online PowerShell（ExO V3.x）で予定表などのフォルダー権限を削除しようとして、Remove-MailboxFolderPermission の -User に GUID（ObjectId）を指定すると失敗することがあります。原因の見分け方と、確実に削除する実務手順をまとめます。
問題の概要：GUID 指定の Remove-MailboxFolderPermission が失敗する
Exchange Online PowerShell（いわゆる ExO V3.x / REST ベース）で、特定のメールボックスフォルダー（例：Calendar）のアクセス権を削除しようとしたとき、次のような現象に遭遇することがあります。
- DisplayName（表示名）を文字列で渡すと削除できることがある
- しかし GUID（Azure AD の ObjectId など） を渡すと削除できない
実行例（失敗しやすいパターン）：
Remove-MailboxFolderPermission -Identity [email protected]:\Calendar -User 01234567-89ab-cdef-0123-456789abcdef代表的なエラー例：
UserNotFoundInPermissionEntryException
There is no existing permission entry found for user: 01234567-89ab-cdef-0123-456789abcdefGUID は本来一意で安全な指定方法に見えますが、このケースでは「一意かどうか」よりも、Exchange Online がその主体（ユーザー/グループ）を“有効な受信者”として解決できるかが成否を左右します。
原因の整理：「権限は存在する」のに「主体が解決できない」
Get-MailboxFolderPermission で権限が見えているのに、Remove-MailboxFolderPermission で削除できない場合、よくある本質は次のどちらかです。
- 権限エントリは残っている（過去に付与された）
- しかしそのエントリが指しているセキュリティ主体を、いまのディレクトリ状態では Exchange が受信者として解決できない
たとえば、次のような状況が「解決できない主体」を作ります。
- 対象ユーザーが削除済み、もしくは復元保留状態で、権限だけ残っている
- Exchange Online ライセンスが外れており、受信者としての属性が不足している（メールボックス/メールユーザーとして見えない）
- ゲスト/外部主体や、メール有効化されていないグループに対して権限が付与されていた
- 以前は解決できたが、UPN/SMTP 変更や同期状態のズレで参照が壊れている
この状態だと、Azure AD の ObjectId を正しく指定しても、ExO 側が「その GUID の受信者を特定できない」または「権限エントリに紐づく主体と同一だと判断できない」ため、削除コマンドが失敗しやすくなります。
まず確認する：権限エントリが ExO で“解決できる主体”か
最初の一手は、Get-MailboxFolderPermission の戻り値に含まれる User オブジェクトを展開して中身を見ることです。ここが分かると、以降の対応の当たりが付きます。
User オブジェクトを展開して確認する
# 予定表の権限を取得
$perm = Get-MailboxFolderPermission -Identity [email protected]:\Calendar
# User の中身を確認（必要に応じて Format-List）
$perm | Select-Object -ExpandProperty User | Format-List *環境や状態によって表示される項目は異なりますが、特に見たいのは次の観点です。
| 見る項目（例） | どう解釈するか | 次に取るべき動き |
|---|---|---|
| UserType | Internal 以外（Unknown など）だと、受信者解決が壊れている可能性が高い | 「User をそのまま渡す削除」や、ライセンス再付与などの回復手順を検討 |
| RecipientPrincipal | null（空）なら、ExO が受信者として特定できていないサイン | DisplayName/GUID ではなく、権限エントリの User オブジェクトで削除を試す |
| IsValidSecurityPrincipal | False の場合、「有効な受信者ではない」扱いに近く、ID 指定で削除が外れやすい | 一時的なライセンス再付与、削除済みユーザーの復元/置き換えを検討 |
| DisplayName | 見た目で対象が分かるが、同名があり得る | 操作対象の突き合わせには使えるが、削除の主キーにはしない |
重要なのは、GUID が一意でも「権限エントリが参照している主体」が解決できなければ削除できないことです。逆に言えば、権限エントリが保持している情報を“そのまま”使うと通ることがあります。
実務で効きやすい回避策：権限レコードの User をそのまま渡して削除する
GUID 文字列で指定して失敗する場合でも、Get-MailboxFolderPermission の各レコードに入っている User（権限エントリが指す主体情報）を、そのまま -User に渡すと削除できるケースがあります。
単発で削除する例
$identity = "[email protected]:\Calendar"
# 例：DisplayName でいったん該当レコードを拾い、User をそのまま使って削除
$entry = Get-MailboxFolderPermission -Identity $identity |
Where-Object { $*.User.DisplayName -eq "Jane Smith" -and $*.AccessRights -contains "Editor" } |
Select-Object -First 1
Remove-MailboxFolderPermission -Identity $identity -User $entry.User -Force -Confirm:$falseポイントは次の通りです。
- -User に渡すのは「GUID 文字列」ではなく「権限エントリの User オブジェクト」
-Forceは本来は警告抑止の意味合いですが、実環境ではこれを付けることで削除が通った例があります- 自動化するなら
-Confirm:$falseを併用し、ログを残しておくと安全です
“Unknown/削除済みっぽいエントリ”を狙って削除する例
DisplayName が信用できない場面では、UserType や RecipientPrincipal の状態で絞り込む方が安全です。
$identity = "[email protected]:\Calendar"
Get-MailboxFolderPermission -Identity $identity |
Where-Object {
$*.User -ne "Default" -and $*.User -ne "Anonymous" -and
($*.User.UserType -ne "Internal" -or $*.User.RecipientPrincipal -eq $null)
} |
ForEach-Object {
Remove-MailboxFolderPermission -Identity $identity -User $_.User -Force -Confirm:$false
}このパターンは「GUID を渡しても削除できない」タイプの棚卸しで特に効果が出やすいです。一方で、環境によって User オブジェクトの見え方が違う場合があるため、まずは削除前に必ず一覧をエクスポートしておくことをおすすめします。
一意に指定したいときの考え方：何の GUID を渡しているか
「表示名は重複するから GUID を使いたい」という発想自体は正しいのですが、Exchange Online のコマンドレットが期待している “一意な識別子” と、管理者が手元で持っている GUID が一致していないことがあります。
| 識別子の例 | どこで見つかるか | 権限削除での扱い |
|---|---|---|
| Azure AD ObjectId（Entra ID の ObjectId） | Microsoft Entra 管理センターや Graph で確認 | 一意だが、受信者として解決できない状態だと -User で失敗することがある |
| UPN / PrimarySmtpAddress | 通常のユーザー属性 | 受信者解決ができていれば成功しやすい。変更履歴がある場合は注意 |
| SID / LegacyExchangeDN など | 権限エントリの内部情報として残ることがある | 環境依存。受信者解決が壊れているとこれでも失敗することがある |
| Get-MailboxFolderPermission の User オブジェクト | 権限レコードそのもの | 「エントリに紐づく主体」として扱われやすく、削除成功率が高い |
実務的には、「一意に指定したい」＝「誤削除したくない」なので、次の順番で考えると事故を減らせます。
- 対象フォルダーの権限一覧を取得し、削除対象レコードを 権限エントリ単位で特定する
- 削除は そのレコードが持つ User オブジェクトを使う
- 事前・事後で差分を取り、ログに残す
どうしても削除できない場合の対処：受信者を“有効”な状態に戻す
回避策でも削除できない場合は、権限エントリが指す主体が「受信者としての要件」を満たしていない可能性が高いです。現場で成功しやすいのが、次の手順です。
一時的に Exchange Online ライセンスを付け直して削除する
- 対象ユーザーに Exchange Online ライセンスを一時的に割り当て、受信者として解決できる状態にする
Remove-MailboxFolderPermissionで権限を削除する- 不要であればライセンスを外す（運用ルールに従って実施）
「本来もう使わないユーザーなのに、ライセンスを付けるのは抵抗がある」という場合でも、権限の棚卸し・クリーンアップが目的なら現実的な落としどころになります。特に、監査対応や棚卸し期限がある場面では、PowerShell の小細工よりこの方が早いことがあります。
表示名（DisplayName）指定は最後の手段にする
DisplayName を文字列で指定すると削除できることがありますが、次の理由で「常用」はおすすめしません。
- 表示名は重複し得る（同姓同名、表記ゆれ、外部ユーザーの表示名など）
- Unknown エントリが、たまたま実在ユーザーと同名になると誤削除リスクが上がる
- “削除できた”という結果が、狙ったエントリだったか検証しづらい
どうしても DisplayName を使うなら、削除前に次のように 対象レコード（AccessRights、共有先、継承の有無）を必ず確認し、可能なら レコードの User を使う削除へ寄せるのが安全です。
よくあるエラーと切り分け早見表
| 症状/エラー | ありがちな原因 | 優先して試す対処 |
|---|---|---|
| UserNotFoundInPermissionEntryException | 権限エントリが指す主体を -User で解決できていない（GUID が一致していない/受信者が無効） | 権限エントリの User を渡す削除（-Force 併用） |
| There is no existing permission entry found for user: (GUID) | GUID は正しいが、ExO が権限エントリ上の主体と同一視できない | UserType / RecipientPrincipal を確認し、Unknown 系なら User オブジェクトで削除 |
| DisplayName だと消えるが GUID だと消えない | DisplayName で曖昧一致している、または古い主体参照が残っている | まず一覧をエクスポートし、削除対象レコードを固定してから削除 |
| そもそも削除対象が Default / Anonymous だった | 特殊エントリの扱いを勘違いしている | Default/Anonymous は文字列指定で管理し、他の User と混ぜない |
複数の権限をまとめて消したい：AccessRights で抽出して一括削除
「予定表の Editor 権限だけ一括で剥がしたい」「削除済みユーザー由来のゴミだけ掃除したい」といった棚卸しでは、AccessRights で抽出して削除するのが手堅いです。
削除前にバックアップ（CSV 出力）
$identity = "[email protected]:\Calendar"
Get-MailboxFolderPermission -Identity $identity |
Select-Object Identity,User,AccessRights,SharingPermissionFlags |
Export-Csv ".\CalendarPermissions_before.csv" -NoTypeInformation -Encoding UTF8Editor 系を対象に削除してログを残す
$identity = "[email protected]:\Calendar"
$targetRights = @("Editor","PublishingEditor","Reviewer") # 例：必要に応じて調整
$result = Get-MailboxFolderPermission -Identity $identity |
Where-Object {
$*.User -ne "Default" -and $*.User -ne "Anonymous" -and
($*.AccessRights | Where-Object { $targetRights -contains $* })
} |
ForEach-Object {
$userText = try { $*.User.DisplayName } catch { "$($*.User)" }
try {
Remove-MailboxFolderPermission -Identity $identity -User $*.User -Force -Confirm:$false -ErrorAction Stop
[pscustomobject]@{
Identity = $identity
User = $userText
Rights = ($*.AccessRights -join ",")
Result = "Removed"
}
} catch {
[pscustomobject]@{
Identity = $identity
User = $userText
Rights = ($*.AccessRights -join ",")
Result = $*.Exception.Message
}
}
}
$result | Export-Csv ".\CalendarPermissions_removed.csv" -NoTypeInformation -Encoding UTF8ポイントは、削除対象の特定（抽出条件）と、削除結果のログ（成功/失敗の理由）を必ず残すことです。特に共有権限はユーザー影響が大きいので、「いつ、誰の、何の権限を外したか」が追える形にしておくと運用が安定します。
再発防止：権限付与の運用を“解決できる主体”に寄せる
今回のような「権限はあるのに削除できない」は、付与時点での主体が、後から解決不能になったことが根っこです。再発防止としては、次の運用が効きます。
- 個人ユーザーではなく、メール有効なセキュリティグループに権限を付与してメンバーで制御する（人の入れ替えに強い）
- ゲスト/外部主体への付与はルール化し、棚卸し周期を短くする
- UPN/SMTP 変更が多い組織では、変更前後の棚卸しをセットで行う
- 四半期や半期ごとに
Get-MailboxFolderPermissionを CSV 化して、差分監査できるようにする
「GUID で指定できるから大丈夫」という設計よりも、Exchange Online が継続的に解決できる主体に寄せる設計の方が、長期的にトラブルが減ります。
まとめ：GUID で消せないのは“存在しない”のではなく“解決できない”ことが多い
Remove-MailboxFolderPermission で GUID 指定が失敗すると、「権限がない」と誤解しがちですが、実際には 権限エントリは残っているのに、ExO が主体を有効な受信者として解決できず操作できないケースがよくあります。
- まずは
Get-MailboxFolderPermissionの User を展開し、UserType / RecipientPrincipal / IsValidSecurityPrincipal を確認する - 削除は 権限エントリの User オブジェクトをそのまま渡す方法が成功しやすい
- それでもダメなら、一時的なライセンス再付与などで受信者解決を回復させる
上記の流れで進めると、表示名の曖昧さに頼らず、現場で安全に権限をクリーンアップしやすくなります。
コメント