Java Runtime 7 Updates auf XenApp-Servern deaktivieren

Verfasst am 26. Jun. 2013 von | Kategorie: Desktop Delivery

Derzeit klagen viele unserer Citrix-Kunden über ein Problem bei der Bereitstellung von Web-Browsern über ihre XenApp-Umgebung. Aufgrund der aktuellen Java-Sicherheitswarnungen wird beim Starten von Java Applets im Browser oft diese Meldung beim User angezeigt:

Java Meldung XenApp

Klickt der User auf „Update“, wird ihm der Download der aktuellen Version angeboten. Mit dem Download kann der User aber nichts anfangen, da ihm natürlich die Rechte fehlen, das Update zu installieren.

Leider konnte ich bei meiner Recherche im Internet keine zufriedenstellende Möglichkeit zur Deaktivierung der Update-Meldung finden. Im Folgenden habe ich daher Optimierungsmöglichkeiten für den Einsatz einer Java Runtime auf Citrix XenApp-Servern zusammengetragen. Darüber hinaus beschreibe ich eine Lösung, mit der diese Meldung bei den Benutzern deaktiviert werden kann. So lassen sich Probleme, die durch die falsche Auswahl des Users entstehen, umgehen und Helpdesk-Anrufe vermeiden.

Umleitung des Java-Caches auf eine zentrales Verzeichnis (pro Server)

Auf dem Laufwerk C: wird dazu folgende Ordnerstruktur angelegt:

Ordnerstruktur Java XenApp

Der Gruppe SERVERNAME\Benutzer werden anschließend Änderungsrechte gegeben.

3

Unter C:\Windows Verzeichnis legt man nun folgende Ordnerstruktur an:

4

Beim Einsatz der Citrix Provisioning Services sollte der Ordner auf dem Write-Cache-Laufwerk erstellt werden, damit der Inhalt beim Neustart erhalten bleibt.

Im Ordner Deployment müssen dann folgende Dateien angelegt werden:

5

Inhalt deployment.config

deployment.system.config=file:\\C\:\\WINDOWS\\Sun\\Java\\Deployment\\deployment.properties deployment.system.config.mandatory=true

deployment.system.config –> Verweis auf eine zentrale deployment.properties Datei

deployment.system.config.mandatory –> wird die Datei nicht gefunden, wird die Ausführung von Java blockiert

Inhalt deployment.properties

deployment.user.cachedir=C\:\\Java\\Cache
deployment.system.cachedir=C\:\\Java\\SystemCache deployment.user.security.trusted.certs=C\:\\Java\\CertStore\\security\\trusted.certs deployment.system.security.trusted.certs=C\:\\Java\\CertStore\\security\\trusted.certs deployment.security.notinca.warning=false
deployment.security.expired.warning=false
deployment.security.mixcode=HIDE_RUN
deployment.javaws.jre.0.args=-Xmx256m -Xms64m
deployment.javapi.jre.0.args=-Xmx256m -Xms64m
deployment.javaws.jre.1.6.0.args=-Xmx256m -Xms64m
deployment.javapi.jre.1.6.0.args=-Xmx256m -Xms64m
deployment.expiration.decision.suppression.10.17.2=true
deployment.expiration.decision.10.17.2=later
deployment.security.level.locked

Beschreibung der wichtigsten Parameter

deployment.user.cachedir –> Pfad zum User-Cache
deployment.system.cachedir –> Pfad zum System-Cache

Durch die Umleitung auf den zentralen Pfad wird die Java-Anwendung beim ersten Aufruf eines Benutzers gecacht. Weitere Aufrufe (auch durch andere User) starten die Anwendung ohne erneutes Caching.

deployment.user.security.trusted.certs –> Pfad zum User Cert Store
deployment.system.security.trusted.certs –> Pfad zum System Cert Store

Durch den Verweis auf eine zentrale trusted.certs Datei müssen die Meldungen zur Bestätigung der Vertrauenswürdigkeit nur beim ersten Aufruf der Anwendung durch einen Benutzer bestätigt werden. Die Datei mit den benötigten Anwendungen kann auch schon vom Administrator bereitgestellt werden.

deployment.expiration.decision.suppression.10.17.2=true –> aktiviert

6

deployment.expiration.decision.10.17.2=later –> aktiviert

7

Der Wert 10.17.2 muss durch die aktuelle Version ersetzt werden.

deployment.security.level.locked –> Der User kann die Security-Einstelllungen in der Systemsteuerung nicht ändern.

Dokumentation der Parameter:
http://docs.oracle.com/javase/7/docs/technotes/guides/deployment/deployment-guide/properties.html 

Beim Starten der Sitzung sollten noch folgende Registry-Einträge gesetzt werden (hier mittels Kixtart):
? @DATE + “ – “ + @TIME + “ – Java Runtime Konfiguration…“
DelTree
(„HKEY_CURRENT_USER\Software\AppDataLow\Software\JavaSoft\DeploymentProperties“)
? @DATE + “ – “ + @TIME + “ – vorhandene Registry Einträge gelöscht…“
$jre_version = READVALUE(„HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment“,“BrowserJavaVersion“)
? @DATE + “ – “ + @TIME + “ – Java Runtime Browser Version“ +$jre_version+“ gefunden…“
WriteValue („HKEY_CURRENT_USER\Software\AppDataLow\Software\JavaSoft\DeploymentProperties“,“deployment.expiration.decision.“+$jre_version,“later“,“REG_SZ“)
WriteValue („HKEY_CURRENT_USER\Software\AppDataLow\Software\JavaSoft\DeploymentProperties“,“deployment.expiration.decision.suppression.“+$jre_version,“true“,“REG_SZ“)
? @DATE + “ – “ + @TIME + “ – Java Runtime Konfiguration fertig…“

Wie ich bei unserem Test festgestellt habe, wird die zentrale deployment.properties Datei erst ausgewertet, wenn die Meldung bereits bestätigt wurde. Allerding müssen die Einträge auch in der Datei vorhanden sein, da sonst die Einträge beim Einlesen der Datei in die Registry gelöscht werden. Sind die Einträge in der Registry nicht vorhanden, wird beim nächsten Start einer Java-Anwendung die Meldung wieder angezeigt.

Aufruf von Java Applets mit Nutzung des System-Caches

Mit folgender Befehlszeile können Java Webstart-Anwendungen (.jnlp) zur Verwendung des System-Caches gezwungen werden. In unseren Testumgebungen hat dies bis jetzt immer funktioniert.

C:\Windows\System32\javaws.exe –system <Pfad zur Java WebStart Datei>

Fehlerbehebung (User hat auf Update geklickt)

Das Klicken auf „Update“ bewirkt eine sofortige Deaktivierung der Java Runtime für den User. Durch Löschen des folgenden Registry-Wertes kann dies behoben werden:

HKEY_CURRENT_USER\Software\AppDataLow\Software\JavaSoft\DeploymentProperties

„deployment.expiration.decision.10.17.2″=“update“

10.17.2 steht für die installierte Version (Java 7 Update 17)

Fazit

Mit diesen Anpassungen lässt sich die Java 7 Runtime im Betrieb mit Citrix XenApp bändigen. Getestet wurde mit den Jave Runtimes 7 Update 17 und 21. Ich hoffe, Oracle ändert diese Mechanismen nicht so bald oder gibt Administratoren künftig bessere Eingriffsmöglichkeiten an die Hand, um die Java Runtime zu managen.

Quellen
http://www.jasonsamuel.com/2011/11/28/getting-java-web-applications-to-work-on-citrix-xenapp/
http://www.labareweb.com/java-1-7-auto-update-deployment-with-sccmmdt/

Tags: , ,

Unser Newsletter informiert Sie über neue Beiträge in unserem Blog.

Ihre E-Mailadresse:

7 Kommentare
Hinterlassen Sie einen Kommentar! »

  1. Hallo Claus,

    ein super Beitrag. Funktioniert prima. Noch eine Frage: Gibt es Vorteile, wenn Java Apps zur Verwendung vom SystemCache gezwungen werden?

    Mfg

    R. Vosswinkel

  2. Hallo Rolf,

    Ein Vorteil der System-Cache Nutzung ist, dass die .jar Files nur einmal von der Quelle geladen werden müssen. Sind die Files im Cache, können alle Benutzer auf dem XenApp Server diese Files nutzen. Das verkürzt die Ladezeiten der Java Anwendung.

    Viele Grüße

    Claus Schwemmlein

  3. Hallo Claus,

    leider verzweifle ich daran.
    Ich habe alles (denk ich) richtig eingerichtet und trotzdem bekomme ich weiterhin die Update-Meldung angezeigt.
    Das Skript für die Registry-Anpassung läuft – konnte ich überprüfen.
    Der Cache wird verwendet – Ordner/Daten werden erstellt.
    Also werden die Configs abgearbeitet. Aber wieso wird weiterhin die Meldung angezeigt?
    Getestet anfangs mit Version 7U25, später mit 7U17.
    Ich hoffe, wir können den Fehler zusammen finden.

    Vielen Dank im Voraus.
    Grüße René

  4. Hallo René,

    bitte einmal prüfen, ob der folgende Registry Key vorhanden ist:
    HKEY_CURRENT_USER\Software\JavaSoft\Java Runtime Environment\Security Baseline
    Hier vermerkt die Java Runtime die sicheren Versionen. Diesen Key löschen, falls vorhanden.

    Auch können Reste im Benutzerprofil stören. Prüfe den Inhalt des Ordners:
    %userprofile%\AppData\LocalLow\Sun\Java\Deployment\security
    Ist dieser vorhanden, den Ordner ebenfalls löschen

    Gegebenenfalls die Java Runtime komplett deinstallieren und alle Reste aus dem File System und der Registry entfernen. Wir deaktivieren auch die Java Updatefunktion in der Registry (verhinderte in älteren Java Versionen die Update Suche):

    [HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Update\Policy]
    „EnableAutoUpdateCheck“=dword:00000000
    „EnableJavaUpdate“=dword:00000000

    [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432NodeJavaSoft\Java Update\Policy]
    „EnableAutoUpdateCheck“=dword:00000000
    „EnableJavaUpdate“=dword:00000000

    Ich hoffe meine Tips helfen das Problem zu lösen.

    Viele Grüße

    Claus Schwemmlein

  5. Hallo Claus,

    vielen Dank für die schnelle Antwort.
    Leider bringen mich auch diese Tipps nicht weiter.
    1. Den RegKey ‚Security Baseline‘ habe ich gelöscht, wird beim nächsten Mal wieder angelegt -> keine Auswirkungen.
    2. Die Reste im Profil hab ich gelöscht, hatte aber keine Auswirkungen.
    3. Java komplett deinstalliert, FileSystem und Registry überprüft.
    Eine Vermutung war noch, dass die ältere Version 6U31 Einfluss hat. Aber auch eine Bereinigung dessen und anschließende Neuinstallation von nur 7U17 hat weiterhin die Meldung „Java ist unsicher“ gebracht.

    Eingesetzt werden Windows 2003 Server. Weiß nicht, ob hier das Problem liegen könnte.
    Schlussendlich das Löschen des kompletten Benutzerprofils (servergespeichert) brachte ebenfalls keine Änderung. Die Meldung verschwindet einfach nicht. Oder ist es falsch zum Testen die Seite von Java zu nutzen (http://java.com/de/download/installed.jsp)?

    Ich werde es wohl vorerst aufgeben, leider fehlt mir die Zeit mich eine Woche lang damit rumzuschlagen. Falls jemand noch einen Tipp hat, werde ich es gerne prüfen, ansonsten müssen die Nutzer damit leben.

    Trotzdem vielen Dank für die Mühe!
    Viele Grüße
    René

  6. Hallo René,

    Schade das meine Tips dir nicht helfen konnten.

    Etwas ist mir noch eingefallen: Hast du die TS Shadow Registry Keys unter „HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install“ mal geprüft? Eventuell hat die Java Runtime bei der Installation im Installationsmodus schon einige Einträge erstellt und diese wurden in die Shadow Registry gespiegelt. Dann werden die Einträge beim Anmelden in das Benutzerprofil kopiert und verursachen so das Problem.

    Viele Grüße

    Claus Schwemmlein

  7. Hallo Claus,

    auch die erwähnten Registry Keys exisiteren nicht.

    Etwas neues ist mir eben noch aufgefallen:
    Du schreibst ja, dass man mit dem String „deployment.security.level.locked“ die Sicherheitseinstellungen nicht verändern kann. Allerdings kann ich sie verändern. Wenn ich aber zusätzlich „deployment.security.level=MEDIUM“ davor setze, wird der Wert auf MEDIUM (alternativ HIGH getestet) gesetzt und ist nicht mehr veränderbar. Fehlt einer der beiden Strings, lassen sich Veränderungen durchführen.

    Obwohl ich alle anderen Werte so wie von dir beschrieben setze, bekomme ich trotzdem weiterhin die Meldung der unsicheren Java-Version angezeigt. Ich verstehe die (Java-)Welt nicht mehr.

    Viele Grüße,
    René

Hinterlassen Sie einen Kommentar!


6 × = vierzig acht