This content has been marked as final. Show 7 replies
I haven't tested this myself, but it looks like you're doing it right per the documentation:
I've instead relied on registry keys to configure this setting:
I know that, but it is a setting per user and it does not default to the installation setting.
I wonder what the installation option is doing. It is not setting the default (for existing users at least), it
does not lock the setting either. So any user can change the setting at will.
I can add the registry key for all users using a logon script, but I could have done that anyway.
Hence my question.
Anyway, the issue seems to have solved itself because Oracle has changed the default to be H in Update 11.
However, the question itself remains open.
I understand why you asked the question: It doesn't appear to be working as designed. ;)1 person found this helpful
I offered up what little I know in hopes of helping you solve the immediate problem of applying that setting. I wasn't trying to dance around the problem. :)
You are correct: it is a per-user setting. There are still a number of ways of getting per-user settings that out there:
- Via login script, as you suggested;
- Via GPO - Push the registry key(s) in this example;
- Via installs - add the registry key as part of the installation to HKCU; for any new user profiles: load the default user hive, add the key there & unload the hive. New profiles from that point on will be updated. You'll still need to do something for existing profiles. (Use one of the two options above for that.)
You added a new twist on this by mentioning a new element: the ability to lock the setting(s) so that users cannot change them. You'll likely need to leverage deployment configuration files to accomplish this. I don't think registry keys apply here, but I could be mistaken. Once the 'master' files are configured properly, they can be deployed via GPO, login script and even new installs.
Take a look at the documentation here, and if you still require some assistance, check back in.
The issue hasn't really 'solved itself' since users can still change the security level. The above will address that.
Thanks for the info about deployment properties. I can probably put that to useful use.
Java Control Panel uses deployment.properties to set the value in registry. So changing the value in registry does nothing.
Set the value deployment.security.level=VERY_HIGH (or you're chosen security level) in deployment.properties, and make sure that both deployment.properties files are written:
<User Application Data Folder>\Sun\Java\Deployment\deployment.properties
If you want to enforce it you probably have to set this through GPO. Logonscript would only set it once per logon.
Indeed I found that changing the registry does nothing. Changing security level requires editing the deployment.properties file.
What a mess... settings in a plain text file, with policy and installation info intermixed.
How is one supposed to manage this?
I had hopes that I could deploy some security settings in a managed environment, but for now I think I'll just follow the
route that more and more people are recommending: uninstall the whole thing and forget that it ever existed.
Interesting. You're saying it writes it out to a file, which governs all the settings, then writes it to the registry? Then I have to ask: What's the point it writing to the registry, if that's not used?
(I don't expect an answer but I'll take it if you got it!)
I must've really botched my environment because I was 100% certain that registry key was working! I'll do some more testing later with fresh machines & two different users.
In the mean time, the deployment.config process does work as we're looking to set & lock some settings.
Note*: I'm pretty sure you can use backslashes, but they'll probably need to be escaped. So \\server\share\file would become \\\\server\\share\\file.
deployment.security.level=VERY_HIGH deployment.security.level.locked deployment.webjava.enabled=true deployment.webjava.enabled.locked