03-05-2013 02:16 PM
I'm using Enterprise Vault version 7.5 and I have the exact same scenario as: https://www-secure.symantec.com/connect/forums/removing-automatically-set-permissions-vaults-where-o... however in that thread I am unable to work out entirely what the solution was.
The original poster mentions:
"Enterprise Vault Policy Manager did not strip automatically set permissions on archives [Ref 801192, E1063349]
The Enterprise Vault Policy Manager did not strip automatically set permissions when you used the ArchivePermissions section in the initialization file. For example:
[ArchivePermissions]
ArchiveName=John Doe
Zap=True
These settings stripped only manually set permissions on John Doe's archive. They did not strip the permissions automatically inherited from the Exchange mailbox.
This has been fixed."
My scenario is the same in that I have attempted to use EVPM.exe to "zap" permissions from an archive. It seems to only work on manually set permissions and not on automatically inherited permissions from Exchange. The OP says "this has been fixed" but does not mention how it was fixed. Does anyone know if there is a solution?
Thanks for your time!
Solved! Go to Solution.
03-06-2013 09:53 PM
Below query wouldbe useful. Replace the archvie name and make sure you take a backup of the directory database before running the query .
Use EnterpriseVaultDirectory
update archiveview
set AutoSecurityDesc = NULL
where archivename = 'ABC'
Close Enterprise Manager or SQL Management Studio
Refresh the Enterprise Vault Admin Console and check the automatically set permissions on the archiv
03-06-2013 06:14 AM
Well you can do the other way round , by just adding everyone as a deny permission from Vac.
03-06-2013 06:25 AM
And if you dont want Inhertited permissions, you can disable them from policy advanced section.
03-06-2013 06:56 AM
I could be wrong but i think the workaround was [VaultPermissions] and not [archivePermissions]
You could always just manually remove them from sql too if you wanted
03-06-2013 03:12 PM
Yes you could, but this is really a workaround and not a solution. This would still leave us with a list of redundant entries in the user permissions and is messy. A majority of our user vaults only have that user's account listed in the permissions which is correct however my goal here is to clean up and fix the other user vaults which look like the screenshot in my original post.
03-06-2013 03:12 PM
The policy already has inherited permissions disabled. This is the problem.
03-06-2013 03:15 PM
[VaultPermissions] appears to be legacy from EV 1-4.x
I did however try it but it made no difference. I can tell that my zap ini is targeting and "zapping" the correct user account as manually added permissions get zapped correctly when I run EVPM. The problem is that inherited permissions (which should not be inheriting as I have them disabled in my policy settings) cannot be zapped and remain in the user's vault permissions.
03-06-2013 09:53 PM
Below query wouldbe useful. Replace the archvie name and make sure you take a backup of the directory database before running the query .
Use EnterpriseVaultDirectory
update archiveview
set AutoSecurityDesc = NULL
where archivename = 'ABC'
Close Enterprise Manager or SQL Management Studio
Refresh the Enterprise Vault Admin Console and check the automatically set permissions on the archiv