Como você gerencia o Java no seu ambiente Windows / Active Directory?

Como suponho que muitas pessoas, temos um ambiente Windows / Active Directory e muitos aplicativos internos de negócios que exigem Java. Nossa experiência é que o Java não funciona bem em um ambiente de rede corporativo. A instalação inicial é boa (pelo menos há um MSI hoje em dia), mas manter as coisas funcionando pode ser um grande desafio.

Os problemas específicos que encontramos incluem:

• O Java possui seu próprio atualizador e, portanto, não se vincula aos nossos sistemas internos de gerenciamento de patches.
• A falta de ferramentas para o gerenciamento de configurações de Java via GPOs.
• O requisito para os usuários definirem manualmente determinadas configurações.
• Vários tempos de execução Java em cada máquina (o Oracle Jinitiator é um culpado específico aqui).
• Arquivos de configurações críticas armazenados na pasta Arquivos de Programa.

conosco, trata-se principalmente de um lote de scripts de logon e soluções alternativas de hackers, mas estou interessado em saber como outras pessoas lidam com esses itens e se há outras coisas que precisamos observar aqui.

Para falar com cada uma de suas preocupações:

Há alguns anos que implanto versões do Java Runtime Environment como atribuições de instalação de software da Diretiva de Grupo. Desabilito a funcionalidade do atualizador como uma transformação no MSI e implanto atualizações, conforme necessário, por meio de atualizações obrigatórias. Se as máquinas precisarem manter um JRE mais antigo (porque algum aplicativo exige), eu uso grupos de segurança para impedir que as máquinas recebam atualizações mais recentes. (Felizmente, não tive que fazer isso com frequência.)

Construo transformações para o MSI da Sun usando a ferramenta Orca da Microsoft. Pode ser bom ter uma ferramenta como o "Assistente de personalização" da Adobe, mas posso fazer tudo o que preciso com o Orca.

Não tive ocasião para os usuários "definirem manualmente determinadas configurações", mas eu lidaria com isso de duas maneiras. Se alguns usuários precisarem de configurações diferentes da "norma", eu implantaria uma "preferência" da Diretiva de Grupo para definir essa configuração (supondo que esteja na parte do usuário do registro) ou um Modelo administrativo para alterar a configuração (supondo que esteja na parte do computador do registro). Se for necessário que o usuário tenha permissão para alterar a configuração sob demanda, eu alteraria de má vontade as permissões no registro para permitir que o usuário (na verdade, um grupo de segurança que contém o usuário) o faça. De má vontade.

Se um aplicativo exigir seu próprio JRE, eu seria capaz de vincular a instalação desse JRE ao script / GPO que implanta o aplicativo e tratar os dois como uma unidade. Essa é a maneira mais simples em que posso pensar para lidar com isso.

Estou tendo dificuldade em lembrar quais configurações estão em "Arquivos de programas", mas concederia, de má vontade, permissão a um grupo de segurança que contém contas de usuário que precisam modificar essas configurações, se necessário. Eu provavelmente também seguraria minha cabeça em minhas mãos e amaldiçoaria Sun.

Até que a Sun ajude a re-implantação e gerenciamento corporativo do JRE, acho que é provável que todos nós tenhamos soluções alternativas para lidar com isso. É frustrante, mas infelizmente típico. Parece que a grande maioria dos desenvolvedores não tem noção de como é fazer o trabalho do administrador de sistemas. <suspiro>

Na verdade, tivemos que lidar com muitos aplicativos de terceiros (incluindo java) e seus atualizadores também.

Decidimos, como organização, integrar o Ninite como nossa solução. Visitar o site e executar a versão gratuita funciona muito bem para uma configuração única em qualquer PC, mas, quando você usa o Pro no ninite, também recebe o Ninite One como parte de sua assinatura. O Ninite one é algo que você pode executar a partir da linha de comando, silenciosamente, para implantar um bom número de aplicativos.

Com prazer divulgarei que somos todos PCs, mas, como um todo, estamos realmente felizes com a solução.

O Ninite One possui opções de linha de comando para desativar itens como atualizações automáticas e criar atalhos na área de trabalho. Foi o que fizemos e funciona muito bem. No entanto, ele não permite várias versões do Java, se esse é um requisito em que não acredito (mas posso estar errado, apenas não testei isso)

Eu tenho uma solução para você, embora seja uma solução comercialmente relacionada, mas você pode usar o PolicyPak para criar um GPO que gerencie quase todas as configurações no Java. Eles têm um modo de teste e edições do modo comunitário para experimentá-lo ou usá-lo em uma capacidade limitada de graça. O PolicyPak se integra à Política de Grupo do Windows e permite gerenciar e bloquear as definições de configuração de aplicativos de terceiros, como Java, com mais eficiência do que a Política de Grupo Padrão bloqueia os vários aspectos do Windows. O link para o seu Java Pak está aqui http://www.policypak.com/products/manage-java-jre-with-group-policy.html e o link para as edições gratuitas está aqui http: //www.policypak. com / support-sharing / policypak-trial-community-edition-full-licenced-modes.html .

Brad (funcionário da PolicyPak)