15
Java Desktop Runtine Enviroment Update
Hallo Zusammen
Zurzeit verwenden wir die Version 6u39 von Java RE für Windows 7. Gerne möchte ich aus Sicherheittechnischen Gründen diese auf den aktuellen Stand bringen.
Zurzeit haben wir Anwendungen welche ältere Versionen von Java benötigen sprich Java 7 Update 40 usw.
Nun bin ich am Informationen sammeln wie ich das am besten angehen soll.
Es gibt die Möglichkeiten mit dem Deployment Rule Set
- Hat jemand von euch bereits Erfahrung damit gemacht?
Die andere Möglichkeit wäre mehrere Java Versionen gleichzeitig auf einen PC zu installieren
- Wie sieht es bei dieser Möglichkeit mit der Sicherheit aus?
Gibt es Lektüre ( ausser Google ) wo man sich ein bisschen in das Thema einarbeiten kann oder so?
Vielen Dank für eure Inputs!
Zurzeit verwenden wir die Version 6u39 von Java RE für Windows 7. Gerne möchte ich aus Sicherheittechnischen Gründen diese auf den aktuellen Stand bringen.
Zurzeit haben wir Anwendungen welche ältere Versionen von Java benötigen sprich Java 7 Update 40 usw.
Nun bin ich am Informationen sammeln wie ich das am besten angehen soll.
Es gibt die Möglichkeiten mit dem Deployment Rule Set
- Hat jemand von euch bereits Erfahrung damit gemacht?
Die andere Möglichkeit wäre mehrere Java Versionen gleichzeitig auf einen PC zu installieren
- Wie sieht es bei dieser Möglichkeit mit der Sicherheit aus?
Gibt es Lektüre ( ausser Google ) wo man sich ein bisschen in das Thema einarbeiten kann oder so?
Vielen Dank für eure Inputs!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 250917
Url: https://administrator.de/forum/java-desktop-runtine-enviroment-update-250917.html
Ausgedruckt am: 22.12.2024 um 20:12 Uhr
15 Kommentare
Neuester Kommentar
Hallo,
ich hatte bis vor wenigen Wochen auch 2 Clients mit Software in einer Außenstelle, die mit der aktuellen 1.7.67 nicht klarkam; dies ist durch ein Update der Steuerungssoftware inzwischen erledigt.
Als ich die neue 1.7.67 dort installierte, war meiner Erinnerung nach die Möglichkeit, auf entsprechenden Hinweis des Java-Setups die vom Setup festgestellten älteren Java-Versionen zu behalten oder vom Setup deinstallieren zu lassen.
Gruß,
VGem-e
ich hatte bis vor wenigen Wochen auch 2 Clients mit Software in einer Außenstelle, die mit der aktuellen 1.7.67 nicht klarkam; dies ist durch ein Update der Steuerungssoftware inzwischen erledigt.
Als ich die neue 1.7.67 dort installierte, war meiner Erinnerung nach die Möglichkeit, auf entsprechenden Hinweis des Java-Setups die vom Setup festgestellten älteren Java-Versionen zu behalten oder vom Setup deinstallieren zu lassen.
Gruß,
VGem-e
Moin.
Gegenfrage: Womit verteilst du denn die Software?
Je nach verwendeter Methode (GPO, SCCM, OPSI, ...) gibt es unterschiedliche Ansätze/Möglichkeiten.
Cheers,
jsysde
Gegenfrage: Womit verteilst du denn die Software?
Je nach verwendeter Methode (GPO, SCCM, OPSI, ...) gibt es unterschiedliche Ansätze/Möglichkeiten.
Cheers,
jsysde
Hallo
Zwei Varianten stehen mir zur Verfügung. SCCM 2007 oder App-V
Gruss
GMOSSin
Zwei Varianten stehen mir zur Verfügung. SCCM 2007 oder App-V
Gruss
GMOSSin
Moin.
SCCM klingt ja schon mal ganz gut, allerdings hatte ich mit SCCM2007 Probleme beim Verteilen der Files (exception.sites etc.); die musste ich alle zusammenzippen, um sie auf die Clients zu deployen und dann eben per Skript während des Setups an die passenden Stellen extrahieren.
Das Update von JRE1.6.x auf 1.7.x ist nicht ganz unproblematisch, da die aktuellste 1.7.67 gewisse Sicherheitseinstellungen erwartet, die man innerhalb eines AD bestenfalls vorher kennt und entsprechend deployed; wie gesagt, unter SCCM2007 mit einigen Fußangeln.
Generell gehe ich so vor:
- aktuelle Version der JRE runterladen und MSI extrahieren
- per InstEd eine MST bauen, die AutoUpdate & Co. entfernt/deaktiviert und per eingebettetem vbs auch die Startmenüverknüpfungen löscht
- Deployment per SCCM, Installation per cmd
- Verteilung von execption.sites etc. ebenfalls per cmd während des Setup
Ich schau mal, ob ich das Skript, das ich im SCCM2007 verwendet habe, noch finde....
Cheers,
jsysde
SCCM klingt ja schon mal ganz gut, allerdings hatte ich mit SCCM2007 Probleme beim Verteilen der Files (exception.sites etc.); die musste ich alle zusammenzippen, um sie auf die Clients zu deployen und dann eben per Skript während des Setups an die passenden Stellen extrahieren.
Das Update von JRE1.6.x auf 1.7.x ist nicht ganz unproblematisch, da die aktuellste 1.7.67 gewisse Sicherheitseinstellungen erwartet, die man innerhalb eines AD bestenfalls vorher kennt und entsprechend deployed; wie gesagt, unter SCCM2007 mit einigen Fußangeln.
Generell gehe ich so vor:
- aktuelle Version der JRE runterladen und MSI extrahieren
- per InstEd eine MST bauen, die AutoUpdate & Co. entfernt/deaktiviert und per eingebettetem vbs auch die Startmenüverknüpfungen löscht
- Deployment per SCCM, Installation per cmd
- Verteilung von execption.sites etc. ebenfalls per cmd während des Setup
Ich schau mal, ob ich das Skript, das ich im SCCM2007 verwendet habe, noch finde....
Cheers,
jsysde
Hi.
Man sollte die höchstmögliche Version einsetzen, die die Applets korrekt ausführt.
Das Umschalten zwischen mehreren ist nicht immer gangbar, da der Nutzer dann mitarbeiten muss, darin sind User nicht immer so begabt :|
Bewerte doch erst einmal die Risiken der Verwendung von alten Versionen. Wann, außer im Browser, könnte bei Euch denn solcher Code für Angriffe genutzt werden? Könnte man es im Browser vielleicht ausschalten?
Man sollte die höchstmögliche Version einsetzen, die die Applets korrekt ausführt.
Das Umschalten zwischen mehreren ist nicht immer gangbar, da der Nutzer dann mitarbeiten muss, darin sind User nicht immer so begabt :|
Bewerte doch erst einmal die Risiken der Verwendung von alten Versionen. Wann, außer im Browser, könnte bei Euch denn solcher Code für Angriffe genutzt werden? Könnte man es im Browser vielleicht ausschalten?
Moin.
hier das Skript, also der relevante Teil davon:
Sollte eigentlich alles drin sein, um die aktuellste JRE1.7 mit SCCM2007 verteilen zu können; Vorarbeiten müssen natürlich sauber erledigt werden und "Nebenkriegsschauplätze" sollten auch bedacht werden => z.B. IE per GPO anpassen, damit JAVA-Applets auch wirklich starten etc.
Cheers,
jsysde
hier das Skript, also der relevante Teil davon:
rem /// Description:
rem /// CMD-based update for JAVA Runtime Environment 7
rem ///
rem /// Following values in "Property" for MST-file must be changed with InstEd:
rem /// AUTOUPDATECHECK 0, IEXPLORER 1, JAVAUPDATE 0, JU 0, MOZILLA 1, RebootYesNo NO
rem ///
rem /// DelStartMenuDir.vbs must be implemented in MST-File!
rem /// http://www.edugeek.net/forums/downloads/123291-java-runtime-environment-7-update-40-released-update-warning-can-now-disabled.html#post1065316
rem ///
rem /// deployment.config and deployment.properties must be deployed to ensure no warnings will be presented when browser is opened
rem /// http://www.edugeek.net/forums/downloads/123291-java-runtime-environment-7-update-40-released-update-warning-can-now-disabled.html#post1065466
rem ///
rem /// Be sure to reference correct (actual) MSI-file!
rem /// Be sure to check correct registry key!
rem /// Uninstall JAVA Runtime Environment 6u45/7u40/7u45/7u51/7u55 prior to installing
if exist %windir%\installer\{26A24AE4-039D-4CA4-87B4-2F83217040FF} msiexec /x {26A24AE4-039D-4CA4-87B4-2F83217040FF} /qn /norestart
if exist %windir%\installer\{26A24AE4-039D-4CA4-87B4-2F83217045FF} msiexec /x {26A24AE4-039D-4CA4-87B4-2F83217045FF} /qn /norestart
if exist %windir%\installer\{26A24AE4-039D-4CA4-87B4-2F83217051FF} msiexec /x {26A24AE4-039D-4CA4-87B4-2F83217051FF} /qn /norestart
if exist %windir%\installer\{26A24AE4-039D-4CA4-87B4-2F83217055FF} msiexec /x {26A24AE4-039D-4CA4-87B4-2F83217055FF} /qn /norestart
if exist %windir%\installer\{26A24AE4-039D-4CA4-87B4-2F83216045FF} msiexec /x {26A24AE4-039D-4CA4-87B4-2F83216045FF} /qn /norestart
rem /// Run Setup with MST-file
msiexec /i jre1.7.0_55.msi transforms=custom_jre7.mst /quiet /passive
rem /// Deploy deployment.config and deployment.properties
if not exist %systemroot%\Sun\Java\Deployment mkdir %systemroot%\Sun\Java\Deployment
7za.exe e JRE7u55.zip
xcopy deployment.config %systemroot%\Sun\Java\Deployment /E /I /H /R /y
xcopy deployment.properties %systemroot%\Sun\Java\Deployment /E /I /H /R /y
xcopy exception.sites %systemroot%\Sun\Java\Deployment /E /I /H /R /y
goto :eof
:eof
rem /// E O FSollte eigentlich alles drin sein, um die aktuellste JRE1.7 mit SCCM2007 verteilen zu können; Vorarbeiten müssen natürlich sauber erledigt werden und "Nebenkriegsschauplätze" sollten auch bedacht werden => z.B. IE per GPO anpassen, damit JAVA-Applets auch wirklich starten etc.
Cheers,
jsysde
Moin.
Nachtrag, das hatte ich gestern irgendwie vergessen...
JRE7u55.zip enthält die deployment-Files, die sich per SCCM2007 nicht direkt verteilen lassen, namentlich:
- deployment.config
- deployment.properties
- execption.sites
deployment.config
deployment.properties
execption.sites (Beispiel)
Cheers,
jsysde
Nachtrag, das hatte ich gestern irgendwie vergessen...
JRE7u55.zip enthält die deployment-Files, die sich per SCCM2007 nicht direkt verteilen lassen, namentlich:
- deployment.config
- deployment.properties
- execption.sites
deployment.config
deployment.system.config=file\:C\:/WINDOWS/Sun/Java/Deployment/deployment.properties
deployment.system.config.mandatory=truedeployment.properties
# deployment.properties
# http://docs.oracle.com/javase/7/docs/technotes/guides/deployment/deployment-guide/properties.html
deployment.browser.vm.iexplorer.locked
deployment.browser.vm.iexplorer=true
deployment.browser.vm.mozilla.locked
deployment.browser.vm.mozilla=true
deployment.expiration.check.enabled=false
deployment.security.level.locked
deployment.security.level=HIGH
deployment.security.mixcode.locked
deployment.security.mixcode=HIDE_RUN
deployment.user.security.exception.sites=c:/Windows/Sun/Java/Deployment/exception.sites
deployment.javaws.associations.locked
deployment.javaws.associations=NEVER
deployment.javaws.autodownload.locked
deployment.javaws.autodownload=NEVER
deployment.javaws.install.locked
deployment.javaws.install=NEVER
deployment.javaws.shortcut.locked
deployment.javaws.shortcut=NEVER
deployment.cache.jarcompression.locked
deployment.cache.jarcompression=9
deployment.console.startup.mode.locked
deployment.console.startup.mode=DISABLE
deployment.proxy.type.locked
deployment.proxy.type=3
deployment.system.tray.icon.locked
deployment.system.tray.icon=false
java.quick.starter.locked
java.quick.starter=falseexecption.sites (Beispiel)
http://deinejavaapp.domain
https://192.168.10.10Cheers,
jsysde
1
Hi
Zurzeit versuche ich alle Applikationen aufzulisten welche bei den Benutzer über Java laufen. Da aber leider nicht dokumentiert wurde welche Software welche Java Version benötigen ist dies noch sehr schwierig.
Ja, es könnte auch auf lokaler Ebene ein Risiko darstellen oder etwa nicht?
Erkennt die Software / Applet welche Version er benötigt und kann nicht diese verwenden ohne das ein Eingriff vom Benutzer benötigt wird?
Zurzeit versuche ich alle Applikationen aufzulisten welche bei den Benutzer über Java laufen. Da aber leider nicht dokumentiert wurde welche Software welche Java Version benötigen ist dies noch sehr schwierig.
Ja, es könnte auch auf lokaler Ebene ein Risiko darstellen oder etwa nicht?
Erkennt die Software / Applet welche Version er benötigt und kann nicht diese verwenden ohne das ein Eingriff vom Benutzer benötigt wird?
Erkennt die Software / Applet welche Version er benötigt
Jein. Es gibt Softwares, die nehmen das registrierte Java (das kann nur eins zur Zeit sein, auch wenn mehrere installiert sind). Andere Softwares suchen bestimmte Pfade ab nach Java-Versionen bzw. es ist eine fest eingestellt.Ja, es könnte auch auf lokaler Ebene ein Risiko darstellen oder etwa nicht?
Natürlich, könnte es das, deshalb frage ich ja, ob Ihr mit Applets hantiert, die aus unvertrauten Quellen kommen. Ist das so?
Nein, es sind eigentliche alle aus vertraubaren Quellen.
Aber im Webbrowser braucht Ihr Java unbedingt?
Leider Ja.
Moin.
Ich hänge noch mal ne Frage hintendran:
Benötigt ihr nur die 32bittige JRE oder auch die 64Bit-Version?
Und verwendet ihr JRE nur im Browser oder habt ihr auch lokale JAVA-Anwendungen, die ein installiertes JRE benötigen?
Ich erinnere mich dunkel, bei einem Kunden lief eine JAVA-Anwendung für die PBX. Damals haben wir JRE + Anwendung einfach als RemoteApp zur Verfügung gestellt in der 64Bit-Version, während auf den Clients nur die 32Bit-Version installiert wurde - man kann das also aufteilen bzw. auch komplett auslagern, wobei das schwer wird, wenn JRE im lokalen Browser benötigt wird....
Cheers,
jsysde
Ich hänge noch mal ne Frage hintendran:
Benötigt ihr nur die 32bittige JRE oder auch die 64Bit-Version?
Und verwendet ihr JRE nur im Browser oder habt ihr auch lokale JAVA-Anwendungen, die ein installiertes JRE benötigen?
Ich erinnere mich dunkel, bei einem Kunden lief eine JAVA-Anwendung für die PBX. Damals haben wir JRE + Anwendung einfach als RemoteApp zur Verfügung gestellt in der 64Bit-Version, während auf den Clients nur die 32Bit-Version installiert wurde - man kann das also aufteilen bzw. auch komplett auslagern, wobei das schwer wird, wenn JRE im lokalen Browser benötigt wird....
Cheers,
jsysde
Hallo
Wir benötigen auch die 64Bit Version.
WIr haben auch lokal Installierete Java Anwendungen.
Der aktuelle Stand ist, dass wir Java aus Gründen der Kompatiblität zu einigen Anwendungen zurzeit nicht aktualisieren können.
Deswegen möchte ich wenigstens eine Black bzw. White Liste erstellen und die Sicherheitseinstellungen von Java anpassen.
Mit der Version 7 funktioniert es ohne Probleme aber die Version 6 hat leider einige Probleme dabei.
Wir benötigen auch die 64Bit Version.
WIr haben auch lokal Installierete Java Anwendungen.
Der aktuelle Stand ist, dass wir Java aus Gründen der Kompatiblität zu einigen Anwendungen zurzeit nicht aktualisieren können.
Deswegen möchte ich wenigstens eine Black bzw. White Liste erstellen und die Sicherheitseinstellungen von Java anpassen.
Mit der Version 7 funktioniert es ohne Probleme aber die Version 6 hat leider einige Probleme dabei.
Moin.
Dann musst du dir diese Zeilen hier genauer anschauen:
Die GUID beinhaltet die Architektur, die "32" vor der JRE-Version (17051) bezeichnet hier die 32BIt-Version; für 64Bit muss dass natürlich "64" heissen.
Cheers,
jsysde
Dann musst du dir diese Zeilen hier genauer anschauen:
if exist %windir%\installer\{26A24AE4-039D-4CA4-87B4-2F83217051FF} msiexec /x {26A24AE4-039D-4CA4-87B4-2F83217051FF} /qn /norestartDie GUID beinhaltet die Architektur, die "32" vor der JRE-Version (17051) bezeichnet hier die 32BIt-Version; für 64Bit muss dass natürlich "64" heissen.
Cheers,
jsysde
