Jump to content

Alternativer Local Update Publisher


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Läuft der LUP denn auf einem 2012er WSUS?

Hab mir deine Links jetzt (noch) nicht angesehen. Aber ich war der Meinung, dass er das eher nicht tun wird.

 

Ich habe schon erst mal den LUP probiert. Nur ließ sich der nicht auf dem 2012er Server starten. Von daher habe ich mich jetzt intensiver mit WPP auseinander gesetzt. Bis auf die sehr holperige (auch englische Übersetzung) finde ich ihn recht gut. :)

 

Nebenbei... so ganz von Erfolg gekrönt war meine Aktion nicht. Hatte ein bisschen Probleme mit Java 8 in Verbindung mit dem MyPortal-Client (gehört bei uns zu einer Telekom Telefonanlage). Das hat dazu geführt, dass ich auf das aktuellste 7er Java zurückgegangen bin.

Konnte mich die Tage deswegen dann etwas intensiver mit dem Thema (incl. WPP) beschäftigen. Hat aber alles geklappt und ich bin froh, dass ich diese "Baustelle" weg hab.

 

Für's Erste werde ich mal beim WPP bleiben. Geht's in deinen Links nur um den LUP? Interessant wäre dabei für mich die Frage, ob es der LUP denn tut, wenn ich ihn nicht direkt auf dem 2012er WSUS installiere. Aber wahrscheinlich eher nicht, oder?

bearbeitet von willy-goergen
Link zu diesem Kommentar

Läuft der LUP denn auf einem 2012er WSUS?

Hab mir deine Links jetzt (noch) nicht angesehen. Aber ich war der Meinung, dass er das eher nicht tun wird.

Dann wird es Zeit den Inhalt der Links zu lesen. Deshalb habe ich sie gepostet.

 

 

Bis auf die sehr holperige (auch englische Übersetzung) finde ich ihn recht gut. :)

wie Norbert schon schrub, melde dich an und biete dem Entwickler deine Hilfe an. Nur meckern ist nicht hilfreich.

 

 

 

Nebenbei... so ganz von Erfolg gekrönt war meine Aktion nicht. Hatte ein bisschen Probleme mit Java 8 in Verbindung mit dem MyPortal-Client (gehört bei uns zu einer Telekom Telefonanlage). Das hat dazu geführt, dass ich auf das aktuellste 7er Java zurückgegangen bin.

Konnte mich die Tage deswegen dann etwas intensiver mit dem Thema (incl. WPP) beschäftigen. Hat aber alles geklappt und ich bin froh, dass ich diese "Baustelle" weg hab.

 

 

 

Es hat dort auf wpp.codeplex jemand ein umfangreiches Script zum vollständigen deinstallieren aller vorhandenen Java Versionen gepostet, lässt sich sicher gut mit einem Custom Update ausrollen.

 

 

Für's Erste werde ich mal beim WPP bleiben. Geht's in deinen Links nur um den LUP? Interessant wäre dabei für mich die Frage, ob es der LUP denn tut, wenn ich ihn nicht direkt auf dem 2012er WSUS installiere. Aber wahrscheinlich eher nicht, oder?

 

Lies bitte und frag dann nochmal Details nach, Danke.

Link zu diesem Kommentar

Mittlerweile weiß ich, das hattest du so jetzt nicht geschrieben: Ich will mir deine Links nochmal näher ansehen. ;)

 

 

wie Norbert schon schrub, melde dich an und biete dem Entwickler deine Hilfe an. Nur meckern ist nicht hilfreich.
 

 

Ich wollte nicht meckern. Im Gegenteil: Ich bin froh, dass Leute gibt, die solche Sachen entwickeln. Ob ich auch einen Teil dazu beitragen kann, hängt ein bisschen davon ab, ob ich überhaupt Zeit dafür habe.

 

 

 

Es hat dort auf wpp.codeplex jemand ein umfangreiches Script zum vollständigen deinstallieren aller vorhandenen Java Versionen gepostet, lässt sich sicher gut mit einem Custom Update ausrollen.

 

Das Mit dem Custom-Update bei Java finde ich etwas komisch. Ich persönlich bin besser mit der Variante gefahren, die der Entwickler in seiner Doku beschreibt.

Wenn ich statt der MSI die EXE-Datei nehme, werden die alten Versionen doch automatisch deinstalliert. Die 32-Bit Executable vom Java-Installer, deinstalliert alle vorherigen 32-Bit Versionen selbstständig. Wieso die umständliche Vorgehensweise mit den Scripten? (was für mich nicht so recht funktioniert hat) 

Link zu diesem Kommentar

Ich wollte nicht meckern. Im Gegenteil: Ich bin froh, dass Leute gibt, die solche Sachen entwickeln. Ob ich auch einen Teil dazu beitragen kann, hängt ein bisschen davon ab, ob ich überhaupt Zeit dafür habe.

Es ist ja nicht eilig, David kann ja immer wieder die Änderungen in das nächste Release packen. Und in letzter Zeit wird so ein Release eigentlich immer nur alle 3-4 Monate veröffentlicht, Du hättest also genug Zeit. ;) 

 

 

 

Das Mit dem Custom-Update bei Java finde ich etwas komisch. Ich persönlich bin besser mit der Variante gefahren, die der Entwickler in seiner Doku beschreibt.

Wenn ich statt der MSI die EXE-Datei nehme, werden die alten Versionen doch automatisch deinstalliert. Die 32-Bit Executable vom Java-Installer, deinstalliert alle vorherigen 32-Bit Versionen selbstständig. Wieso die umständliche Vorgehensweise mit den Scripten? (was für mich nicht so recht funktioniert hat)

Mit dem MSI passiert nichts anderes, es ist einfach nur ein MSI. Es gibt leider genügend Clients da ist alles richtig vermurkst und es gibt zig verschiedene Java-Installation auf einer Maschine. Genau deshalb ist das Script gedacht. Ich hatte auch schon mit Java 8 getestet, es wurde keine vorige Java Version deinstalliert. Deshalb der Hinweis. Wenn Du es anders hingekriegt hast, sehr gut. Du darfst auch hier teilen. ;)

Link zu diesem Kommentar

Mit dem MSI passiert nichts anderes, es ist einfach nur ein MSI. Es gibt leider genügend Clients da ist alles richtig vermurkst und es gibt zig verschiedene Java-Installation auf einer Maschine. Genau deshalb ist das Script gedacht. Ich hatte auch schon mit Java 8 getestet, es wurde keine vorige Java Version deinstalliert. Deshalb der Hinweis. Wenn Du es anders hingekriegt hast, sehr gut. Du darfst auch hier teilen. ;)

 

Ich hatte da eben die gegenteilige Beobachtung gemacht. Es sei mal dahin gestellt, ob ich mich nicht täusche.

Die MSI hat bei mir stur drüber installiert, ohne auf vorherige Java-Versionen zu prüfen. Da war dann plötzlich "Java 7 - Update 65" zusammen mit "Java 7 - Update 71" installiert. Zumindest bei meinen Tests.

 

Versionsübergreifend (z.B. zwischen Java 7 und Java 8) wurde da nichts deinstalliert, das kann ich bestätigen. Das Versionchaos war/ist auch bei mir vorhanden. So wirklich fit bin ich im Scripting dann auch nicht.

 

Deswegen war ich froh, dass mir die Doku des Entwicklers etwas Denkarbeit abnimmt. Eigentlich ist auf fast allen Clients nur Java 7 (32-Bit) vorhanden. Und nachdem ich im Scripting noch nicht grade so wirklich fit bin, dachte ich mir:

 

Erst einmal alle Clients auf das aktuelleste Java 7 (32-Bit) updaten. Danach könnte ich immer noch den Weg gehen und hier zwischen 32 und 64 Bit (zum Beispiel) unterschieden. Die eindeutige MSI-GUID Den eindeutigen MSI-String für die Deinstallation der alten Version sollte man dann ja haben.

 

Ich weiß nicht, ob das jetzt wirklich jemandem hilft. Waren nur meine eigenen Gedanken dazu.

bearbeitet von willy-goergen
Link zu diesem Kommentar

Ich hatte da eben die gegenteilige Beobachtung gemacht. Es sei mal dahin gestellt, ob ich mich nicht täusche.

Die MSI hat bei mir stur drüber installiert, ohne auf vorherige Java-Versionen zu prüfen. Da war dann plötzlich "Java 7 - Update 65" zusammen mit "Java 7 - Update 71" installiert. Zumindest bei meinen Tests.

Java 7 Update 72 ist übrigens aktuell.

 

 

Versionsübergreifend (z.B. zwischen Java 7 und Java 8) wurde da nichts deinstalliert, das kann ich bestätigen. Das Versionchaos war/ist auch bei mir vorhanden.

 

Genau, super haben die Jungs von Oracle das hingekriegt.

Link zu diesem Kommentar

Wozu ich die 64-Bit Version ausrollen sollte, hat sich mir bisher auch noch nicht erschlossen. Aus Gründen der möglichen Inkompatibilität (und den vorher genannten Scripting-Kenntnissen) rolle ich nur das akutellste Java 7 (32-Bit) für alle aus. Für mich ist das auch ausreichend. Das war auch nicht die Frage, für mich zumindest. 

 

Für mich persönlich wäre es fatal Java 8 im Betrieb auszurollen, eben wegen der Dödelkom Telefonanlage. Da ist ein java-basierter Telefonieclient dabei, der derzeit nur mit Java 7 läuft.

Ich schließe mich jetzt mal leise an. Das haben die Jungs von Oracle echt toll gemacht. Jegliche Abwärtskompatibilität ist einfach gestrichen. Was früher in System32 oder SysWOW64 lag, ist heute ganz wo anders. Da habe ich mich auch riesig drüber gefreut.

 

 

Java 7 Update 72 ist übrigens aktuell.
 

 

 

Bist du dir da sicher? War das Update 72 nicht nur für das JDK?

bearbeitet von willy-goergen
Link zu diesem Kommentar

Bist du dir da sicher? War das Update 72 nicht nur für das JDK?

Ich hab die 72 von hier: http://www.oracle.com/technetwork/java/javase/downloads/jre7-downloads-1880261.html

 

Hier noch ein Artikel dazu: http://it-blogger.net/post/Java-SE-7-Update-72-steht-zum-Download-bereit.aspx

bearbeitet von Sunny61
Link zu diesem Kommentar

Ups... das hab ich wohl übersehen. Auf der Seite habe ich mir das Update 71 auch geholt.

 

Danke für den Hinweis. :)

 

Das muss ich dann nächste Woche beheben.

Zumindest bin ich schon mal froh, dass ich das Chaos in der Hinsicht diese Woche etwas lichten konnte. Wenn ich dran denke, wie das alles zu Beginn ausgesehen hat... Ihr habt's ja im Ansatz mitbekommen. Und es ist immer noch so viel zu tun.

bearbeitet von willy-goergen
Link zu diesem Kommentar
  • 2 Wochen später...
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...