We have a brand new vault 8.0 SP1 on Windows 2008 server 64 bits. Everything has been working fine but except an intermittent small problem. Sometimes, when you do a manual archive, the item will turn into pending state in Outlook. After 10 minutes or so, the pending state item will turn into shortcut. During that time, I look at event viewer, I see event id 3310 that
There was a problem accessing a network service or resource. The dispenser will re-queue the current item and sleep for 10 minute(s).
Symantec provided me this article and told me to restart the task controller service once in awhile. While on the phone with Symantec, I restarted the task controller service, and it worked. The pending state item in Outlook turned into shortcut immediately and there was no problem with subsequent items. Symantec told me that there is no fix for it, and I'm not buying it. What do you guys think?
I actually restart the services on a scheduled basis. I think there is something to Symantec telling you to restart the service. Maybe you can add service restarts to your backup jobs, so things happen automatically? I've run into similar issues and restarting the task controller service did the trick. Good luck!
ok restarting the task is a workaround nothing more. The 3310 can be due to many causes gc lookups, mapi, networking and is not really a fault with ev. It is simply saying cannot process at this time and it will try again in 10 minutes. Restarting the task will simply mean it trust again there and then. You may find even that even a restart will not work100% of the time.
I personally would not accept this workaround though some people will and are happy with it.
How to troubleshoot then. Set up a trigger dtrace on 3310. See support site for technote. Beyond that further analysis with packet sniffing with things like ethereal may be necessary.
I am not actually familiar with your case but I do work in ev support at Symantec and would be happy to have a look over the case if you want to mail me the case ID direct.
Regards,
The Don.
***PLEASE REMEMBER TO MARK AS SOLVED IF YOU HAVE BEEN GIVEN THE ANSWER***
It is a patch and it could be a network issue between your EV server and your exchange system.
Don't accept that as the solution push the person in support you are working with to find the root cause. If need be insist on escalating the call to the back-line support
Restarting something periodically is bad. It shouldn't have to be like that. We've done a ton of work to improve things in the product, with more work still to come. So if you're "having" to do this, then we need you to work with our support folks to get to the bottom of the problem.
No, that is not a fix.. its a work around. Do not accept that as a solution, you will need to get to the bottom of it. I totally agree with Rob on this one.
Hi guys, I think that's almost the same with my problem too though not exchange but Domino is what we I have issue with. Support guy said that I should restart EV storage service daily and I don't agree with this. Still we one of the domino user accounts cannot archive manually, we are running Enterprise Vault 8.0 SP1. Can you help me on this? Thanks.
I was seeing 3310's all the time on one of my servers (Exchange mailbox archiving for 4 2007 servers) but never on the other one (archiving for 2 Exchange 2007 servers). Granted, one was a bit more busy than the other, but it was still puzzling. All the errors seem to have gone away after a support rep modified some Message Queue settings, specificially the "Limit message storage to (KB): 8388608" and the same value for Limit journal storage. I was assured this couldn't possibly have fixed the errors, but it did.
We had issues getting MSMQ installed on that server, though, so perhaps it was corrupt or something and modifying the settings reset something else, too.
We have a brand new vault 8.0
We have a brand new vault 8.0 SP1 on Windows 2008 server 64 bits. Everything has been working fine but except an intermittent small problem. Sometimes, when you do a manual archive, the item will turn into pending state in Outlook. After 10 minutes or so, the pending state item will turn into shortcut. During that time, I look at event viewer, I see event id 3310 that
There was a problem accessing a network service or resource. The dispenser will re-queue the current item and sleep for 10 minute(s).
Symantec provided me this article and told me to restart the task controller service once in awhile. While on the phone with Symantec, I restarted the task controller service, and it worked. The pending state item in Outlook turned into shortcut immediately and there was no problem with subsequent items. Symantec told me that there is no fix for it, and I'm not buying it. What do you guys think?
http://seer.entsupport.symantec.com/docs/290280.htm
We have a brand new vault 8.0
Hi Doctortt,
Could you confirm what version of Outlook and Service Pack Level you are running on the EV Server?
Regards
EVNoodles
If this reply has resolved your issue please mark this post as solved
Thanks for your time
EV Noodles
We have a brand new vault 8.0
I actually restart the services on a scheduled basis. I think there is something to Symantec telling you to restart the service. Maybe you can add service restarts to your backup jobs, so things happen automatically? I've run into similar issues and restarting the task controller service did the trick. Good luck!
Hi ok restarting the task is
Hi
ok restarting the task is a workaround nothing more. The 3310 can be due to many causes gc lookups, mapi, networking and is not really a fault with ev. It is simply saying cannot process at this time and it will try again in 10 minutes. Restarting the task will simply mean it trust again there and then. You may find even that even a restart will not work100% of the time.
I personally would not accept this workaround though some people will and are happy with it.
How to troubleshoot then. Set up a trigger dtrace on 3310. See support site for technote. Beyond that further analysis with packet sniffing with things like ethereal may be necessary.
I am not actually familiar with your case but I do work in ev support at Symantec and would be happy to have a look over the case if you want to mail me the case ID direct.
Regards,
The Don.
***PLEASE REMEMBER TO MARK AS SOLVED IF YOU HAVE BEEN GIVEN THE ANSWER***
I agree with The Don It is a
I agree with The Don
It is a patch and it could be a network issue between your EV server and your exchange system.
Don't accept that as the solution push the person in support you are working with to find the root cause. If need be insist on escalating the call to the back-line support
Liam Finn
http://www.computerusersolutions.com
http://www.enterprisevaultfaq.com
http://www.plymouthrocklodge47.com
http://www.plymouthrocklodge47.com/masonchat
Agree
Restarting something periodically is bad. It shouldn't have to be like that. We've done a ton of work to improve things in the product, with more work still to come. So if you're "having" to do this, then we need you to work with our support folks to get to the bottom of the problem.
Thanks
Rob Wilcox
EV Engineering Support
No, that is not a fix.. its a
No, that is not a fix.. its a work around. Do not accept that as a solution, you will need to get to the bottom of it. I totally agree with Rob on this one.
evdiscuss.net - bringing it all together
www.evtools.net - All your EV Tools
Restart EV Storage Service daily?
Hi guys, I think that's almost the same with my problem too though not exchange but Domino is what we I have issue with. Support guy said that I should restart EV storage service daily and I don't agree with this. Still we one of the domino user accounts cannot archive manually, we are running Enterprise Vault 8.0 SP1. Can you help me on this? Thanks.
John Optimus
I was seeing 3310's all the
I was seeing 3310's all the time on one of my servers (Exchange mailbox archiving for 4 2007 servers) but never on the other one (archiving for 2 Exchange 2007 servers). Granted, one was a bit more busy than the other, but it was still puzzling. All the errors seem to have gone away after a support rep modified some Message Queue settings, specificially the "Limit message storage to (KB): 8388608" and the same value for Limit journal storage. I was assured this couldn't possibly have fixed the errors, but it did.
We had issues getting MSMQ installed on that server, though, so perhaps it was corrupt or something and modifying the settings reset something else, too.
YMMV :)
Would you like to reply?
Login or Register to post your comment.