Old emails not removed from Journal Mailbox?

Do NOT do a cancel operation or any other manual archiving within a journal mailbox, it will cause the journal to stop working altogether and require it to be provisioned, and at that point you would have to remove the journal target, delete the EME reference, then re-add the journal target and then resync the mailbox.

If you really wanted to do a cancel pending, there are provisions in the policy to do this, but just because they are stuck in a pending state does not mean that they have not been archived yet and you can end up with a number of duplicates

If the items have been archived and are indexed, the simple thing to do would be to delete them, as that would be the next step in the journal archive.

So the logic and flow goes as follows
 - Journal Mailbox is flagged to archive every minute
 - Journal task goes through and lists each message and starts to archive from oldest to youngest
 - An item is taken to the J2 queue where it becomes pending
 - It then places a copy of the full message in to storage archive queue
 - StorageArchive.exe then converts the item in to a DVS/DVSSP etc
 - Once the item has been archived it then posts a message to the J1 queue
 - The journal task then takes the item from J1 and locates the pending message and deletes it

As you mentioned there is a 5 minute delay (which is configurable) due to the fact that changes relating to that message could come in from other servers, so its a step to avoid duplicates

If you cancel pending on an item that is already stored in the archive, then the journal task would simply just go through and re-archive them creating duplicates

My best guess is that these items were pending in the OLD journal mailbox and you moved it at that point, and if you had a new journal task to take care of the new journal mailbox this would explain it, or it could have happened if you changed the Vault Store Partition to be after backup and then back to immediately after archive for the safety copies

In the case of an After Backup, it means that in the database it is now waiting for the items to be secured before it will begin post processing, so you'd have an item in your WatchFile table and your journalArchive table within the vault store database.

You can hack your way around importing a PST file in to a journal archive (either by stopping the journal task and changing the archive type to be a shared archive then do the PST import OR do a PST import through EVPM) however things such as DL Expansion, Random Sampling, custom filters etc will not be applied.

Your best bet is to see if the items are still in the J1 queue, determine why its not moving on the J1 OR have a look and see if theres an older J1 queue with the items stuck in them, and then use something like QueueExplorer to move them

But if i were youj, i'd export them to PST to clean up the mailbox and try and determines which ones haven't been archived and then use DocMessageClass to revert them to IPM.NOTE and put them back in the journal mailbox