Retention support for inactive mailboxes is now available in Public Cloud, and administrators have a new, consolidated PowerShell option—Set-Mailbox -ExcludeFromAllHolds—to remove most retention holds from inactive mailboxes in a single operation while preserving legal and restrictive holds required for compliance. This feature simplifies the final stages of mailbox lifecycle management, but it also introduces operational risk if used without careful verification and auditing.
Background
Inactive mailboxes exist to preserve user data after an account is deleted when retention controls are in effect. They are a compliance-first mechanism: a mailbox becomes inactive only when a retention policy, retention label, litigation hold, or an eDiscovery hold existed at the time the user account was removed. Administrators can retain data in inactive mailboxes indefinitely or configure time-based removal using retention settings. The lifecycle of an inactive mailbox — creation, retention, recovery, restore, and permanent deletion — is governed by applied holds and the Managed Folder Assistant’s processing schedule. Microsoft’s PowerShell cmdlets for Exchange Online and Purview have evolved to give admins more granular control over how holds are applied and removed. The Set-Mailbox cmdlet now includes switches intended specifically for inactive mailbox scenarios, including
-ExcludeFromAllHolds,
-ExcludeFromAllOrgHolds,
-ExcludeFromOrgHolds, and the more surgical
RemoveComplianceTagHold (documented in the Set-Mailbox reference). These options are cloud-only and are designed to be used from an Exchange Online PowerShell session.
Why this matters now
Microsoft has signalled product changes tied to inactive mailbox management as part of a broader Purview Roadmap item addressing bulk removal of retention from inactive mailboxes. That roadmap entry describes a PowerShell cmdlet to remove retention (holds) from inactive mailboxes in bulk while preserving legal holds, and it is being rolled out in phases to different clouds and tenants. Administrators who need to permanently delete inactive mailboxes — for example, to reduce licensed footprint or comply with data minimization requests — now have a supported mechanism to do that without manually reconciling dozens of policy assignments. At the same time, Exchange and Purview retain multiple types of holds that reflect legal, regulatory, and policy obligations. Removing the wrong hold can make data unrecoverable and expose the organization to legal risk. Recent large-scale Exchange hardening and policy changes underline the importance of cautious, auditable operations when changing hold state.
Overview: What ExcludeFromAllHolds does (and does not)
At-a-glance
- Purpose: Exclude an inactive mailbox from most retention and tag-based holds so the mailbox can be transitioned to soft-deleted and removed per the standard inactive-mailbox lifecycle.
- Applies to: Exchange Online (cloud service). Must be executed from an Exchange Online PowerShell session.
- Key property: Does not change retention policy definitions — it stamps an exemption on the mailbox rather than altering the policy itself.
Holds removed by ExcludeFromAllHolds
The Set-Mailbox -ExcludeFromAllHolds switch removes several types of holds applied to an inactive mailbox, including:
- Organization-level retention policies (org‑wide retention policies stamped on mailboxes).
- User-level retention policies targeted at an individual mailbox.
- Compliance tag (label) holds, when no preservation‑locked policy prevents it.
- Delay holds and delay release holds (temporary holds used during transitions or policy changes).
These removals are intended to clear the holds that prevent permanent deletion while ensuring true legal holds are not bypassed.
Holds preserved (not removed)
The command explicitly preserves the holds that are most often necessary for legal defensibility and regulatory compliance:
- eDiscovery holds (InPlaceHold / Compliance Search holds)
- Litigation hold
- Restrictive retention policies (policies with preservation lock or policies that the tenant cannot exempt)
If a hold is tied to an eDiscovery case or a litigation process, ExcludeFromAllHolds will not remove it. This design ensures that defenders of data preservation remain intact even while administrators clear less-critical retention stamps.
How ExcludeFromAllHolds fits with RemoveComplianceTagHold
- ExcludeFromAllHolds is a broad switch that attempts to remove multiple hold types and exemptions, enabling mailbox deletion if no legal or restrictive holds remain.
- RemoveComplianceTagHold (documented in Set-Mailbox as RemoveComplianceTagHoldApplied / RemoveComplianceTagHoldApplied in some docs) is granular: it removes only the hold caused by item-level retention labels (Compliance Tag holds), leaving all other holds unchanged. RemoveComplianceTagHold requires caution when used on active mailboxes: for active mailboxes the operation typically needs explicit consent via a parameter such as -ProvideConsent.
Practical rule of thumb:
- Use RemoveComplianceTagHold when the only blocker is a retention label on items and you want to maintain other holds.
- Use ExcludeFromAllHolds when the objective is to prepare an inactive mailbox for permanent deletion, and you are certain no eDiscovery or litigation holds should remain.
Prerequisites and safety checks
Before running any hold-exclusion operations on inactive mailboxes:
- Establish an active Exchange Online PowerShell session (this cannot be done from the EAC or Purview portal).
- Confirm mailbox state: the mailbox must be inactive (created when the user was deleted while a hold was applied). Use Get-Mailbox with the -InactiveMailboxOnly switch to verify.
- Verify RBAC permissions: you must have roles such as Mailbox Import Export, Retention Management, and eDiscovery Manager (or equivalent custom roles) to view and modify holds.
- Document current hold state: capture output of Get-Mailbox -InactiveMailboxOnly | Select-Object Name, InPlaceHolds, ComplianceTagHoldApplied, IsInactiveMailbox to record before/after differences.
- Confirm legal clearance: consult legal/compliance teams to ensure no active cases or regulatory holds require preservation.
Important caution: Excluding a mailbox from holds does
not update or remove the retention policy objects themselves. It stamps an exemption on the mailbox only, leaving global policies intact for other mailboxes. For defensibility, record timestamps and operator identity for every Set-Mailbox operation and retain audit logs.
Recommended verification steps (pre- and post-action)
- Pre-run inventory (example command):
- Get-Mailbox -InactiveMailboxOnly | Select Name,PrimarySmtpAddress,ExchangeGuid,InPlaceHolds,ComplianceTagHoldApplied
- Confirm absence/presence of eDiscovery or litigation holds:
- Use Purview (Content search / eDiscovery) and Get-CaseHoldPolicy if needed, or review the mailbox’s InPlaceHolds GUIDs.
- Run the command (single mailbox example):
- Set-Mailbox -Identity "john.doe@contoso.com" -ExcludeFromAllHolds
- Immediate verification:
- Get-Mailbox -SoftDeletedMailbox -Identity "john.doe@contoso.com" | Select Name,InPlaceHolds,ComplianceTagHoldApplied,DelayHoldApplied,DelayReleaseHoldApplied
- Audit trail:
- Search-UnifiedAuditLog for Set-Mailbox operations or query Exchange admin logs for changes to hold attributes.
- Allow propagation:
- Expect short propagation latency (minutes). For defensibility, note timestamps and allow the propagation window before performing irreversible deletions.
Examples and scripts (practical)
1. Remove holds from a single inactive mailbox
- Validate mailbox is inactive:
- Get-Mailbox -InactiveMailboxOnly -Identity "john.doe@contoso.com" | Select Name, IsInactiveMailbox, InPlaceHolds
- Remove holds:
- Set-Mailbox -Identity "john.doe@contoso.com" -ExcludeFromAllHolds
- Verify:
- Get-Mailbox -SoftDeletedMailbox -Identity "john.doe@contoso.com" | Select Name,InPlaceHolds,IsInactiveMailbox
2. Bulk processing with safety checks (pattern)
- Get inactive mailboxes:
- $Inactive = Get-Mailbox -InactiveMailboxOnly -ResultSize Unlimited
- Loop with pre-check:
- foreach ($mbx in $Inactive) {
$hasEd = Test-HasEdHolds -Mailbox $mbx # implement a test function based on InPlaceHolds patterns
if (!$hasEd) {
Write-Host "Processing: $($mbx.DisplayName)"
Set-Mailbox -Identity $mbx.Guid -ExcludeFromAllHolds
Start-Sleep -Seconds 5
Get-Mailbox -SoftDeletedMailbox -Identity $mbx.Guid | Select Name,InPlaceHolds
} else {
Write-Warning "Skipping due to eDiscovery or litigation hold: $($mbx.DisplayName)"
}
}
This pattern enforces a conservative approach: if eDiscovery/litigation hold GUIDs are detected (common prefixes or GUID mapping via Purview), skip the mailbox. Office365ITPros and Microsoft Q&A threads show administrators using similar pipelined commands and stress the importance of using DistinguishedName or ExchangeGUID to avoid accidental exclusions.
Using ExcludeFromAllHolds for non-user Exchange objects
The ExcludeFromAllHolds logic also supports:
- Inactive mail users (cloud-only mail users that had an associated inactive mailbox).
- Group mailboxes that are in a soft-deleted/inactive state.
Use the appropriate cmdlets (Set-MailUser or Set-Mailbox with -GroupMailbox and -SoftDeletedMailbox contexts) to stamp exemptions on the underlying mailbox object before verifying deletion behavior. The core principle remains the same: remove allowed holds while preserving litigation and eDiscovery holds.
Troubleshooting common outcomes
- Symptom: ExcludeFromAllHolds appears to have no effect.
- Likely causes:
- Only eDiscovery, litigation hold, or restrictive preservation‑locked policies exist — these are intentionally preserved and will not be removed.
- Insufficient permissions or not run against an inactive mailbox.
- The mailbox identifier was incorrect (use DistinguishedName or ExchangeGUID).
- Actions:
- Re-run Get-Mailbox with -InactiveMailboxOnly to confirm state.
- Validate InPlaceHolds and check for GUIDs that map to eDiscovery or litigation holds.
- Confirm RBAC role membership.
- Symptom: Partial hold removal (some InPlaceHolds remain).
- Explanation: eDiscovery, litigation hold GUIDs or preservation‑locked policies remain; ExcludeFromAllHolds will not remove them by design. Use the GUID mapping guidance to identify which holds remain and consult legal before any further actions.
Best practices and operational guidance
- Document everything: capture the mailbox state, the operator identity, and the exact command and timestamp. Use the unified audit log for a tamper-resistant trail.
- Process in small batches: stagger work to avoid throttling and to let Purview and Exchange process changes before proceeding to destructive steps.
- Require approvals: integrate a documented approval workflow with legal/compliance sign-off before stamping exclusions.
- Enable monitoring and alerts: after exclusions, verify soft-deletion timestamps and monitor for unexpected deletions.
- Test in a sandbox tenant: use a test tenant to validate scripts and their results before running at scale in production. Independent community guides and product blogs emphasize careful piloting of hold exclusions.
Compliance, defensibility, and legal cautions
This operation changes the preservation posture of mailbox data. Even though ExcludeFromAllHolds preserves core legal holds, there are real-world considerations:
- Preservation vs policy intent: Excluding a mailbox from organization-level or tag-based holds does not remove the retention policies themselves; it removes the mailbox from their scope. If the policy had been used as the primary mechanism for preservation, exclusion may trigger deletion per retention timelines.
- Evidentiary defensibility: If an organization excludes mailboxes to enable deletion and discovery subsequently uncovers the need to retain data, reversing that action may be difficult or impossible. Set-Mailbox exclusions are not always reversible; the Email Lifecycle Assistant or other automation may reapply holds to items with retention labels in some scenarios, but that behavior is conditional. Microsoft docs caution administrators to treat ExcludeFromAllHolds as an irreversible stamp for the mailbox’s current state unless new policies are applied.
- Auditability: Keep a clear, auditable chain of custody around these operations. Use the Unified Audit Log and record all approvals and legal sign-offs.
Broader operational context: Exchange and hybrid hardening work in recent years has emphasized inventory, documentation, and phased changes to avoid accidental escalations or data loss. These changes reinforce why hold-exclusion operations must be conservative and logged.
What to do if you need to revert
- There is no simple “undo” flag for a stamped exemption. If you need to re-protect data:
- Re-apply retention policies or labels at the mailbox or item level.
- If items were purged after an exclusion, use content search/exports (if available) and forensic backups to reconstruct evidence where possible.
- For active mailboxes where Compliance Tag hold removal has occurred, the email lifecycle assistant may reapply Compliance Tag holds for items that still carry labels; however, this behavior should not be relied upon as a reversible safety net.
Roadmap and availability notes
- Microsoft’s roadmap item describing a new cmdlet/capability to remove retention from inactive mailboxes in bulk is listed under roadmap id 537204 and indicates phased rollout across clouds. Administrators should confirm their tenant’s roadmap/Message Center updates for exact availability windows for Government or other sovereign clouds before relying on automation at scale. Community trackers and roadmap summaries reflect this roadmap entry and show it in various rollout stages. Treat any timeline in external commentary as subject to change and verify against the tenant Message Center.
Conclusion — practical takeaways for Exchange admins
- ExcludeFromAllHolds is a powerful, supported way to remove multiple non-legal holds from inactive mailboxes so they can be processed for permanent deletion; use it carefully, with audit trails and legal clearance.
- RemoveComplianceTagHold is useful when the immediate blocker is item-level retention labels and you want to make a surgical change without affecting broader holds. Confirm the exact parameter name in your environment (documentation shows RemoveComplianceTagHoldApplied / RemoveComplianceTagHoldApplied variants) and use -ProvideConsent when operating on active mailboxes.
- Always verify mailbox state with Get-Mailbox -InactiveMailboxOnly and map InPlaceHolds GUIDs back to policies or eDiscovery cases before stamping exclusions.
- Process in small batches with approvals, keep detailed logs, and allow propagation windows before performing irreversible deletions.
- Confirm tenant-specific availability and roadmap status for bulk cmdlets and any cloud boundary differences (Public Cloud vs Government Cloud) through your tenant’s Message Center and the published roadmap entry.
This capability reduces manual friction in inactive-mailbox lifecycle operations, but its safe use depends on rigorous verification, legal buy-in, stepwise automation, and detailed audit trails. The operational benefits are real — license reclamation, reduced attack surface, and simpler lifecycle management — but they must be balanced against the requirements of defensible preservation and regulatory obligations.
Source: Microsoft Exchange Team Blog
Using ExcludeFromAllHolds to Remove Holds from Inactive Mailboxes | Microsoft Community Hub