An archive policy is in place, the archive mailbox is enabled and visible, items are well past the age limit, and none of them have moved. There is nothing to read in a log and no error anywhere, because nothing failed. Something declined to start.
Five conditions account for almost all of these, and they are worth checking in this order because the first two are the cheapest to eliminate and the third invalidates the policy entirely.
Two systems, and only one of them can archive
This is the one that makes the rest of the troubleshooting pointless if you have it, because the policy was never able to do what you asked. Microsoft 365 has two retention systems that coexist, and they are not interchangeable.
Exchange messaging records management uses retention tags and retention policies, and a tag can carry a move to archive action. Purview retention labels and policies handle retention and deletion across the wider service, and they do not move items to the online archive. If the archive behaviour was configured with a Purview retention label, the items are being retained exactly as instructed and no move was ever going to happen.
So the first question is not why the policy did not run. It is whether the thing configured was an Exchange retention tag with a move action at all.
A mailbox under 10 MB is never processed automatically
The assistant that applies retention policies runs automatically about once every seven days, and only for mailboxes larger than 10 MB. Below that threshold it does not run automatically at all.
The reason this matters out of proportion to how obscure it sounds is that it breaks testing specifically. The sensible way to validate an archive policy is a test mailbox with a few deliberately aged messages in it. That mailbox is a long way under 10 MB, so it is precisely the case the automatic run skips. The policy is correct, the test proves nothing, and the conclusion drawn is that archiving is broken.
For small mailboxes the documented approach is to run the assistant by hand each time you want items moved. That is a workaround rather than a fix, and it is the right answer for a test mailbox and a poor answer for a production one, where the better move is to stop worrying about a mailbox holding under 10 MB of mail.
The retention clock, and what resets it
The cause behind the most confusing version of this: most of the mailbox archives correctly and specific items stubbornly stay put, often the ones somebody cares about.
Retention age is calculated from an item's retention start date, which for ordinary received mail is the date it was received. But if the item is modified, the last modified date changes and becomes the new starting point for the calculation. Modification here is broader than editing: moving an item between folders, marking it read or unread, flagging it, or applying a category all count.
The practical consequence is that an item somebody has been actively working with has a retention clock that keeps restarting. A message received two years ago that was flagged last week is, for retention purposes, a week old. This is working as designed, and it is essentially invisible unless you know to look for it.
Holds stop the assistant without saying so
A retention hold on a mailbox prevents the assistant from processing it, which stops archive moves along with everything else. Holds are applied for good reasons, often during offboarding, litigation, or an investigation, and they are frequently applied by somebody other than the person now troubleshooting the archive.
This is worth checking early precisely because it is administratively invisible from the mailbox owner's side. From the user's perspective nothing has changed and their mail simply stops archiving.
A disabled account stops archiving entirely
Where the primary mailbox belongs to a user account that has been disabled, messaging records management does not move items to the archive mailbox. Shared mailboxes are the exception, because their associated account is expected to be disabled and they are handled accordingly.
This one bites during offboarding, which is exactly when people are trying to get a departing employee's mail into the archive before doing something else with the mailbox. Disabling the account first is the natural order of operations and it is the order that prevents the archiving from happening. Converting the mailbox to a shared mailbox is the usual way through.
Building the policy, and running the assistant by hand
For reference, the shape of an Exchange retention policy that moves items to the archive, and the command that processes a mailbox immediately rather than waiting for the weekly run:
New-RetentionPolicyTag "ArchiveTag" -Type All -RetentionEnabled $true `
-AgeLimitForRetention 90 -RetentionAction MoveToArchive
New-RetentionPolicy "CorpPolicy" -RetentionPolicyTagLinks "ArchiveTag"
Set-Mailbox <mailbox> -RetentionPolicy "CorpPolicy"
Start-ManagedFolderAssistant -Identity <mailbox>The move action on the tag is the part that matters for archiving. A tag that is otherwise correctly built and configured to delete rather than move will apply cleanly and never archive anything, which is the same outcome as the Purview label case arrived at by a different route.
Running the assistant by hand is also the honest way to test a policy change. Waiting a week to find out whether a configuration worked is not troubleshooting, and the manual run removes the schedule from the list of things that might be responsible.
The order worth working in
- Confirm the archiving behaviour is an Exchange retention tag with a move to archive action, not a Purview label.
- Check the mailbox size against the 10 MB threshold, particularly if this is a test mailbox.
- Check for a retention hold on the mailbox.
- Check whether the associated user account is disabled and the mailbox is not shared.
- Run the assistant by hand, then look at whether specific items or all items stayed behind. Specific items points at the retention clock.
How long after enabling the archive should items start moving?
The automatic run happens roughly weekly rather than on enablement, so give it a cycle or run the assistant by hand. Expecting movement within hours of applying a policy is the most common false alarm here.
Does the archive have its own separate retention policy?
The policy applies to the mailbox and its tags govern what happens to items in both the primary and the archive, so it is one configuration rather than two. That is also why a tag that deletes rather than moves can produce alarming results.
Can I archive a departing employee's mail after disabling their account?
Not while the account is disabled and the mailbox is still a user mailbox. Convert it to a shared mailbox, which is the supported state for a mailbox with no active user behind it.
Why did some items move and others not?
Almost always the retention clock. Items that have been moved, flagged, categorised or marked read or unread have had their retention start date reset, so they are younger than the policy limit even though they arrived years ago.