Technical Case — KT-000002

Exchange Online Archive Not Reducing Primary Mailbox

An Online Archive was active and an MRM policy was assigned, but the primary mailbox remained near capacity. The investigation separated configuration from processing and proved activity at the archive itself. Configured does not mean processing.

Documented by Published

Case ID

KT-000002

Category

Microsoft 365

Status

Resolved

Technologies

Exchange Online / MRM / PowerShell

Tags: Exchange · Microsoft 365 · PowerShell

Privacy note: All mailbox identities, policy and tag names, measurements, counters, and displayed output are synthetic examples. No tenant identifiers or customer data are included.

Problem

What happened?

A Microsoft 365 mailbox was approaching its primary-mailbox quota even though an Online Archive existed, auto-expanding archiving was enabled, and an Exchange MRM retention policy was assigned.

The mailbox owner was also deleting messages manually. A smaller primary mailbox therefore could not prove that MRM had moved any content to the archive.

Environment

Where did it happen?

Platform

Microsoft 365

Mail

Exchange Online

Lifecycle

Messaging Records Management

Administration

Exchange Online PowerShell

Symptoms

What did the technician see?

  • The primary mailbox remained close to capacity.
  • The archive existed and already contained substantial historical data.
  • The intended retention policy appeared to be assigned.
  • Manual deletions contaminated primary-mailbox size as evidence.
  • No single admin-center percentage proved where content was moving.

Investigation

How was the problem approached?

Step 1

Capture an attributable baseline

Measure both the primary and archive stores before changing anything. The destination must be measured because manual deletion can make the source smaller without proving archive movement. 

$mbx = "user01@contoso.com" # Synthetic identity

Get-EXOMailboxStatistics -Identity $mbx |
    Select-Object DisplayName, TotalItemSize, ItemCount

Get-EXOMailboxStatistics -Identity $mbx -Archive |
    Select-Object DisplayName, TotalItemSize, ItemCount

Step 2

Inspect mailbox configuration and hold state

Query the archive, hold, policy, and retention property sets explicitly. This avoids mistaking a policy assignment for proof that MRM can archive content from user-visible folders. 

Get-EXOMailbox -Identity $mbx -PropertySets Archive, Hold, Policy, Retention |
    Select-Object RetentionPolicy,
                  RetentionHoldEnabled,
                  LitigationHoldEnabled,
                  InPlaceHolds,
                  ArchiveStatus,
                  ArchiveState,
                  AutoExpandingArchiveEnabled

Confirmed finding: RetentionHoldEnabled was True.

Microsoft documents that this setting prevents expiration or archiving from folders visible to the mailbox owner, even though Managed Folder Assistant processing can continue for other areas such as Recoverable Items.

Step 3

Verify the assigned policy and its linked archive tag

A valid retention tag can exist without being linked to the mailbox's assigned policy. The assigned policy and intended tag were checked separately. 

$policyName = "KER-DEMO-Archive-365"       # Synthetic name
$archiveTagName = "KER-DEMO-MoveToArchive-365" # Synthetic name

Get-RetentionPolicy -Identity $policyName |
    Format-List Name, RetentionPolicyTagLinks

Get-RetentionPolicyTag -Identity $archiveTagName |
    Select-Object Name,
                  Type,
                  RetentionEnabled,
                  AgeLimitForRetention,
                  RetentionAction

Confirmed finding: the intended tag was linked to the assigned policy and reported Type=All, RetentionAction=MoveToArchive, an age limit of 365 days, and RetentionEnabled=True.

Step 4

Evaluate competing explanations

Hypotheses evaluated:

  • The archive was inactive or unavailable.
  • The intended archive tag existed but was not linked to the assigned policy.
  • The primary-mailbox decrease came from manual deletion instead of archiving.
  • Litigation Hold, In-Place Holds, MRM retention hold, and Microsoft Purview retention had been treated as one control.
  • Recoverable Items pressure represented a separate hidden-data problem.

The first two hypotheses were disproved. Manual deletion remained an attribution problem, so only archive-side growth could provide immediate evidence of movement. The different hold and retention systems were checked independently rather than assumed to have equivalent behavior.

What We Tried

Document the dead ends too.

Inconclusive Evidence Avoided

The admin-center mailbox percentage and a drop in primary-mailbox size were not accepted as proof because the mailbox owner was deleting content.

The policy was not repeatedly changed after its assignment and tag linkage were confirmed. Changing multiple variables would have made the result harder to attribute.

Root Cause

What was actually wrong?

Confirmed Root Cause

A stale mailbox-level MRM retention hold had RetentionHoldEnabled=True. It prevented eligible content in user-visible mailbox folders from being expired or moved to the Online Archive, even though the intended MRM policy was assigned and the archive was active.

This mailbox-level MRM setting is not the same control as Litigation Hold, In-Place Hold, or a Microsoft Purview retention policy. Similar terminology does not make those systems interchangeable.

Resolution

How was it fixed?

After confirming that the retention hold was stale and that its removal was authorized, the mailbox-level hold was removed. The assigned MRM policy, linked MoveToArchive tag, active archive, and auto-expanding archive state were left intact. 

Set-Mailbox -Identity $mbx -RetentionHoldEnabled $false

The setting was queried again to confirm RetentionHoldEnabled=False. Managed Folder Assistant was then requested for the synthetic mailbox: 

Start-ManagedFolderAssistant -Identity $mbx

The command requests processing; it does not promise synchronous completion or a deterministic amount of immediate movement.

Final Verification

The primary and archive statistics were captured again after the request. The following values are deliberately synthetic and illustrate the evidence pattern only; they are not copied from any tenant.

Baseline — Primary

91.2 GB · 128,400 items

Baseline — Archive

63.7 GB · 245,000 items

Follow-up — Primary

91.2 GB · 128,399 items

Follow-up — Archive

63.7 GB (+0.6 MB) · 245,003 items

Confirmed verification: the archive item count and byte count increased after the blocker was removed and processing was requested. That proved renewed archive-side activity.

Monitoring conclusion: the mailbox was not declared fully remediated from a small immediate movement alone. Continued before-and-after measurements were required because Exchange Online processes asynchronously and normal mailbox activity can obscure primary-store trends.

Lessons Learned

Measure the system that moves the data.

A small verified change is stronger evidence than a large unexplained one.
  • Policy assignment and active processing are different states.
  • Measure both primary and archive stores before and after one controlled change.
  • Do not use user-driven primary-mailbox changes as proof of archiving.
  • Verify tag linkage on the assigned policy, not merely the tag's existence.
  • Keep MRM retention, Microsoft Purview retention, and legal holds conceptually separate.

Command Validation

Current Microsoft references

Every Exchange Online cmdlet and parameter shown in this candidate was checked against current Microsoft documentation during publication review.

Related Resources

Related tutorial and future opportunities

Published Tutorial

Diagnose an Archive Not Reducing Primary Mailbox Usage

Follow the reusable PowerShell procedure for checking archive state, MRM configuration, retention hold status, processing, and measured movement.

Open the Tutorial

Reference Opportunity

MRM Retention Hold vs. Microsoft Purview Retention

Suggested future content; not currently published.

PowerShell Opportunity

Exchange Online Archiving Verification Checklist

Suggested future content; not currently published.