EV10 A6 and A7 queues not clearing down

[James_Slack]

Hi,

We have 2 Exchange servers and their A6 and A7 queues look as follows.

Server 1 A6 = 10336

Server 1 A7 = 420

Server 2 A6 = 7370

Server 2 A7 = 203

These queues do change a bit, but not much, they are pretty static.

I am mainly concerned about the A6 queues at the moment. Looking in Server 1s A6 queue I can see the same messages have been stuck in there for days (or weeks).

Archiving does actually seem to be working. Looking in mailboxes you would not know anything is wrong.

The reason I stumbled across these is I was running an import of some PSTs and a lot of them were failing. While that may be unrelated, it can't be right having 10k messages in an MSMQ.

What would I need to do to get messages flowing through the A6 queue.

Also, what does the A6 queue actually do? Is it simply updating the shortcuts in the Exchange Mailbox? Has an email already been vaulted and this is just updating the mailbox? What would happen if I deleted items in the A6 queue?

Thanks - James

[Arjun_Shelke]

A6 queue is used in moved items update operation. For example, if you move a shortcut of already archived email, from one folder to another within mailbox, then EV needs to update the the location of that item in archive of user.

Hence Archive Task checks the properties of shortcut and processes moved shortcut for location updates in A6 queue.

Most of the times, mailbox policy is set to update the retention category of moved items. I have seen issues when retention category change does not occur. If you can live with different locations of these 10k items in mailbox and archive then you can purge them, but its never recommended. So its better to investigate the cause, Dtrace ArchiveTask to know more..

I hope this helps..

[James_Slack]

Thanks, that makes sense.

I have been digging through the A6 queues and looking in to this more and think I have spotted something, though with your above info it now makes no sense.

In the A6 queue I can see a bunch of emails for users in one country we have been migrating. The address shown in the A6 queue might be wrong. These (in the A6 queues) look like X500 addresses. If that is the case, then looking at one of the users in question, then I can confirm that the user does not have this X500 address. It is different.

A6 = Exchange Admin group / user.name234

Exchange = Different Admin Group / User.Name

So, now I am confuesd.

What I guess may have happened is some of these users may have had mailboxes on our Exchange and their own. Then something was done to migrate these users in to our Exchange. Either a merge or a delete and creation of a new mailbox with the same name. I wont be able to find out, the person who did this no longer works for us.

What I am trying is adding the missing / shown in the A6 queue X500 address to the mailbox

Then running a sync and provisioning task and see if that clears that person from the queue.

[James_Slack]

Well, after what I thought was success, it seems that adding the X500s in has not helped.

Also, I can see loads of things queued in the A7 queue, including a few complete mailbox syncs I had queued up. These have been in there hours and nothing seems to have moved.

Can I delete the things in A7?

Thanks

[James_Slack]

OK, I have done some reading and deleted the A7 queues, so they are not a worry.

I have changed the archiving schedule for a bit so its not going to do anything new for the day. This has meant that the A6 queues are actually dropping now.

However. I notice a massive difference in speed between the 2 servers.

In the same time Server 2 has done 100, Server 1 only did 30.

Is there something that can be done to speed up the processing of the A6 queues?

Thanks

[James_Slack]

Still the same issues with 1 server. A6 queues cleared down on one server now. The other is running so slow, I expect a lot of this slowness is down to it retrying invalid items.

WIll do a DTRACE and see if I can find anything.

[James_Slack]

DTRACE log attached. This shows it trying to process messages stuck in the A6 queue.

These messages may be related to the email / PST migrations I have been having troubles with, they seem to be for users who we migrated - but they may not be as those users are archiving like normal users now.

Any help or advice would be greatly appeciated.

[James_Slack]

Actually, I think I may see the error.

It references UsedServerName = [VAULT.MENZIESWORLD.NL]

That is the old vault server, not my Vault server.

So, is the A6 queue trying to update somethng in the wrong Vault somehow? Is that even possible?

How would I find out?

How would I change it?

[Arjun_Shelke · Accepted solution]

Can you try following on affected EV Server:

HKEY_LOCAL_MACHINE\SOFTWARE\KVS\Enterprise Vault

Create a new Dword named 'UseLocalDirectory' and value = 1.

Restart the archiving task, perform Run Now on all affected mailboxes.

[James_Slack]

I can and will give that a go as soon as the current batch of PST imports completes in a couple of hours.

Before I do it, could I ask what it does please?

[James_Slack]

Nevermind... "Physician, heal thy self"

I did a search and found some info:

Stops Vault trying to talk to an external vault site basically (can't paste in this site) which sounds exactly like something we need right now, with importing one vaults data in to ours.

Thanks - will give this a blast asap.

[Arjun_Shelke]

I was offline for few days....did you manage to try it out?

[James_Slack]

Hi,

I did try it out and sadly it has made no difference.

The A6 queues for one of our servers are still super slow.

Last night they had got down to 6000, but today (during archiving) we are up to almost 9000 with 2 hours of archiving still to go. They will drop during the non-archiving times, but not to zero.

It seems about the same speed since the change and restart of the archiving task.

Not sure what to do to speed things up?

Thanks

[GertjanA]

James, can you run the associated archiving task in report mode for a day? This will allow the queues to be processed, without adding new data. This might help to clear out the queue.

[James_Slack]

I am not sure that I can at the moment. Would this affect .PST imports? I am on a major deadline to get these 1700 PSTs imported from our NL Vault and at the moment, I can't do anything that would slow or stop this process.

[GertjanA]

Hi James,

Running in report mode will not affect PST-import. Curious: NL as in Netherlands?

Did the queues go down in the end, or are they still higher as expected?

[James_Slack]

Once the imports had all finished, the queues fell away and are fine now.

I expect it was something to do with trying to restore shortcuts to the wrong place or something - but I really don't know. I think Advisors key helped with new stuff but there was a lot of old stuff stuck in the queues waiting to time out.

As we have finished our import of the Netherlands data, hopefully we wont need to do this again.

I never did run it in report mode as this import took about 8 weeks to run and we were expecting more like 2 weeks and we could not afford any more time.