Showing results for 
Search instead for 
Did you mean: 

Quick way to populate vault cache?

Level 6
Partner    VIP    Accredited Certified


Is there any quick ways to populate a users vault cache without having to synch over the network?

We have a single remote user with a very large archive that we want to enable for vault cache. The user is 'very' remote and can't get a fast link onto network so synching the vault cache over the slow link is simply not working. It's also not really an option for them to post their laptop to the office.

Can anything be done to export their archive to PST, send them the PST and somehow get the vault cache created using the PST file?

I think once the initial synch is done, we can use preemptive caching from their OST to keep the vault cache updated from then on.



Level 6
Partner    VIP    Accredited Certified

Would it perhaps be an option to create their vault cache on a local system in the office and then copy the vault cache files to a USB stick to send to them. They can then copy the contents of the USB to the correct vault cache location on their laptop?

Partner    VIP    Accredited Certified

Hi mate, I'm afraid that may not be possible. You can modify the default location of the Vault Cache both centrally from the EV server and on a per-user basis via the registry. See this article:

However, the Vault Cache must be completely rebuilt as changing the registry value does not affect any existing instance of the cache.

One instance when the cache is not sent over the network is when doing PST migrations using the client-driven method. In that case, the data is first added to the local cache then sent over the network to the EV server.


Level 6
Partner    VIP    Accredited Certified

Hmmm ok - thanks

I didn't think it would be a straight forward process. We wouldn't actually be changing the location of the offline vault and the cache header information synch's ok - it's just the content that takes too I was hoping just to be able to physcially copy the files from a locally created vault cache (or the specific user) from the vault cache locaton. I'm not sure what else (outside of these files) vault cache needs to be able to open an item?

I actually thought I read somewhere ages ago that vault cache is nothing more than a pst file anyway.

But what you say about the PST file migration may be worth persuing. I could potentially export the users archive to PST, send it to them, ask them to do a client driven migration (without creating shortcuts) and isn't there an option to get rid of any duplicate items from within the archive that the PST migration would create?

I'd recommend against the PST migration scheme, because the whole reason you're asking this question is the low bandwidth between the user and the server. PST migration is likely going to suffer the same problems as VC synch, just with the packets flowing in the opposite direction.

I'm actually pretty sanguine about the "build the VC locally and mail him a USB drive" approach. We don't have published steps and it's not officially supported (don't call in a case on this!), but it seems like it should work, and lab testing bears that out.

You'll want to enable and synch the VC on a workstation in your network. Then on that workstation copy the folder

%LocalAppData%\KVS\Enterprise Vault

It should contain all the Vault Cache files in a folder named with a GUID.

Send that folder to the user and have him place it in the same location.The tricky part is in the Registry, where the key

HKEY_CURRENT_USER\Software\KVS\Enterprise Vault\Client

has a subkey that is supposed to be named with the same GUID as the folder. Since your user has already enabled and tried to synch his VC, he will have a different GUID here in the Registry. You'll want to rename the copied folder to match the GUID from his Registry. Then restart Outlook and it should treat the copied VC files as its own.

There is also no reason you can't try this out in a lab between any two workstations to make sure you've got the process down before you do it for the remote user.

I hope that helps, and remember, this advice is provided as-is, no warranty, use at your own risk, don't call in a case, and test test test first!



Level 6
Partner    VIP    Accredited Certified

Brilliant - thanks Chris

I fully understand the 'no warranty' element to this, but it sounds worth a try.

I'll probably test first before creating the USB.

thanks again