Come gestite Java nel vostro ambiente Windows / Active Directory?

Come suppongo che molte persone, abbiamo un ambiente Windows / Active Directory e molte app line-of-business interne che richiedono Java. La nostra esperienza è che Java non funziona bene in un tale ambiente di rete aziendale. L'installazione iniziale va bene (almeno c'è un MSI in questi giorni), ma mantenere il ticchettio delle cose può essere una vera sfida.

I problemi specifici che incontriamo includono:

• Java ha un proprio programma di aggiornamento, quindi non si collega ai nostri sistemi interni di gestione delle patch.
• La mancanza di strumenti per la gestione delle impostazioni Java tramite oggetti Criteri di gruppo.
• Il requisito per gli utenti di configurare manualmente determinate impostazioni.
• Più runtime Java su ogni macchina (Oracle Jinitiator è un colpevole particolare qui).
• File delle impostazioni critiche archiviati nella cartella Programmi.

con noi è principalmente una serie di script di accesso e soluzioni complicate, ma sono interessato a sapere come altre persone gestiscono questi elementi e se ci sono altre cose a cui bisogna fare attenzione qui.

Per parlare con ciascuna delle tue preoccupazioni:

Sto distribuendo le versioni dell'ambiente di runtime Java da alcuni anni come incarichi di installazione di software da Criteri di gruppo. Disattivo la funzionalità di aggiornamento come trasformazione all'MSI e distribuisco gli aggiornamenti, se necessario, tramite aggiornamenti obbligatori. Se le macchine devono mantenere un vecchio JRE (perché alcune applicazioni lo richiedono), utilizzo i gruppi di sicurezza per impedire alle macchine di ricevere aggiornamenti più recenti. (Fortunatamente, non ho dovuto farlo di frequente.)

Costruisco trasformazioni per l'MSI di Sun usando lo strumento Orca di Microsoft. Potrebbe essere bello avere uno strumento come "Customization Wizard" di Adobe, ma posso fare tutto ciò di cui ho bisogno con Orca.

Non ho avuto occasione per gli utenti di "configurare manualmente determinate impostazioni", ma lo gestirò in due modi. Se si tratta di alcuni utenti che necessitano di impostazioni diverse dalla "norma", implementerei una "preferenza" di Criteri di gruppo per impostare tale impostazione (supponendo che si trovi nella parte utente del registro) o un modello amministrativo per modificare l'impostazione (supponendo che sia nella parte del registro del computer). Se è necessario che l'utente venga autorizzato a modificare le impostazioni su richiesta, modificherei a malincuore le autorizzazioni sul registro per consentire all'utente (in realtà, un gruppo di sicurezza contenente l'utente) di farlo. A malincuore.

Se un'app richiede il proprio JRE sarei adatto a collegare l'installazione di quel JRE con lo script / GPO che distribuisce l'applicazione e tratta i due come un'unità. Questo è il modo più semplice che mi viene in mente di affrontarlo.

Sto facendo fatica a ricordare quali impostazioni vivono in "Programmi", ma concederei a malincuore l'autorizzazione a un gruppo di sicurezza contenente account utente che devono modificare queste impostazioni, se necessario. Probabilmente avrei anche tenuto la testa tra le mani e maledetto Sun.

Fino a quando Sun non metterà insieme le proprie azioni in merito all'implementazione e alla gestione delle imprese di JRE, penso che è probabile che tutti noi avremo soluzioni temporanee complicate per gestirle. È frustrante, ma tristemente tipico. Sembra che la stragrande maggioranza degli sviluppatori non abbia idea di cosa significhi fare un lavoro di amministratore di sistema. <Sigh>

In realtà abbiamo avuto a che fare con molte applicazioni di terze parti (inclusa Java) e anche con i loro programmi di aggiornamento.

Abbiamo deciso come organizzazione di integrare Ninite come nostra soluzione. Visitare il sito ed eseguire la versione gratuita funziona benissimo per un'installazione singola su qualsiasi PC, ma, quando si va su Pro su Ninite, si ottiene anche Ninite One come parte dell'abbonamento. Ninite one è qualcosa che puoi eseguire dalla riga di comando, in silenzio, per distribuire un buon numero di applicazioni.

Sarò lieto di rivelare che siamo tutti PC, ma nel complesso siamo davvero contenti della soluzione.

Ninite One ha opzioni della riga di comando per disabilitare cose come gli aggiornamenti automatici e la creazione di collegamenti desktop sugli aggiornamenti. Questo è quello che abbiamo fatto e funziona abbastanza bene. Tuttavia, non consente più versioni di Java se questo è un requisito che non credo (ma potrei sbagliarmi, non l'ho ancora testato)

Ho una soluzione per te, sebbene sia una soluzione commerciale, ma puoi usare PolicyPak per creare un oggetto Criteri di gruppo che gestirà quasi tutte le impostazioni all'interno di Java. Hanno una modalità di prova ed edizioni in modalità community per provarlo o utilizzarlo gratuitamente in una capacità limitata. PolicyPak si integra con i Criteri di gruppo di Windows e consente di gestire e bloccare le impostazioni di configurazione delle applicazioni per applicazioni di terzi come Java in modo ancora più efficace rispetto ai Criteri di gruppo standard che bloccano i vari aspetti di Windows. Il link al suo Java Pak è qui http://www.policypak.com/products/manage-java-jre-with-group-policy.html e il link alle edizioni gratuite è qui http: //www.policypak. com / support-sharing / policypak-trial-community-edition-full-licenza-mode.html .

Brad (dipendente di PolicyPak)