Video Screencast Help
Give us your opinion and win with Symantec! Please help us by taking this survey to tell us about your experience with Symantec Connect, so that we can continue to grow and improve.  Take the survey.

DCOM error 10009 - unable to communicate with the computer EVSITE

Created: 21 Feb 2013 • Updated: 22 Feb 2013 | 3 comments
GertjanA's picture
This issue has been solved. See solution.

Hello all,

I suddenly have this error in the System Event Log.

Event 10009 - DCOM was unable to communicate with the computer EVSITE using any of the configured protocols.

Anyone seen that before? we do not have an EVSITE computer, nor has it ever been used as an alias.

I verified that in the computerentry table there is no mentioning of the EVsite computer.

Thanks

Operating Systems:

Comments 3 CommentsJump to latest comment

JesusWept3's picture

and EVSite is not at the end of your archiveID's etc?
So if you do something like
SELECT TOP 1 vaultEntryId FROM Root

What does the GUID end with?

Chris Warren's picture

So, "EVSITE" is not in DNS?

Also, did you see this TECH article?

http://www.symantec.com/docs/TECH138624

So far, it looks like a DNS related issue with this Computername.

I hope this helps.

GertjanA's picture

Hello all,

As said the name EVSITE has not been used in this environment, ever. There is no server called EVSITE, nor is it (or has ever been) a site-alias.

We believe that the issue happened because of the following:

Last weekend, it was patching weekend. Windows patches have been rolled out, and servers restarted on schedule. Apparently after that reboot an additional DotNet patch was installed. Although there was no indication of a need to reboot, we did get issues with storing/retrieving items from users (slow, not happening etc), and also getting items for a DA case was very slow (like 1 in an hour). Initial investigations did not reveal any issues on the servers. Restarting services (as you do), did help 10 minutes. Further investigation showed that there were ASP errors in the systemlog. (100% of requests hung etc).

We then checked the reboottime (14:10 on sunday), and then found that the dotnet/asp folder had some later time. We rebooted the Journal Archiving servers (as they host no users) and that made the situation return to normal. This morning at 06:00 we rebooted the mailarchiving servers, and that resolved the issues also.

Thank you, Gertjan, MCSE, MCITP,MCTS, SCS, STS
Company: www.t2.nl

www.quadrotech-it.com

www.symantec.com/vision

SOLUTION