Java im Unternehmen einzusetzen war schon immer eine Herausforderung – insbesondere was die vorhandenen Sicherheitslücken angeht. Sun bzw. mittlerweile Oracle hat als Hersteller dafür gesorgt, das sich Java bei erscheinen einer neuen Version entweder selbständig aktualisiert oder zumindest den Anwender über die neue Version informiert.
Das funktioniert auf PCs, auf denen der Benutzer selber für die Software verantwortlich ist, im Allgemeinen recht gut. Auf PCs im Unternehmen, die zentral verwaltet werden oder auf Terminalservern ist die Meldung über einen neue Java-Version allerdings überflüssig oder sogar hinderlich. Ein ungeplantes Update auf eine neue Version kann zur Folge haben, das eine Unternehmensanwendung nicht mehr funktioniert. Daher müssen neue Java-Versionen vorab darauf getestet werden, ob alle Unternehmensanwendungen dazu kompatibel sind.
In den Version bis Java 1.7 Update 10 genügte es, den Haken bei der automatischen Suche nach Update im Java Control-Panel herauszunehmen.
Dies kann manuell erfolgen, durch ein GPO oder die Verteilung einer Konfigurationsdatei. Die Nutzung dieser Konfigurationsdateien (deployment.properties) ist ziemlich Tricky und wird später in diesem Artikel noch genauer erklärt.
Ab der Version 1.7 Update 10 wurde diese besagte Update-Prüfung eingebaut und bei vorliegen einer neuen Version kam der Hinweis, das ein Java-Update erforderlich sein. Dabei handelt es sich um die Prüfung gegen die Website https://javadl-esd-secure.oracle.com/update/baseline.version, die die aktuelle Java-Version auflistet. Aktuell (6.10.2017) liefert der Aufruf der URL das folgende Ergebnis:
Der Test kann blockiert werden, indem der Zugriff auf diese URL geblockt wird. Das soll bis zur Version 1.7 Update 72 funktioniert haben, ab den späteren Versionen wurde dann zusätzlich noch ein internes Verfallsdatum in Java eingebaut. Wird dieses Datum erreicht, wird wieder darauf hingewiesen, Java zu aktualisieren:
Für die Version 1.8 Update 121 sind die Verfallsdaten der 18.4.2017 über die Update-Prüfung und der 18.8.2017 für die interne Prüfung. Diese Informationen findet man auf der Website Java 8-Releasehauptmerkmale für die Version 1.8.
Um Java mit einer sauberen Konfiguration zu installieren und insbesondere auch den Hinweis auf das Update zu unterdrücken sind mehrere Schritte nötig.
Im ersten Schritt wird der Offline-Installer von Java benötigt. Wird auf der Seite www.java.com der Download über den prominenten Knopf „Kostenloser Java Download“ gestartet, bekommt man nur einen Online-Installer, der für eine angepasste Installation nicht geeignet ist.
Wichtig ist, hier das hier der unscheinbare Link „Download“ angeklickt wird. Damit wird man auf eine weitere Seite geleitet, auf der man dann den Link zu alle Java-Downloads findet:
Auf der Seite können dann die Java-Installer für verschiedene Systeme heruntergeladen werden, auf der nun benötigte Windows Offline-Installer.
Der Download landet dann als exe-Datei auf dem Computer, für die Installation nutze ich allerdings lieber *.msi-Dateien. Diese lassen sich zum einen besser per GPO verteilen, sind aber auch für mein Lieblings-Software-Verteilungstool Empirum super geeignet.
Um die msi-Datei aus der exe-Datei zu bekommen genügt es, die Datei zu starten. Die benötigte Datei liegt dann unter %user%\Appdata\LocalLow\Oracle\Java\%version% und kann von dort in ein anderes Verzeichnis kopiert werden.
Der Installer kann dann direkt wieder abgebrochen werden, wir haben, was wir haben wollten.
Die Installation könnte jetzt direkt mit
msiexec -i jre1.8.0_144.msi
gestartet werden, das würde aber keinen Unterschied zur Standard-Installation bringen. Es sollen ja noch Anpassungen der Installation vorgenommen werden.
Die Parameter für die angepasste Installation lassen sich bei Oracle abholen, diese finden sich unter Installing With a Configuration File.
Für die Parameter habe ich eine Datei java.cfg erstellt, die die folgenden Einstellungen beinhaltet:
INSTALL_SILENT=Enable INSTALLDIR=C:\Program Files\Java\jre8 STATIC=Disable AUTO_UPDATE=Disable WEB_JAVA=Enable WEB_JAVA_SECURITY_LEVEL=H WEB_ANALYTICS=Disable EULA=Disable REBOOT=Disable NOSTARTMENU=Enable SPONSORS=Disable
Diese Parameter-Datei wird bei der Installation mit übergeben. Wichtig ist, das der absolute Pfad zur Datei mitgegeben werden muss! Außerdem werden UNC-Pfade nicht unterstützt, eine Installation aus einem Netzwerk-Share funktioniert so also auch nicht.
Wenn die Installationsdateien zum Beispiel in einem Ordner c:\Java liegen, würde die Installation so gestartet:
msiexec /i c:\java\jre1.8.0_121.msi INSTALLCFG=c:\java\java.cfg AUTOUPDATECHECK=0 REBOOT=REALLYSUPPRESS /qn
Damit wird Java installiert, die Einstellungen werden aus der java.cfg geladen. Der automatische Update-Check wird deaktiviert und ein eventueller Neustart des Computers unterdrückt. Der Parameter /qn steuert die Sichtbarkeit der Installation, die hier nur auf das Minimum beschränkt wird (Siehe msiexec Command-Line Options).
Dies ist allerdings erst die halbe Miete. Damit kein weiterer Test auf ein Update durchgeführt wird, muss noch eine Systemvariable gesetzt werden:
setx deployment.expiration.check.enabled false /m
Nun werden noch zwei weitere Dateien benötigt, damit verschiedene Optionen für Java systemweit gesetzt werden können. Zur Konfiguration von Java werden sowohl Registry-Keys genutzt als auch Text-Dateien. Die Einstellungen gelten normalerweise nur für den aktiven Anwender, liegen in der Registry also unter HKCU und im Filesystem unter %appdata%\LocalLow. Welcher Hirni ist bei Sun/Oracle auf die Idee gekommen ist, wichtige Einstellungen ausgerechnet im Profilpfad LocalLow unterzubringen? Selbst die akzeptierten Zertifikate landen in diesem Pfad.
Die benötigten Dateien sind zum einen die Datei deployment.config, in der hinterlegt wird, wo die zweite Datei gefunden wird, und die Datei deployment.properties, die die eigentlichen Konfigurationselemente beinhaltet. Für die systemweite Konfiguration muss die Datei deployment.config im Pfad c:\windows\sun\Java\Deployment liegen. Der Inhalt ist übersichtlich:
deployment.system.config=file\:C\:/WINDOWS/Sun/Java/Deployment/deployment.properties deployment.system.config.mandatory=true
Die erste Zeile gibt den Ort der Konfigurationsdatei an, das könnte auf ein Netzwerk-Share sein, habe ich aber noch nicht getestet. Die zweite Zeile erklärt den Inhalt der deployment.properties für verbindlich.
In der deployment.properties werden die Optionen von Java konfiguriert:
deployment.cache.enabled=FALSE deployment.cache.enabled.locked deployment.console.startup.mode=HIDE deployment.console.startup.mode.locked deployment.javaws.shortcut=NEVER deployment.javaws.autodownload=NEVER deployment.javaws.autodownload.locked deployment.expiration.check.enabled=FALSE deployment.expiration.check.enabled.locked deployment.expiration.decision=NEVER deployment.insecure.jres=ALWAYS deployment.insecure.jres.locked deployment.javaws.autodownload=NEVER deployment.security.level=MEDIUM
Mit diesen Einstellungen funktioniert Java auf Einzelplatz-Rechnern problemlos. Der Internet Explorer hat allerdings noch einen eigenen Test auf abgelaufene Plugins, so das beim Start von Java im IE dieser nun auf die veraltete Java-Version hinweist. Dies kann allerdings mit einem GPO oder einem Registry-Eintrag konfiguriert werden:
reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Ext"/v VersionCheckEnabled /t REG_DWORD /d 0 /f
In einer XenApp-Umgebung wurde trotz dieser Einstellungen beim Start einer Java-Anwendung im Browser auf das Java-Update hingewiesen. Da es sich bei dieser Anwendung um ein ERP-System handelt, das von allen Mitarbeitern im Unternehmen genutzt wird, war der Support-Aufwand nach dem Rollout von Java 1.8 dementsprechend hoch. Insbesondere, wenn der Hinweis mit „Aktualisieren“ oder „Blockieren“ beantwortet wurde.
Die Information, welche Option beim Update-Hinweis ausgewählt wurde, legt Java in der persönlichen deployment.properties des Benutzers unter %appdata%\locallow\Sun\Java\Deployment ab. Diese Einträge sind nur für die aktuell installierte Version gültig:
deployment.expiration.decision.timestamp.11.121.2=1507193746 deployment.expiration.decision.suppression.11.121.2=true deployment.expiration.decision.11.121.2=later
Der Timestamp ist im Unix Time Format angelegt (Millisekunden seit dem 1.1.1970) und enthält die Zeit der Auswahl, der Dialog soll nicht mehr gezeigt werden und die Auswahl ist „Später“. Parallel werden diese Einträge auch in der Registry unter HKCU\Software\JavaSoft\DeploymentProperties abgelegt.
Den Wert für decision.timestamp habe ich auf einen anderen Wert gesetzt, den 31.12.2020 um 23:59 Uhr., was als Unix-Timestamp dem Wert 1609459140 entspricht (mit dem Epoch Unix Time Stamp Converter).
Diese Einträge können über ein GPO im Benutzerkontext eingebaut werden, was auch für den ersten Start einer Java-Anwendung die Meldung deaktiviert. Wenn die Java-Anwendung beendet wird, werden diese Registry Keys leider wieder gelöscht, was beim nächsten Start wieder zu der Meldung des Java-Updates führt.
Das lässt sich umgehen, wenn die Datei deployment.properties die identischen Einträge bekommt. Dazu habe ich Java ohne deployment.properties-Datei gestartet, damit eine komplett neue Datei angelegt wird. In dieser Datei werden die drei Zeilen von oben eingefügt, und diese dann ebenfalls per GPO verteilt.
Dazu habe ich die Dateien ins Netlogon-Verzeichnis gepackt, und ein GPO zum kopieren der Datei erstellt. Als Quelle ist das Verzeichnis innerhalb von Netlogon angegeben, das Ziel ist
%systemdrive%\Users\%username%\AppData\Locallow\Java\Deployment\deployment.properties
Zusätzlich verteile ich noch die benötigten Zertifikate für die Java-Anwendungen, da es oft Probleme bei den Anwendern gibt, diese Zertifikate zu bestätigen. Die Zertifikate werden in der Datei trusted.cert im Verzeichnis
%systemdrive%\Users\%username%\AppData\Locallow\Java\Deployment\security
abgelegt. Diese kann mit einer Datei, die die benötigten Zertifikate enthält, ersetzt werden. Dadurch bekommt der Anwender keine Zertifikatsmeldungen mehr. Allerdings werden die Zertifikate für andere Anwendungen damit dann überschrieben.