Vault Cache and Virtual Virtual
From my experience in the field, it is a very popular feature. The end users *love* it. There are some challenges but my experience has been that customers who identify the challenges in advance and plan around them have very smooth and successful rollouts.
Some things you may wish to consider:
-As you mention leaving archive data on the end user machine, the cache itself is a local copy of the online archive. Some companies have security policies that prevent this kind of data being stored to the local machine so you would want to ensure this does not violate any such policies in your company.
-The cache is required in order for Virtual Vault to be visible; you can choose to sync only the archived item metadata in order to reduce the space and bandwidth requirements but many users don't like this, as the client still needs to go to the EV server to fetch anything they wish to view, and the optional integration with Windows Desktop Search would be limited to just the metadata (users couldn't find the content in their WDS searches if you only sync the metadata).
-The initial sync can take a bit of time, and "how much time" depends on various factors such as your network bandwidth, average archive size, and server/client horsepower. Some customers choose to sync only the most recent year or two of data to combat the potential issues faced when a user has a massive archive, or to restrict the amount of space the cache is allowed to consume on the workstation. Review the policies carefully and see which restrictions, if any, would best suit your environment
-When a user performs manual archiving via Virtual Vault drag-and-drop, the only copy of the data is removed from exchange straight away but is not written to the EV server until the user performs a sync. So there is a narrow window of time where a workstation permanent failure or a cache reset can cause the data to be lost. Because of this, some customers choose to NOT allow drag-and-drop archiving via Virtual Vault, and allow users to rely on the nightly archiving tasks doing that job
-In more recent versions, you can configure your Desktop policy to trigger a sync after the user has manually archived X number of items or X mb in size; this is a great help but be cautious to not set the value too low; forcing a sync after every 1 item dragged to the Virtual Vault could bring some unwanted side effects such as frequent occurence of Server Busy messages as the finite number of sync slots are constantly all consumed.
-If you choose to allow drag-and-drop archiving, it tends to be very popular when the users first see it. It's not at all uncommon to see users dragging entire PST's into the archive. This can cause performance issues on the server, in the same way that a user doing a Store In Vault on 10's of thousands of mails would. So you should roll out gradually and monitor the server performance as you continue to roll out to more users
These are not con's --- they are just things you have to consider as you introduce any new technology and potentially change the way the users interface with large amounts of data. Keep in mind that the VC/VV rollout is essentially calling a massive amount of data which has been at rest for a long time, and pushing it through network pipes that may not be scaled for that amount of traffic, so a gradual rollout is a must.
The pro's are that users Love Love Love the interface, and providing offline access for folks who travel is a huge feature. The interface itself is familiar to the users, so little training is required (although you may want to spin up an intranet FAQ page for your users that explains your policies and rules as well as how to use the tool).
Excellent whitepaper here http://www.symantec.com/docs/TECH75381
There are also some challenges when it comes to providing the VV to Citrix-based users. I am not 100% sure but that may still officially be an unsupported configuration, but regardless, if you have a large number of virtual desktop based users, then a separate discussion on that matter is probably in order.
