Video Screencast Help

Old messages not archived

Created: 12 Feb 2014 • Updated: 20 Feb 2014 | 7 comments
This issue has been solved. See solution.


We are using version on Windows 2012 server.

Every user in Outlook has a folder in which they can drop items that are archived overnight. After our migration from version 9 to version 10, I noticed that the script that overruled the default policies wasn't activated on the new server. Now I notice that all items that have been moved to this folder since the migration, until I reactivated the EVPM.exe script, are still in this folder in Outlook and they get not archived.

How can I ensure that also these items are processed? I am looking for an automated/central solution, as we are not going to ask all our users to drop is again in the folder to trigger the archive process. We are required to use the archive bit option as all items need to be on backup before they can be replaced by a shortcut in Outlook. It would not be a surprise to me if this had anything to do with it.

This are the parameters that we submit to the EVPM.exe:


DistinguishedName = /o=Company/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=User 1
DistinguishedName = /o=Company/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=User 2
DistinguishedName = /o=Company/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=User 3
DistinguishedName = /o=Company/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=User 10

name = filter1
CreateShortcut = true
DeleteOriginal = true
unreadMAIL = true
UseInactivityPeriod = true
InactivityUnits = days
InactivityPeriod = 0

name = \EV-Archives
filtername = filter1
OverrideArchiveLocks = true

Any idea?

Thank you!

Operating Systems:

Comments 7 CommentsJump to latest comment

Rob.Wilcox's picture

So try with one user, reapplying the EVPM ...  and then do a run now on the mailbox archiving task for that user -- and see what happens. You could also capture a DTRACE and see if you can see what is happening via that.

WiVM's picture


I have already done that. But I have the impression that when I do so that the default policy is applied rather than the specific filter as set in the ini file. How can I ensure that the archive task submitted to EVPM is executed?

Rob.Wilcox's picture

Well you've got a few different options:


b/ Take a look at the folder using the Outlook Add-in, and open the properties page, and then the EV tab.. see what that says.

c/ The archiving report for the mailbox archiving task might also say what it has done on that folder... not sure, and don't have one handy to check.

Also remember EVPM is *not* submitting an archive request, simply applying a policy.

WiVM's picture

I did notice a lot of DCOM errors in the system log while running the Archive Tasks. This started a few days ago. I have resolved them by running the FileReRegister.bat and a reboot.

In DTrace I get these errors now:

3591370       13:56:06.122  [8464]       (ArchiveTask) <9036> EV:H   :CArchivingAgent::ProcessUser() |Archive/Journal Task ignored a Process Mailbox Message because the Process Mailbox mutex was locked and the mailbox is being processed by another thread |

3591371       13:56:06.122  [8464]       (ArchiveTask) <9036> EV:L       {AgentMessageDispenser::ActivateObject:#3560} An archive folder request could not be carried out because the mbx was locked on another operation [ARCHIVING_E_ARCHIVEFOLDER_MAILBOX_LOCKED (0xc0040b63)], so aborting the current msg and reposting to the back of the msg queue without incrementing it's retry count.

3591372       13:56:06.122  [8464]       (ArchiveTask) <9036> EV:L       {AgentMessageDispenser::ActivateObject} (Exit) Status: [The dispenser will abort the current item being processed, the item will be requeued for later processing      (0xc00408e6)]

3591373       13:56:06.122  [8464]       (ArchiveTask) <9036> EV:M       {AgentMessageDispenser::ProcessNextMessage:#1032} It took [0.014430] seconds to process the [MsgID_ArchiveMailboxEx3 (91)] MSMQ message body (ActivateObject). Processing the message [failed].

3591374       13:56:06.122  [8464]       (ArchiveTask) <9036> EV:M       {AgentMessageDispenser::ProcessNextMessage:#1278} AGENTS_E_DISPABORTITEM. Agent will sleep and abort the the current MSMQ transaction.

3591375       13:56:06.122  [8464]       (ArchiveTask) <9036> EV:L       {AgentMessageDispenser::ProcessNextMessage:#1521} Committing MSMQ transaction.

3591376       13:56:06.122  [8464]       (ArchiveTask) <9028> EV:H       {AgentMessageDispenser::ProcessNextMessage:#1013} Retrieved a [MsgID_ProcessMovedItemsInFolder4 (89)] MSMQ message on queue [EVPRD01\Private$\Enterprise Vault Exchange Mailbox Task for MBXPRD01 140213112233 A6] and it's retry count [0] is within retry limits.

I have already recreated the Outlook profile and also recreated all archive tasks so new MSMQ queues are created.

Any idea?

GabeV's picture

Hello WiVM,

The items moved to this EVPM folder, are regular emails or Enterprise Vault shortcuts? Looking at the dtrace entries you posted, there is only one thread [8464] and it's pulling messages from the A6 queue

3591376       13:56:06.122  [8464]       (ArchiveTask) <9028> EV:H       {AgentMessageDispenser::ProcessNextMessage:#1013} Retrieved a [MsgID_ProcessMovedItemsInFolder4 (89)] MSMQ message on queue [EVPRD01\Private$\Enterprise Vault Exchange Mailbox Task for MBXPRD01 140213112233 A6] and it's retry count [0] is within retry limits.

The A6 queue is used for: "Requests to update folders with items that have been moved inside a mailbox" (TECH164832). if you are moving regular emails, then you are looking at the wrong queue, because this queue is used for shortcut moved from one folder to another.

Also, you need to confim in the dtrace if there is another thread trying to process the same message and/or mailbox. That would explain these entries in the dtrace. Can you post the entire dtrace and let us know what is the mailbox you used for the test?

“Success is not final, failure is not fatal: it is the courage to continue that counts.”–Winston Churchill

Rob.Wilcox's picture

I would suggest exploring the other options from the list above.

WiVM's picture


The issue has been resolved. I enabled the registry key ContinueOnMissingItemErrors.