Aus gegebenen Anlass werfe ich mal wieder das Problem in die Runde das gerade abgelaufene JAVA Updates bei Verteilung der .msi via WPP nicht deinstalliert werden wenn eine neue Version erscheint.
Die erste Frage wäre: Wieso ist das so, schließlich kommt das bei der normalen Installation nicht vor. Wäre gut das herauszubekommen, denn alle separaten Deinstall Lösungen sind eigentlich nur arbeitsaufwendige Workarounds.
Da es mehrere Möglichkeiten bei JAVA gibt- ich benutzt den Weg die .msi zu extrahieren und ein modifiziertes .mst zu generieren was ich in WPP dann mit auf dem Weg gebe.
Mein alte Lösungsansatz Nr1 war immer das ich die abgelaufen Updates von "Genehmigt" auf " Zur Deinstallation genehmigt" gesetzt habe. Leider läuft dieses Update was dann ausgeführt wird seit einiger Zeit ins leere, JAVA bleibt installiert obwohl das Update durchläuft.
Lösungsvorschlag Nr2 war CustomUpdate/Deinstall MSI Produkt, dann hab ich mir den MSI Code von einer ClientInstallation ausgelesen und ein entsprechendes Update erzeugt. Das funktioniert irgendwie nicht immer. Außerdem ist das Aufwendig in der Erstellung und Pflege, ich hab auch noch 64bit JAVA.
Lösungvorschlag Nr3 war der Hinweis aus einem Posting, das man, sofern man seine Optionen in der CommandLine bei WPP einträgt, REMOVEOLDERJRES=1 eintragen kann. Find ich nicht schlecht, nur das ich lieber ein transformtes .mst File benutze.
Also hab ich in der msi nach REMOVEOLDJRES gesucht und bin im Table INSTALLEXECUTESEQUENCE fündig geworden, wo das zwei mal auftaucht. Einmal bei FINDRELATEDPRODUCTS und einmal bei REMOVEXSISTINGPRODUCTS. In beiden Fällen ist es Standardmäßig mit 1 belegt, trotzdem wird die alte Installation nicht entfernt. Kann mir das einer erklären?
Und es gibt noch ein paar Krücken ( install&uninstall.exe oder so) die alten Javas zu entfernen, aber eigentlich würde ich lieber herausbekommen was das ganze Problem eigentlich verursacht.
Ich verwende normalerweise keine Regeln bei .msi Installationen und bin damit immer gut und problemlos gefahren, frage mich aber ob es in diesem Fall von Bedeutung sein könnte.
by Pö
Die erste Frage wäre: Wieso ist das so, schließlich kommt das bei der normalen Installation nicht vor. Wäre gut das herauszubekommen, denn alle separaten Deinstall Lösungen sind eigentlich nur arbeitsaufwendige Workarounds.
Da es mehrere Möglichkeiten bei JAVA gibt- ich benutzt den Weg die .msi zu extrahieren und ein modifiziertes .mst zu generieren was ich in WPP dann mit auf dem Weg gebe.
Mein alte Lösungsansatz Nr1 war immer das ich die abgelaufen Updates von "Genehmigt" auf " Zur Deinstallation genehmigt" gesetzt habe. Leider läuft dieses Update was dann ausgeführt wird seit einiger Zeit ins leere, JAVA bleibt installiert obwohl das Update durchläuft.
Lösungsvorschlag Nr2 war CustomUpdate/Deinstall MSI Produkt, dann hab ich mir den MSI Code von einer ClientInstallation ausgelesen und ein entsprechendes Update erzeugt. Das funktioniert irgendwie nicht immer. Außerdem ist das Aufwendig in der Erstellung und Pflege, ich hab auch noch 64bit JAVA.
Lösungvorschlag Nr3 war der Hinweis aus einem Posting, das man, sofern man seine Optionen in der CommandLine bei WPP einträgt, REMOVEOLDERJRES=1 eintragen kann. Find ich nicht schlecht, nur das ich lieber ein transformtes .mst File benutze.
Also hab ich in der msi nach REMOVEOLDJRES gesucht und bin im Table INSTALLEXECUTESEQUENCE fündig geworden, wo das zwei mal auftaucht. Einmal bei FINDRELATEDPRODUCTS und einmal bei REMOVEXSISTINGPRODUCTS. In beiden Fällen ist es Standardmäßig mit 1 belegt, trotzdem wird die alte Installation nicht entfernt. Kann mir das einer erklären?
Und es gibt noch ein paar Krücken ( install&uninstall.exe oder so) die alten Javas zu entfernen, aber eigentlich würde ich lieber herausbekommen was das ganze Problem eigentlich verursacht.
Ich verwende normalerweise keine Regeln bei .msi Installationen und bin damit immer gut und problemlos gefahren, frage mich aber ob es in diesem Fall von Bedeutung sein könnte.
by Pö