StorageTransientException: the mailbox is busy or over quota during a move

Fix it now

The store refused an operation and MRS classified the refusal as temporary: the mailbox was locked by another operation, the target was over quota, or the database was busy. One occurrence buried in a long report is normal. The ones worth acting on are those that repeat until the retry budget is gone, because those were never transient.

$stats = Get-MoveRequestStatistics -Identity user@contoso.com -IncludeReport
$stats.Report.Failures | Select-Object -Last 5
Get-MailboxDatabase -Status | Format-Table Name,Server,Mounted
Get-MailboxStatistics user@contoso.com | Format-List TotalItemSize,ItemCount
Get-Mailbox user@contoso.com | Format-List *Quota*,UseDatabaseQuotaDefaults

1. Compare TotalItemSize against ProhibitSendReceiveQuota. If the mailbox is at or over it, the store has stopped accepting writes and a move is a very long sequence of writes.
2. Raise the quota if that is the fault. UseDatabaseQuotaDefaults has to be $false before per-mailbox values apply: Set-Mailbox user@contoso.com -UseDatabaseQuotaDefaults $false -ProhibitSendReceiveQuota 5GB.
3. Look for another request holding the mailbox: Get-MoveRequest -Identity user@contoso.com on both sides, plus Get-MigrationUser. Remove only requests that belong to an abandoned attempt.
4. Resume with Resume-MoveRequest -Identity user@contoso.com, then re-read the report and see whether the same exception comes back.

Removing a move request that is still making progress discards the partial target copy and the work done so far. Check the status before you remove anything.

If the move advances past where it stopped, you are done. If the same exception returns on every resume, the next section covers what the store is actually refusing.

Why it happens

The information store guards mailbox consistency with locks. Only one process may hold a mailbox for a structural operation at a time, so when MRS asks for a mailbox another operation already owns, the store refuses rather than queueing indefinitely. That refusal is transient by definition, because the other operation will finish. MapiExceptionMailboxInTransit is the specific case where the other operation is itself a move.

Quota is the second family. A mailbox that reaches or exceeds its send and receive limit cannot send or receive messages, and the store treats a replication write no differently. Two settings decide this and they interact: UseDatabaseQuotaDefaults decides whether the mailbox inherits the database values or uses its own, and it defaults to $true. Setting ProhibitSendReceiveQuota on a mailbox that is still inheriting changes nothing anybody can observe, which is why so many quota fixes appear to be ignored.

MapiExceptionNotFound is the odd one out and the one that is not really transient. It means the store looked for the mailbox or folder the request named and did not find it, which on a move means the directory and the store disagree: the mailbox was moved, disabled or soft deleted while the request still points at where it used to be. Retrying that cannot help, and MRS will burn its whole budget discovering as much.

Full reference

Quota settings and how they interact

Valid quota values run up to 1.999999999 terabytes or unlimited, qualified with B, KB, MB, GB or TB. An unqualified number is treated as bytes, which is a memorable way to set a quota roughly two billion times smaller than you meant.

Commands for the lock and quota picture

Orphaned move state on the directory object

When no move request is listed on either side and the mailbox still behaves as though one holds it, the leftovers are on the Active Directory user object. Microsoft documents clearing them by hand when the request itself is gone. Turn on Advanced Features in Active Directory Users and Computers, open the Attribute Editor, and look for the msExchMailboxMove attributes: msExchMailboxMoveRemoteHostName, msExchMailboxMoveSourceMDBLink, msExchMailboxMoveTargetMDBLink and the two archive equivalents.

Record the values before you clear them. Editing Active Directory attributes by hand is exactly the kind of change that is impossible to reverse from memory at two in the morning, and these ones are read by the service you are trying to unstick.

Telling a real transient from a permanent one wearing its coat

• A transient exception that appears once and does not return is noise. Do not chase it.
• The same exception repeating identically until the request fails is a permanent fault that MRS was not able to classify as one.
• Failures that track a clock rather than a mailbox are infrastructure: backups, maintenance windows, failovers.
• Failures that track one mailbox across every attempt are that mailbox’s state, not the network’s.
• If a batch only completes with unusual retry or concurrency settings, something in the path is closing connections and it will do it again during the cutover.

Every code this article covers

Confirm the fix worked

1. The move advances past the point it previously stopped at.
2. Get-MailboxStatistics on the target shows the size comfortably inside the quota you set.
3. Get-Mailbox <user> | Format-List *Quota*,UseDatabaseQuotaDefaults reads back the values you intended, with inheritance off if you set per-mailbox values.
4. Get-MoveRequest | Format-Table DisplayName,Status shows no abandoned requests left behind.
5. The application event log on the store server shows no new quota or lock events after the change.

Questions people ask about this