Java Deployment for Enterprise
- To solve your security prompts issue: Use a Deployment Rule Set to whitelist internal utilities that are currently being blocked or causing Java to throw security warnings. Documentation here. The ability to sign JAR files with a trusted certificate is required. I use KACE K1000 for deploying and tracking rule sets as custom software inventory items, which requires the installation script for the rule set to create registry entries that KACE can read.
- Enable the Java usage tracker for versions that have implemented that feature (Java 7 and 8 free versions, Java 4, 5, 6 if you've paid for extended support) and use Splunk (if you have it) to track and analyze the data. Usage tracker documentation. How to use it with Splunk.
- Use the Java deployment.properties and deployment.config files to limit what Java Control Panel options end users can play with. Documentation here. The presence of these files will also prevent users from upgrading Java on their own.
- Initial deployment will be handled with a PowerShell script that removes existing JRE installations, replaces them with our standard deployment configuration, installs the rule set and configuration files, and enables usage tracking for all installed JREs.
- Keeping Java 8 up to date is handled with K1000 patching.
I don't want to go into too much detail, as there is a lot of configuration and setup that went into this project, but this should give you some idea of what you can do to manage Java in the enterprise without buying Oracle's expensive AMC option.