cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted

Old emails not removed from Journal Mailbox?

I recently moved from an Exchange 2003 server to a new Exchange 2007 server.  After the move I had some issues getting Enterprise Vault fully working with the new mail server.  During that time, probably around 35,000 emails queued in the Journal mailbox.  Any new email that comes into the Journal mailbox gets archived and deleted within 5 minutes or so.  I can certainly live with that.

The problem is that 25,000 emails are still sitting in the Journal mailbox.  They don't get removed from the mailbox, ever.  I have done searches on the Journal archive and most of them seem to be in the journal archive, however at least one is not.  I don't know what my best bet would be in this instance.  Everything else seems to be working fine.  Should I export the problem emails to a PST and import them into the Journal to be safe and make sure everything is journaled or is there something I'm missing?

 

Thank you for any help you can offer.

1 Solution

Accepted Solutions
Highlighted
Accepted Solution!

Do NOT do a cancel operation

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

https://www.linkedin.com/in/alex-allen-turl-07370146

View solution in original post

3 Replies
Highlighted

What is the status of the

What is the status of the remaining emails?  Are they in a Pending status?  I don't believe you can export to PST and then import to a Journal Archive, as I recall you can't directly import to a Journal archive.

When you stop and restart the Journal task, are there any events in the event log?  You may need to run a Dtrace of the startup of the Journal task to see where the stoppage is.

Highlighted

Rather than exporting the

Rather than exporting the emails to PSTs, you might try opening the Journal mailbox in Outlook on the EV server using the Vault Service Account.  Select all of the stuck (older) pending items using and choose Tools->Enterprise Vault->Cancel Operation.  This will reset the pending items and they should then be archived normally.

Highlighted
Accepted Solution!

Do NOT do a cancel operation

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

https://www.linkedin.com/in/alex-allen-turl-07370146

View solution in original post