Showing results for 
Search instead for 
Did you mean: 
Level 6
Partner Accredited Certified

In this article I will describe some of the general principles that you might employ when it comes to securing an Enterprise Vault environment. I personally don't think it's necessary to do everything in this article, it is more to give you an idea of the different aspects that can be considered. As with everything relating to software it is essential to thoroughly test the changes in a lab environment before making wholesale changes to a production environment which could impact users if there is a problem.


In an Enterprise Vault environment there are a number of shares which are created to facilitate the working of the EV server. Take a look at one of my lab machines:


Only one of these isn't related to Enterprise Vault (that's the last one).

So aside from the Admin shares ($ shares) there are several which are created by EV. If you take a look at the shares relating to partitions you will see that the are shared out to your Vault Service Account (with full control). This makes them pretty safe.

The only one with even slightly worrying permissions/sharing is the PST Holding Folder.  If you are doing PST migrations and want end-users to be able to use Client Driven PST Migration then the permissions on this share have to be quite relaxed. For this and many other reasons it might be a good idea to put this holding folder on a disk of it's own, which means that any kind of drop in disk space availability by users filling it up, won't affect the rest of the Enterprise Vault server.  In many ways it is a good idea to think through and separate out disk storage as much as possible on an Enterprise Vault server.



I would always suggest having as few people in the IT organisation as possible having direct access to the Enterprise Vault servers, particularly because this usually means that they need to know or have access to, the Vault Service Account username and password. Almost all administration in Enterprise Vault can be performed from a remote Vault Admin Console installation, with Roles Based Administration configured to give administrator accounts a good level of access to what they need to do. Doing things this way means that administrators can have their normal Windows account, and a separate Administrative account for working with Enterprise Vault. It's this second account that gets the permissions added to it via RBA.

There are several good articles which talk about RBA on the Symantec website including this one:

Often times with RBA it is quite time consuming to configure the different role levels, and it involves a lot of testing.  It is of course best to do all this testing in a lab environment before making any changes to you production environment.

Also included in Server security is of course the physical security of the server itself. In many security circles 'all bets are off' if an attacker can get physical access to the machine itself. For this and many other reasons carefully consider the physical security of the Enterprise Vault server, and other components like the SQL server, Exchange server targets, file server targets and so on.

Finally when it comes to the servers involved in the Enterprise Vault deployment itself, consider how Windows Updates will be applied to them. Will they be applied automatically, and immediately when they are released? Will there be a separate group of people or an individual who will test the updates in a lab first of all before deploying them on the production environment.



Securing client machine is a whole book in itself, never mind article, but one thing to consider in this area, which you might not think about, is whether or not users are allowed to override the archiving policy that they have been given. Users can do this if the Enterprise Vault Outlook Add-in is used to bring up the properties on a folder, and the 'change' button is used on the Enterprise Vault tab.


You might want to allow users to do this in which case everything is fine, but you might not. Sometimes users can get into hot water with this ability to change the policy. What they may do is to stop archiving of a folder, or subfolder, or whole hierarchy. This could be done by accident, which is likely to result in a support call at some point in the future to try and undo or figure out what the user has done. It can also be done purposely by someone that doesn't like having their mailbox archived for whatever reason. For those users they may just end up consuming some of their 'unlimited mailbox quota' or, if quotas in Exchange are in place, that too might lead to a support call.



Careful thought should be given to the types of policies which are deployed to users. There are many different questions which should be asked, such as:

  • Do you want to allow users to delete items from their archive?
  • Do you want them to be able to restore items back to their mailbox? 
  • Do you even want them to be able to manually archive items at all?  
  • Do you want to deploy virtual vault, but in more of a read-only capacity? 



How often backups can or should be performed and how best to do them is a whole article or two in its own right, so I will not go in to that here! But with backups consider the security of them. Where are the backups being made to? If it's to physical media, is that media taken off site after a period of time? How is the data retrievable? Who has access to the physical location where the backups are stored? And of course a super important one, are the backups tested from time to time?


Securing any kind of system takes a lot of time and effort, and it is almost a never ending task. Hopefully this article will have given you a little insight in to the sorts of things to consider when approaching an Enterprise Vault environment, and it's multiple components. Do you do any particular security related changes, or enhancements to deployments? Let me know in the comments below.


Version history
Last update:
‎11-20-2013 10:55 PM
Updated by: