cancel
Showing results for 
Search instead for 
Did you mean: 

Do not apply default permissions to Exchange Mailbox archive

markchall
Level 2
When Enterprise Vault creates a Exchange mailbox archive, it automatically assigns the user of the mailbox Read, Write, and Delete rights on their archive. We have a desire to not have these permissions assigned to the mailbox automatically and to assign those permission manaully as needed. We are implementing EV as a compliance archive and not as a user facing archive. We are not using shortcuts and we are not deploying the client to the end-users. The only reason that end-users will need to get to a mailbox is for accessing terminated employee's mail by their manager. They will accomplish this through the web interface. Does anyone no how to stop EV from assigning these permissions? If a default user is required, we can specify the EV service account. Any help would be appreciated. Mark Hall
1 ACCEPTED SOLUTION

Accepted Solutions

GertjanA
Moderator
Moderator
Partner    VIP    Accredited Certified

Would journaling not be a better option:

As you say it is only for compliance, you might be better off using journalarchiving, and keeping that forever? This way, you can use DA to search mails if needed.

As for the permissions, as you do not deploy the client, your users cannot access the archive direct anyway. You could 'secure' the webpages called (search and archive explorer) to prevent users from accidently stumbling accross these pages.

And, as Karl says, the user will be synced automatically every time.

Regards. Gertjan

View solution in original post

6 REPLIES 6

KarlW
Level 6
Employee

There isn't anything to stop the synchronization of user permissions to a mailbox archive.

If you manually add the same permissions (Read, Write, Delete) as a DENY this should override the automatically synchronized permissions - basically disabling end user access.

Thanks

Karl

RahulG
Level 6
Employee

KarlW
Level 6
Employee

Whilst the script will remove the permissions it doesn't stop on-going synchronization of the permissions from the archive task back to the mailbox.  Therefore once performs a synchronize and archiving run the permissions will be synchronized back to the archive.

This would mean having to run the script daily for all active users (not deleted from AD).

-Karl

RahulG
Level 6
Employee

Yup KarlW thats true , synchornize the mailbox woud get the permission back.Archive permissions are automatically inherited from AD mailbox rights
These will need to be manually denied on the archive properties in order to prevent access to the archive.

GertjanA
Moderator
Moderator
Partner    VIP    Accredited Certified

Would journaling not be a better option:

As you say it is only for compliance, you might be better off using journalarchiving, and keeping that forever? This way, you can use DA to search mails if needed.

As for the permissions, as you do not deploy the client, your users cannot access the archive direct anyway. You could 'secure' the webpages called (search and archive explorer) to prevent users from accidently stumbling accross these pages.

And, as Karl says, the user will be synced automatically every time.

Regards. Gertjan

markchall
Level 2
Although it is not the most eligant solution, removing users from the ACL and replacing it with a AD group that has restricted members will work. We will have to also do the deny trick listed above if we do not want them to see their archive as well as the archive of the employee they are searching, but atleast this limits the amount of work. Thanks. On you first question, when I say compliance, I am talking about our legal mandate to not automatically delete things. End-users are required to make an informed decision on whether a piece of information is relevant for records retention. We are using archiving to move that data out of the mailbox and into a place the IT and legal people can access which lights the load on our exchange servers. It what we are terming soft grooming: The user thinks it is groomed, but in reality it is archived.