我们遇到的具体问题包括：
> Java拥有自己的更新程序,因此它不会与我们的内部补丁管理系统绑定.
>缺乏通过GPO管理Java设置的任何工具.
>要求用户手动配置某些设置.
>每台机器上有多个Java运行时(Oracle Jinitiator是这里的一个特殊罪魁祸首).
>存储在Program Files文件夹下的关键设置文件.
与我们一起,它主要是一批登录脚本和hacky解决方法,但我有兴趣听听其他人如何处理这些项目,如果有任何其他事情需要在这里注意.
我已经将Java运行时环境版本部署了几年,作为组策略中的软件安装分配.我禁用更新程序功能作为MSI的转换,并根据需要通过强制升级部署更新.如果机器需要保留较旧的JRE(因为某些应用程序需要它),我使用安全组来防止机器接收更新的升级. (幸运的是,我没有经常这样做.)
我使用Microsoft的Orca工具为Sun的MSI构建转换.拥有像Adobe的“自定义向导”这样的工具可能会很不错,但我可以用Orca做我需要的一切.
我没有机会让用户“手动配置某些设置”,但我会用两种方式处理它.如果某些用户需要一些与“规范”不同的设置,我要么部署一个组策略“首选项”来设置该设置(假设它在注册表的用户部分中),或者管理模板更改设置(假设它在注册表的计算机部分).如果要求允许用户按需更改设置,我会勉强改变注册表上的权限,以允许用户(实际上是包含用户的安全组)这样做.勉强.
如果一个应用程序需要自己的JRE,我倾向于将该JRE的安装与部署应用程序的脚本/ GPO联系起来,并将两者作为一个单元处理.这是我能想到的最简单的处理方式.
我很难回想起“程序文件”下的设置,但我不情愿地授予包含需要修改这些设置的用户帐户的安全组的权限,如果需要的话.我可能也会抓住我的头,诅咒太阳.
在Sun将他们的行为放在一起之前：JRE的企业部署和管理,我认为我们所有人都可能会采用hacky变通方法来处理它.这令人沮丧,但遗憾的是很典型.似乎绝大多数开发人员都没有关于做系统管理员工作的概念. <叹息>
