Comment gérez-vous Java dans votre environnement Windows / Active Directory?

Comme je suppose que beaucoup de gens, nous avons un environnement Windows / Active Directory et de nombreuses applications internes qui nécessitent Java. D'après notre expérience, Java ne joue pas bien dans un tel environnement de réseau d'entreprise. L'installation initiale est très bien (au moins il y a un MSI de nos jours), mais garder les choses en marche peut être un défi.

Les problèmes spécifiques que nous rencontrons incluent:

• Java a son propre programme de mise à jour, et il n'est donc pas lié à nos systèmes de gestion des correctifs internes.
• L'absence d'outils pour la gestion des paramètres Java via les GPO.
• La nécessité pour les utilisateurs de configurer manuellement certains paramètres.
• Plusieurs exécutions Java sur chaque machine (Oracle Jinitiator est un coupable particulier ici).
• Fichiers de paramètres critiques stockés dans le dossier Program Files.

avec nous, il s'agit principalement d'un lot de scripts de connexion et de solutions de contournement hacky, mais je suis curieux de savoir comment les autres gèrent ces éléments, et s'il y a d'autres choses à surveiller ici.

Pour parler de chacune de vos préoccupations:

Je déploie des versions d'environnement d'exécution Java depuis quelques années maintenant en tant qu'affectations d'installation de logiciels à partir de la stratégie de groupe. Je désactive la fonctionnalité de mise à jour en tant que transformation du MSI et déploie des mises à jour, si nécessaire, via des mises à niveau obligatoires. Si les machines doivent conserver un ancien JRE (car certaines applications l'exigent), j'utilise des groupes de sécurité pour empêcher les machines de recevoir des mises à niveau plus récentes. (Heureusement, je n'ai pas eu à le faire fréquemment.)

Je crée des transformations au MSI de Sun en utilisant l'outil Orca de Microsoft. Il serait peut-être bien d'avoir un outil comme "l'assistant de personnalisation" d'Adobe, mais je peux faire tout ce dont j'ai besoin avec Orca.

Je n'ai pas eu l'occasion pour les utilisateurs de "configurer manuellement certains paramètres", mais je le gérerais de deux manières. S'il s'agit de certains utilisateurs ayant besoin de paramètres différents de la "norme", je déploierais soit une "préférence" de stratégie de groupe pour définir ce paramètre (en supposant qu'il se trouve dans la partie utilisateur du registre), soit un modèle d'administration. pour modifier le paramètre (en supposant qu'il se trouve dans la partie ordinateur du registre). S'il est nécessaire que l'utilisateur soit autorisé à modifier le paramètre à la demande, je modifierais à contrecœur les autorisations sur le registre pour permettre à l'utilisateur (vraiment, un groupe de sécurité contenant l'utilisateur) de le faire. À contrecœur.

Si une application nécessite son propre JRE, je serais en mesure de lier l'installation de ce JRE au script / GPO qui déploie l'application et à traiter les deux comme une unité. C'est la façon la plus simple à laquelle je peux penser pour y faire face.

J'ai du mal à me rappeler quels paramètres vivent sous "Program Files", mais j'accorderais à contrecœur la permission à un groupe de sécurité contenant des comptes d'utilisateurs qui doivent modifier ces paramètres, si cela était nécessaire. Je tiendrais probablement aussi ma tête dans mes mains et maudirais le soleil.

Jusqu'à ce que Sun agisse ensemble sur le déploiement en entreprise et la gestion du JRE, je pense qu'il est probable que nous aurons tous des solutions de contournement pour le gérer. C'est frustrant, mais malheureusement typique. Il semble que la grande majorité des développeurs n'aient aucune idée de ce que c'est que de faire un travail d'administrateur système. <soupir>

Nous avons en fait dû gérer de nombreuses applications tierces (java incluses) et leurs mises à jour également.

Nous avons décidé en tant qu'organisation d'intégrer Ninite comme solution. Visiter le site et exécuter la version gratuite fonctionne très bien pour une configuration unique sur n'importe quel PC, mais, lorsque vous passez Pro sur ninite, vous obtenez également Ninite One dans le cadre de votre abonnement. Ninite one est quelque chose que vous pouvez exécuter à partir de la ligne de commande, en silence, pour déployer un bon nombre d'applications.

Je dévoilerai volontiers que nous sommes tous des PC, mais dans l'ensemble, nous sommes vraiment satisfaits de la solution.

Ninite One a des commutateurs de ligne de commande pour désactiver des choses comme les mises à jour automatiques et la création de raccourcis de bureau sur les mises à jour. C'est ce que nous avons fait et cela fonctionne plutôt bien. Cependant, il ne permet pas plusieurs versions de Java si c'est une exigence que je ne crois pas (mais je peux me tromper, je ne l'ai tout simplement pas testé)

J'ai une solution pour vous, bien qu'il s'agisse d'une solution commerciale, mais vous pouvez utiliser PolicyPak pour créer un objet de stratégie de groupe qui gérera presque tous les paramètres de Java. Ils ont un mode d'essai et des éditions en mode communautaire pour les essayer ou les utiliser gratuitement dans une capacité limitée. PolicyPak s'intègre à la stratégie de groupe Windows et vous permet de gérer et de verrouiller les paramètres de configuration des applications pour des applications tierces telles que Java encore plus efficacement que la stratégie de groupe standard verrouille les différents aspects de Windows. Le lien vers son Java Pak est ici http://www.policypak.com/products/manage-java-jre-with-group-policy.html et le lien vers les éditions gratuites est ici http: //www.policypak. com / support-partage / policypak-trial-community-edition-entièrement-sous-licence-modes.html .

Brad (employé de PolicyPak)