Estoy intentando configurar algunos ajustes de implementación reforzados para Java para las máquinas de los usuarios finales en mi red.
Tengo configurados mis archivos de configuración y propiedades de implementación en todo el sistema:
- % windir% \ Sun \ Java \ Deployment \ deployment.config (apunta al archivo de abajo)
- % windir% \ Sun \ Java \ Deployment \ deployment.properties
Para los fines de esta discusión, el contenido de deployment.properties es:
-
deployment.webjava.enabled=false -
# deployment.webjava.enabled.locked (commented out)
Mi objetivo es deshabilitar webjava de forma predeterminada y obligar a los usuarios finales a habilitarlo si es necesario. Luego, al reiniciar o la próxima carga, esperaría que el sistema volvería de forma predeterminada al estado desactivado. Sin embargo, he encontrado que una vez que el usuario lo habilita, a menos que el archivo de propiedades de implementación se modifique nuevamente, la configuración no se volverá a leer independientemente del reinicio, etc.
Me doy cuenta de que podría anular el comentario de este # deployment.webjava.enabled.locked (commented out) y estaría bien, pero el usuario final no podría modificarlo si fuera necesario.
Pregunta: ¿Alguien más ha tenido éxito con la configuración de webjava en sus ajustes de implementación cuando estoy intentando o tengo algún otro comentario con el fortalecimiento del jre para los usuarios finales?
Referencias:
ACTUALIZACIÓN: Brandon - gracias por tu aporte. Sí, tienes razón, esto es un trabajo alrededor. Podríamos establecer eso para que en el próximo gpupate (por ejemplo, inicio de sesión) la configuración vuelva a deshabilitarse. El panel de control de Java tiene un comportamiento extraño: si esta configuración de registro se establece fuera del panel de control, la próxima vez que se abra el panel de control, la configuración se leerá en otro lugar (? Configuración predeterminada en alguna parte que no conozco) y por lo tanto aparecerá como aquellos ajustes que todavía están 'habilitados'. De hecho, el registro se actualiza a "habilitado" (en virtud de la eliminación de la entrada del registro que hemos realizado) simplemente abriendo el panel de control y sin hacer clic en Aplicar o Aceptar. Un comportamiento extraño de hecho, pero supongo que todavía nos lleva a la meta deseada. Solo se requerirá un poco más de entrenamiento con los usuarios finales debido a la confusa visualización de la configuración en el panel de control. Pero, de nuevo, todo lo que estaba a punto de hacer hubiera requerido algún tipo de educación para el usuario final.