Hello Folks,
I am new to this forum, but not new to Enterprise Vault. I am not sure if this is the correct place to place this question/request. If it isn’t, I apologize in advance.
My goal is to get the assistance from the EV Product Team. I would like to see this escalated so it gets resolved. I have already gone through support and it appears they can’t do anymore as only EV Engineers can fix it.
Problem Definition
===============
Symptom: DCOM 10016 or 10015 Errors observed in Windows Event log.
Symptom: All errors point to the EV service account or EV processes not having sufficient DCOM permissions assigned.
Fact: Enterprise Vault Admin service resets DCOM permissions every time it is restarted.
Fact: Errors do not appear to “break” overall EV functionality.
Fact: Feedback from Tech Support is that this is “known issue” by the EV Engineering Group.
Fact: Due to perceived “low impact” (i.e. server not down) issue has not gained attention to become an escalation.
Fact: Customer’s confidence in the product going into a production environment is affected.
Fact: There are many customers out there having this issue (as per Support’s feedback & what I see in the Discussion groups).
Action: Replicated issue on three different environments with various EV versions.
Action: Used “SkipChecks” (EV 7) and “DoNotChangeAnonymousPermissions” Registry Keys (EV 5 & 6) but NO effect.
Action: Researched DCOM permission changes made by Microsoft in Windows 2003 SP1 and higher.
Action: Month-old Symantec Technical Support case open with no results or resolution (since December 11th, 2007)
Action: Followed all Symantec’s technotes outlining steps/suggestions to correct DCOM permission. For example:
http://seer.entsupport.symantec.com/docs/279588.htm
http://seer.entsupport.symantec.com/docs/284386.htm
Environment:
==========
Windows 2003 Enterprise SP1 and SP2
Enterprise Vault 7.0 SP1,
Enterprise Vault 2007 SP1, 2007 SP2
Errors in Event log:
==============
Event Type: Error Event Source: DCOM Event Category: None Event ID: 10016 Date: 12/15/2007 Time: 9:45:00 AM User: DOMAIN\EVSA_ACCOUNT Computer: ENTERPRISE_VAULT_SERVER Description: The application-specific permission settings do not grant Remote Launch permission
for the COM Server application with CLSID {562FF725-C308-11D1-93DA-0000F87A3C75}
to the user DOMAIN\ EVSA_ACCOUNT SID (S-1-5-21-2076772084-1888234209-63777028-948613).
This security permission can be modified using the Component Services administrative tool.
To replicate the problem:
===================
1. Follow any of the Symantec technotes and assign suitable DCOM permissions to the EV account and EV processes as required.
2. Restart EV admin service
3. Check DCOM permissions that were just set. They will be gone!
Current Status:
============
My colleagues and I have been troubleshooting and replicating this issue for the past month and followed Symantec technotes and/or suggestions provided by EV Technical Support. The technotes or suggestions are really useless because the Enterprise Vault Admin service wipes and resets the DCOM permissions when it is restarted. Due to the low severity of the support case (server is not down) and the fact that the issue has not been considered an actual problem to resolve; there has been no action or feedback indicating issue will be addressed. It is unknown when this will get corrected.
Comments:
=========
Our understanding is that Microsoft did in fact tighten DCOM access by removing the Anonymous account from the “Everyone” group, so as to move away from allowing Anonymous Logon access for security reasons:
http://technet2.microsoft.com/windowsserver/en/library/4c9a2873-2010-4dbb-b9dd-6a7d1e275f0f1033.mspx...
Microsoft’s suggestions to correct any of these DCOM permission errors indicate that you can:
- Add the account used by that program to the new group called “Distributed DCOM users” …or…
- Give the account or process that is identified by the error the necessary DCOM permissions.
*** However, due to the EV admin service resetting them, this would seem to be impossible to make stick for any length of time.
In our research to understand the problem, we saw that these errors are a common problem for a lot of other applications that rely on DCOM. In all the resolutions, they advise to set the DCOM permission manually for the account/process involved and the problem disappears.
I am confused why Symantec appears to be relying on still giving the Anonymous account the same DCOM permissions when Microsoft has moved away from this for security reasons. Our customers wonder why the Anonymous account is needed when a special dedicated account (EVSA) is being used to run the services and processes for EV to function.
Questions:
========
o Shouldn’t the EVSA account be given the appropriate DCOM permissions instead?
o Why is DCOM permissions hard coded into the service?
o Should we not have a choice between running a script (once!) and then do DCOM permission individually without losing them?
o Why are the registry keys specifically created to bypass the “checking/setting” of the DCOM permissions (“SkipChecks” for EV 7 & DoNotChangeAnonymousPermissions” for EV 5 & 6) NOT working?
o Why is the focus on the Anonymous account, when these errors are being flagged as attributed to the EVSA account and EV processes?
o Shouldn’t the DCOM permissions be set up correctly for the EVSA at minimum?
Please help! Thanks in advance!
Francisco.
