Event 4216 - Access denied. User is not in a role that allows 'Can manage Enterprise Vault Exchange Mailbox tasks'.

[pL0ck]

Hi There

I've been trying to track down the cause of this particlar warning. Every 5 minutes we get an event 4216

Access denied. User is not in a role that allows 'Can manage Enterprise Vault Exchange provisioning tasks'.

User: 'NT AUTHORITY\SYSTEM'

or

Access denied. User is not in a role that allows 'Can manage Enterprise Vault Exchange Mailbox tasks'.

User: 'NT AUTHORITY\SYSTEM'

Both from the Task Controller service. A snapshot of the DTrace shows

.

.

785 13:55:26.587  [17096] (TaskController) <7948> EV:M {CTaskControl::SynchRetrievalTask:#673} Not managing associated retrieval task for Task: [1FD634250F202E84E9281567A853D54AF1012000evserver1]
786 13:55:26.587  [17096] (TaskController) <7948> EV:L {CTaskControl::SynchRetrievalTask} (Exit) Status: [Success]
823 13:55:28.490  [17096] (TaskController) <10524> EV:L {CSecurityWrapper::HasServerClientGotPermission:#515} Checking role access for admin operation [4001]...
824 13:55:28.490  [17096] (TaskController) <10524> EV:L {CSecurityWrapper::IsServerClientTheVSA:#864} Checking if server client is VSA...
825 13:55:28.490  [17096] (TaskController) <10524> EV:L {CSecurityWrapper::IsServerClientTheVSA:#894} Client server is running as VSA: [False] (in a client COM call: [True]).
826 13:55:28.490  [17096] (TaskController) <10524> EV:L {CSecurityWrapper::CommonRoleAccessCheck:#920} Checking access for operation [4001]. Impersonating client: [True]...
827 13:55:28.490  [17096] (TaskController) <10524> EV:L {CSecurityWrapper::UpdateAzStoreCacheIfNecessary:#1455} Updating if required...
828 13:55:28.490  [17096] (TaskController) <10524> EV:M {CSecurityWrapper::CommonRoleAccessCheck:#997} Access [denied]
829 13:55:28.490  [17096] (TaskController) <10524> EV:L {CSecurityWrapper::HasServerClientGotPermission:#557} Caller [doesn't have] role [4001]. Permission [denied].
830 13:55:28.490  [17096] (TaskController) <10524> EV:L {CSecurityWrapper::GetOperationNameFromID:#656} Getting name of operation [4001]...
831 13:55:28.506  [17096] (TaskController) <10524> EV:M {CSecurityWrapper::ServerClientCheckPermissions:#1567} Operation [Can query Enterprise Vault tasks (4001)] has been denied.
832 13:55:28.506  [17096] (TaskController) <10524> EV:L {CSecurityWrapper::HasServerClientGotPermission:#515} Checking role access for admin operation [66]...
833 13:55:28.506  [17096] (TaskController) <10524> EV:L {CSecurityWrapper::IsServerClientTheVSA:#864} Checking if server client is VSA...
834 13:55:28.506  [17096] (TaskController) <10524> EV:L {CSecurityWrapper::IsServerClientTheVSA:#894} Client server is running as VSA: [False] (in a client COM call: [True]).
835 13:55:28.506  [17096] (TaskController) <10524> EV:L {CSecurityWrapper::CommonRoleAccessCheck:#920} Checking access for operation [66]. Impersonating client: [True]...
836 13:55:28.506  [17096] (TaskController) <10524> EV:L {CSecurityWrapper::UpdateAzStoreCacheIfNecessary:#1455} Updating if required...
837 13:55:28.506  [17096] (TaskController) <10524> EV:M {CSecurityWrapper::CommonRoleAccessCheck:#997} Access [denied]
838 13:55:28.506  [17096] (TaskController) <10524> EV:L {CSecurityWrapper::HasServerClientGotPermission:#557} Caller [doesn't have] role [66]. Permission [denied].
839 13:55:28.506  [17096] (TaskController) <10524> EV:L {CSecurityWrapper::GetOperationNameFromID:#656} Getting name of operation [66]...
.

.

It appears to be the same problem as

https://www-secure.symantec.com/connect/forums/ev10-event-4216-access-denied-user-not-role-allows-ca...

I've gone though many posts and done the DCOM config for the VSA. Reentered the VSA password, all without any success. It was an error we saw on 10.0.3 and since then we have moved to new server hardware so migrated everything across and also updated to 10.0.4 CHF3 and the problem has followed us. This is a production system so a bit hard to rebuild as in the above forum entry.

I have rebuilt a test environment (10.0.3 then upgraded to 10.0.4 CHF3) and I see than same thing there.

Just not sure to look next as I can't see anything that uses the SYSTEM account.

Everything appears to work though so it is more of an annoyance than anything.

Cheers

Peter

[SYMAJ]

Peter,

Did you resolve this issue ?  I have exactly the same problem on a 10.0.4 system.

Thanks,

AJ

[SHI-CRO]

Just a shot in the dark here, but is your MSMQ service running using those credentials?  If so, you might try changing it to run under the local account (I think it's supposed to be that way anyway).
 

[pL0ck]

Hi All

Seems the only way I could resolve this was to add SYSTEM to the EV Administrators group in Authorization Manager. Not sure if it the right thing to do but seems to be working.

Cheers

Peter

[GertjanA]

I've also seen this in a Lab environment, and added the System account. It might be SCOM agent (monitoring the EV-tasks), or the backup client (both of which seem to run under the system account)

In our production environment, I do not have these, as we have defined SCOM account, and Backup account within EV.