Which queue specifically?  If it is a5 that is mailboxes to be processed and it is normal to have some items in there at the end of the schedule.  It will pick up where it left off.

When you upgrade to EV 10 sp 2 or later you will have a nice archiving report created at the end of the run that you can reference.

TS

As tony said if its A5, don't worry about it,
One thing you can do is open up the queue message, scroll all the way down to the bottom and double click the last message, this will be your oldest message, look at the submit time for that message

If your archiving window kicks off at something like midnight, and it has a submit time of 2am, then it simply means that it re-queued the user for archiving but then ran out of time to get to that mailbox again.

So the way that it works is you have Number of Messages Per Pass set on the task, by default 1000 messages.....

1. The Schedule starts at midnight
2. Posts a message to A5 to Process Exchange Server
3. EV looks up all the enabled users for that exchange server
4. Posts a message in the queue for each enabled user
5. Each of those messages will have a submit time of midnight
6. EV will then take several at a time (default is 5 users or 5 concurrent connection)
7. EV then scans the mailbox and archives up to 1000 messages
8. EV then moves on to the next mailbox in the queue and so on and so forth until the queue is empty
9. Any mailboxes with more items to archive past those 1000 items will be re-added to the A5 queue
10. So if it took 1 hour to process all mailboxes at 1000 messages per pass, you may have additional mailboxes queued, and the submit time be somethng like 3:50am

Then your archiving schedule stops at 4am
Well the message is still in the A5 queue, because EV only had ten minutes to attempt to get to that mailbox and simply ran out of time

The A6 queue would be Moved/Updated Shortcut processing, and that will run throughout the day regardless of schedule to update the metadata in the ev database, so although you might come in in the morning and see 3000 messages in A6 queue, it will go down throughout the day.

Storage Archive and Storage Restore queues will also go down regardless of the schedule.
I believe A1 and A2 will still go down regardless of the schedule.....
None of the queues will move though if EV is in backup mode

Thanks guys.

Yes indeed, it's the A5 queue for each Exchange server's (we have four) archiving task. There are between 300 - 600 mesages in each. Seems to be exactly 4 messages in the A4 queues too. All others are 0. 

The number of messages per pass is set to 2000 and concurrent connections to 5.

What's stange is that the A5 contains mailboxes which don't even have 2000 messages in total in them (some only have 5 or 6 messages in total), so why would they be requeued? There are about 20 queue messages just called [1] too. 

All the messages have the same time of 4:20am, our archiving run is from 9pm - 6am, backup is afterwards.

Is that all normal?

Jumping in here: and, what about [2]?

Thanks JW for your (as always) thorough and clear explanation. But, this does also mean that at the start of the new scheduled run, these existing entries will first have to be processed, and then the newly added are being handled right? It is a sequential run if I am not mistaken.

Question of Alan on [1] and mine on [2], I believe it has something to do with a retry, but I am not sure. If Tony or JW know, please enlighten us :-)

You're right Gertjan, [1] [2] etc is a retry on fail count
Once it gets to three the mailbox is discarded and won't be archived against that archiving run

I still can't figure out why the queue contains mailboxes which only contain 5 or 10 mail items in total? If it can archive 2000 messages in one pass, why wouldn't they be picked up on the first pass?

Thanks for the help anyways. Much appreciated.

Because they're erroring out

So it Is something to worry about after all, if a few hundred normal mailboxes "error out" every single night?

Why would enabled, under-quota mailboxes with the correct perms not be archived? Is there a tech note explaining the reasons to look for please?

To be honest you'd have to DTrace it to see what's going on if nothing is being thrown in the event log

Typically they're soft or recoverable errors
Other times it can be that they're mailboxes moved from on exchange server to another but provisioning hasn't been run so it doesn't reflect the change, so you end up with these mailboxes in the wrong MSMQ etc

Gonna chime in here.  You have a variety of different errors..  I'll comment on a few of these generally:

Those top 2270's (Updating moved items in a folder.) and the 6578's are related.  Basically because something during the scan to determine if shortcuts were moved didn't pull the Retention category right (Note the folder retention category: []).

For these, look at the following:

http://www.symantec.com/docs/TECH156217
During Shortcut Processing to update Moved items, Event Ids 6578 and 2270 occur when 'Archive Exchange Managed Folders' is set to 'Off'

http://www.symantec.com/docs/TECH188048
Exchange Shortcut Processing is incorrectly identifying all mailbox folders as being moved

http://www.symantec.com/docs/TECH71905
Moved shortcuts are not updated correctly during archive task

For the 3432's, see the following forum post:

https://www-secure.symantec.com/connect/forums/eve...

The 6592's, you may want to open a case with Support on.

Finally, the last events you posted seem pretty self-explanitory due to corrupt or unreadable messages.

On a side, if a mailbox is over quota, that will affect Synch's as well as archiving, since EV must be able to update exchange objects to change messages class and such.  If Reads and Writes are denied, EV will have issues.

I hope this helps.

Thank you very much indeed Chris.

- For the 2270 and 6578 errors: I'm not quite clear. We only have the default "Business" retention category in EV and we don't use Managed Folders in Exchange (2003). We did create a "DoNotArchive" top-level folder in most users' mailboxes using EVPM - if users move or rename that folder, does it cause an error?

- The 3432 error doesn't appear to be happening anymore but I'll keep an eye on it and apply the reg hack if needed.

- The corrupt message error is being caused by a single message which was sent to all users. It has little text but the TO field contains a few thousand recipients. That means the message envelope is almost 1MB and EV can't seem to handle that. Should we tick the "set failed messages - do not archive" in the archiving policy? Does that need an associated reg hack? I think that's why our A5 queues are so long.

Thanks again.

Heya - Are you still experiencing errors from above?