Hello Mkimler,

The registry key should be working for any user logging in, provided you assign the registry key to be set via a GPO.

If you have a seperated OU showing only laptops, and one for desktops, you could use that info to set (or not set) the Vault Cache.
The key (btw) is not available on HKLM.

If yu search the forum, you will see that this is an issue more people have. You could use WMI to determine the machinetype, then set the registrykey (or not)

Good luck.

Gertjan

MKimler,

Vault Cache is a per user setting.  I ran into your scenario at a client last year and this is definitely a limitation of the product.  Here's the possible work arounds:

1. On the desktop PCs do NOT enable Outlook cache mode.  No cached mode SHOULD mean no VC however in practice I found this to be hit or miss for some users (disclaimer: I have not tested VC with this issue).  Even though it is not supported if the EV registry keys have been set (in my case roaming profiles were in use) then the Offline Vault would enable itself regardless of cached mode status.

2. Use a logon script that sets the OVEnabled key as needed.  This is the best solution we could find and it works but does require some logic in the script to differentiate desktop and laptop.

-Joe

Errr

Why can you not modify the EV desktop policy to disable vault cache and then sync all mailboxes. 

Job Done...

HTH

PJuster is right. The settings are there in policys now so customers don't have use reg hacks.

I belive the use case here is the fact they cannot easily distinguish desktop users from laptop users, hence wanting to put a registry key on the desktop.  Also, it can be the scenario where users have a Desktop and a Laptop and they only want Vault Cache to be able to be enabled on the Laptop.

Hi,

you may create a new Desktop Policy and disable Cache in Vault Cache tab. then you need to add a particular users in Target Tab

Regards
Kesavan

All,

My understanding of his situation:  One user has a desktop computer AND a laptop with Outlook and EV Add-on installed on both machines.  In this scenario VC is either on or off for both machines as it is a user level setting.  My suggestions were to assist in over coming this limitation which I ran into.  

At my client security policy stated no data should be stored on unencrypted hardware.  The laptops had boot level encryptions but the desktops did not.  My original hope was that the laptops would enable OV as they were running Outlook cached mode (a pre-req for OV\VC) and the desktops would not.

-Joe

Thanks for all of the feedback. Sorry for not checking back in.

I think there are some good ideas here and it also seems to be an option that people want.

PJuster / The Don - The EV Desktop policy would then be a global policy change which I do not want. I only wish to disable the Vault Cache for desktop computers and not laptop computers. A global policy change will not be ideal. Thank you for the feedback though. (PS - PJ...telling the customer "Err" sounds like you think I didn't do my homework or I'm a dumba$$. That's probably not the best way a Symantec employee should reply to the customers but it's okay. I'm originally from NJ and can take it. :D.)

GertJanA - This is a good option to create seperate OUs, one for desktop and another for laptop, to break out the deployment of a script but we have a large organization and due to our medical organization structure, I cannot break down the OUs this way. However, it still requires us to manually manage the workstations and this can become extremely complicated in large organizations. Thank you for your feedback.

Joseph / Tony - Your understandings are correct. It must be assumed that a user would have possibly both types of machines. It should also be assumed that machine types will change constantly as time goes on. People going from laptop to desktop and vice versa. The scripting must be done based on the workstation level and not the user level. Joseph's first post, option 1 is a good start for new machines but I also need to address the current deployment which really is the main concern. As for Joseph's option 2, that's exactly what I would like to do but the key itself seems to have a dynamic identifier in it and I'm not sure how that could be done. Thank you both thus far.

Kesavan - This is another option but similar to Gert's ideal, instead of managing machines through Active Directory, I'm now manually managing them through Enterprise Vault. Good suggestion but it's not ideal for me. Thank you though.

Thanks for the suggestions thus far. I think the main question is this:

Is it possible to create an HKLM key, that contains no unique identifier, that disables the cache for all users on that particular machine?

You could probably do it in Group Policy as Gertjan suggest, but automatic, by using WMI Filter to find out if it's a desktop or a notebook computer.

http://www.microsoft.com/technet/scriptcenter/resources/qanda/sept04/hey0921.mspx

You can then target the User based on this...

Cheers
Michel

It is sounding like there is no global registry key that could be made to disable the vault cache for all profiles on a machine. It also looks like that the registry key is actually dynamic, unlike in version 7, further preventing a simple change to be scripted.

I have to script to first do the WMI filter, then further investigate the user's specific id key, and then actually make the value change.

Unless someone knows where I can place new OVEnabled value, or something similar, in HKLM or some other place in HKCU?

there is no easy way to get the key afaik. you could grab the key via mapi from the users hidden message (ipm.note.enterprisevault.offlinevault), the property is named "store id"

Thanks MichelZ

@Mkimler does this answer your question?

--wayne

That answer is probably the best answer. I also contact Symantec support on this matter and that's pretty much their conclusion as well. I will be putting in a feature request with my sales rep to hopefully get a better option to control vault cache and who gets it.

For the time being, I am going to have to set this up for new machines and have it manually changed to existing machines until I can determine a great way to roll it out.

Or the option is to just turn it off for everyone and leave it at that.

Thanks again for all of the posts and feedback. Good job to everyone that donated their knowledge.