MSI Update mit gleichem ProductCode aber unterschiedlicher Version

Topics: Configuration Issue
Nov 12, 2015 at 2:24 PM
Edited Nov 12, 2015 at 2:41 PM
Hallo Zusammen,

wieder mal ein Problem welches ich nicht alleine lösen konnte. Für eine Software möchte ich ein Update einrichten (mit einer MSI Datei samt CAB Datei).

Egal ob das Update als "ersetzendes Update" oder "separates Update" eingerichtet wird, es wird nicht installiert.

Im Bericht zeigt der WPP dafür an, dass das Update schon installiert wäre - obwohl es nicht durchgeführt wurde. Mir ist dann aufgefallen, dass der MSI ProductCode bei der alten und der neuen Version identisch ist.

Evtl. wird deswegen auch die Installation des Updates nicht durchgeführt?

Wenn ich die alte Version deinstalliere, wird die neue Version durch den WPP installiert... somit scheint meine Theorie zu stimmen (den das Update funktioniert ja).

Man müsste also das Update irgendwie über die Regeln eingrenzen. Dort habe ich gesucht und probiert aber nichts hat wirklich funktioniert.

Prinzipiell pflegen die MSI Dateien einen Wert "ProductVersion" und "Build Nummer". Hiermit könnte man evtl. in den Regeln eine "if else" Eingrenzung machen - im WPP habe ich hier aber kein entsprechendes Feld gefunden.

Evtl. geht es auch über das Datum - nur weiß ich ehrlich gesagt nicht welche Datei ich hierzu auswählen soll´etc....

Kann mir hier jemand helfen wie ich dies in den Regeln definieren muss?

Danke

Gruß Markus
Nov 12, 2015 at 2:30 PM
nochmal ich

Mein erster Workaround war zunächst die alte Version zur Deinstallation freizugeben. Mit dem nächsten Update wurde auch die alte Version deinstalliert. Mit dem nächsten Updatelauf dann die neue Version installiert.

Man musste hierzu natürlich zweimal hintereinander das Update aufrufen - was im Echtbetrieb eher kontraproduktiv wäre.

Dann viel mir allerdings auf, dass mit dem nächsten Updatelauf auch wieder die Deinstallation durchgeführt wurde (war ja noch nicht abgelehnt).

Also hätte ich hier einen schönen Deinstallation / Installationskreislauf ;-)
Editor
Nov 12, 2015 at 3:08 PM
Du kannst dir dieses HowTo dazu anschauen: http://www.wsus.de/chrome_per_wpp

Als Alternative wäre evtl. auch Uninstall2Install etwas für dich: http://www.wsus.de/uninstall2install Denk dir das Java weg, dafür deine Anwendung rein: http://www.wsus.de/uninstall2install
Nov 13, 2015 at 3:13 PM
Edited Nov 13, 2015 at 3:17 PM
Vielen Dank für die Unterstützung.

Ich probiere momentan die erste Lösung - scheitere aber anscheinend an dem Regelwerk.

Im Prinzip reicht mir doch eigentlich eine einzige UND Schleife

beim ersten Regelfenster gebe ich ein, dass nachgeschaut wird ob
  • das MSI Paket Installiert ist
  • die Datei existiert
  • die Version kleiner x ist
Also:

<lar:And>
<msiar:MsiProductInstalled ProductCode="{xxxxxxxxx}"/><bar:FileExists Path="Ordner1\Ordner2\programm.exe" Csidl="42"/><bar:FileVersion Path="Ordner1\Ordner2\programm.exe" Comparison="LessThan" Version="1.2.3.4567" Csidl="42"/></lar:And>

das muss ich doch nicht in drei einzelne UND Schleifen packen - oder etwa schon?


Beim zweiten Regelwerk setzte ich dann beim MSI Paket ein <lar:Not> ... </lar:Not> um die Regel umzukehren


Bisher haben meine Einstellungen aber noch nicht geklappt.

Eine allgemeine Frage:
Ich gehe davon aus, dass im ersten Regelfenster Regeln eingegeben werden die danach suchen ob das Programm vorhanden ist und im zweiten Regelfenster Regeln eingegeben werden ob das Update benötigt wird.

Vielleicht liegt hier auch mein Fehler?!?

Gruß und schönes Wochenende Markus
Editor
Nov 13, 2015 at 4:57 PM
Im ersten Teil legst Du fest, ob das Update schon installiert ist. Im zweiten Teil legst Du fest, ob das Update installiert werden kann.

Das Update ist installiert, wenn die Dateiversion gleich mit deiner ist. Das Update kann installiert werden, wenn die vorhandene Dateiversion kleiner ist als die, die das Update hat.
Nov 17, 2015 at 1:04 PM
Edited Nov 17, 2015 at 2:09 PM

*** lest gleich den nachfolgenden Post :-) ***

Vielen Dank für den Hinweis - ich bin nun einen Schritt weiter - er bietet das Update nun an. Allerdings kommt bei der Installation relativ schnell die Meldung "Die Updates wurden installiert - nicht benötigte Updates: 1 Update". Das Update wurde nicht installiert. Im Status des WPP kommt die Meldung "Fehlgeschlagen". Das Update wird bei einer erneuten Suche wieder angeboten.

Wo kann es nun haken - kann man sich irgendwo noch mehr Informationen (Log Dateien) holen um die Ursache genauer festzustellen?

Im Prinzip wird es als Update erkannt - aber bei der Installation wird es als "nicht benötigt" eingestuft!?!


Zu Übersicht

Folgendes ist eingestellt:

Erstes Regelwerk (Update vorhanden?)

UND Verknüpfung innerhalb der Update level rules:
  • Regel für die Dateiversion - wenn diese gleich der Version 6.8.0.1759 ist
Zweiten Regelwerk (Update installierbar?):

UND Verknüpfung innerhalb der Update level rules:
  • Regel ob die exe Datei existiert
  • Regel für die Dateiversion - wenn diese kleiner der Version 6.8.0.1759 ist
Unter Package level rules wurden der jeweilige Eintrag gelöscht. Seit dem Update auf die Version 1.3.1511.15 werden dort Einträge gesetzt wenn das Update eine MSI Datei ist. Bleiben diese Einträge gesetzt, wird das Update nicht angeboten.

Ich habe generell mit vielen Optionen schon probiert aber kam entweder zu dem Ergebnis, dass das Update nicht angeboten wurde oder als nicht benötigt eingestuft wurde...

Gruß Markus
Nov 17, 2015 at 2:06 PM
Edited Nov 17, 2015 at 2:20 PM
Hallo zusammen,

ich habe eine Lösung gefunden.

Die von mir erstellten Regeln haben gepasst - allerdings erwies sich die Installation über die MSI Datei als "zickig".

Ich habe das ganze jetzt über die Exe Datei gestartet und es funktioniert (da man hier entsprechende Befehlsparameter setzen kann)

Das einzige Problem was ich jetzt noch habe, dass die "unbeaufsichtigte" Installation die ich über die Parameter eingestellt habe einen Neustart des PCs im laufenden Betrieb macht....

Ich suche momentan in den nicht vorhandenen Dokumentationen ob es hier auch eine alternative zu dem Parameter gibt.

Gibt es hier eine Möglichkeit aus dem WPP einen Neustart zu unterdrücken?


Bzw. gibt es die Möglichkeit die Installation über eine Batch Datei anzustoßen? Soweit ich bisher rausgefunden habe, gelingt es dem Setup nicht das Programm zu schließen wenn es noch aktiv ist. Ich möchte quasi eine Batch Datei schreiben um vorher das Programm zu beenden... und dann erst die Installation zu machen


Gruß Markus
Editor
Nov 17, 2015 at 4:24 PM
Edited Nov 17, 2015 at 4:26 PM
Schön das Du eine Lösung gefunden hast. ;)

Wird denn auch neugestartet, wenn Du das uns unbekannte Programm manuell SILENT installierst? IMHO gibt es immer einen /NORESTART Parameter. Wenn nicht, dann würde ich mich an den Support des Herstellers wenden.

Natürlich kannst Du auch alles über eine Batch anschieben, besser wäre es allerdings mit dem Hersteller sprechen. Der kann dir sicherlich weitere Parameter/Optionen im MSI nennen um dein Ziel zu erreichen. Auch findet es der Anwender bestimmt nicht toll, wenn das Programm plötzlich beendet wird und evtl. offene Eingaben nicht gespeichert werden.

Ansonsten schau dir die Möglichkeit des Custom Update an, dort kannst Du vorher Dienste/Prozesse beenden, natürlich auch die Benutzer informieren oder auf Antwort der Benutzer warten. Einfacher wird das dann allerdings nicht. Dazu gibt es auch eine Dokumentation.
http://wsuspackagepublisher.codeplex.com/documentation

EDIT: Informiere auch den Hersteller bezglich des Produktcode im MSI. Das sollte er unbedingt korrigieren!
Nov 18, 2015 at 12:48 PM
Ich bräuchte nochmal die Hilfe der Experten.

Da meine erste Lösung sehr umständlich erscheint (und auch ist) - und auch den Nachteil hat, dass aktive Prozesse deaktiviert werden müssen und der PC ohne Vorwarnung neustartet, suche ich noch einen perfekteren Weg.


Es gibt für das Update eine MSP Datei - lokal gestartet führt die Datei ein Update aus ohne Neustart oder den Prozess gewaltsam beenden zu müssen. Sozusagen wäre diese Datei perfekt.

Leider wird sie aber vom WPP nicht akzeptiert, bzw. kommt im letzten Fenster des Assistenten folgende Fehlermeldung:

"An error accourred while checking the meta data of the file you are trying to publish. This Problem occurs mostly in Publishing invalid MSI or MSP files."

Aktiviere ich das Häkchen "Anwendungbarkeitsmetadaten bearbeiten (Nur für erfahrene Benutzer)" und klicke auf "Bestätigen" werden für alle 31 Elemente der Metadaten ein Fehler ausgegeben.

Das Element 'http://www.microsoft.com/msi/patch_applicability.xsd:TargetLanguage' ist ungültig - Der Wert '0,1033,1043,2057,1036,1031,1040,1045,1034' ist gemäß seinem Datentyp 'http://www.microsoft.com/msi/patch_applicability.xsd:ValidateLanguage' ungültig -- Die Zeichenfolge '0,1033,1043,2057,1036,1031,1040,1045,1034' kein gültiger Int32-Wert..

lösche ich alle Metadaten - kommt bei der Installation leider auch eine Fehlermeldung...


Hier mal ein Auszug der Metadaten


<msiar:MsiPatchMetadata>
<MsiPatch xmlns="http://www.microsoft.com/msi/patch_applicability.xsd" SchemaVersion="1.0.0.0" PatchGUID="{6017626C-A4E7-4214-893B-B955CDFAA1E4}" MinMsiVersion="3">

<TargetProduct MinMsiVersion="200">
        <TargetProductCode Validate="true">{831ADA8C-C73B-4915-AF8D-83D22BD58AA8}</TargetProductCode>
        <TargetVersion Validate="true" ComparisonType="Equal" ComparisonFilter="MajorMinorUpdate">6.6.2700</TargetVersion>
        <UpdatedVersion>6.8.3180</UpdatedVersion>
        <TargetLanguage Validate="false">0,1033,1043,2057,1036,1031,1040,1045,1034</TargetLanguage>
        <UpdatedLanguages></UpdatedLanguages>
        <UpgradeCode Validate="true">{8E9E5B2B-6216-4D98-A792-979326435833}</UpgradeCode>
    </TargetProduct>

    ... 

    <TargetProduct MinMsiVersion="200">
        <TargetProductCode Validate="true">{831ADA8C-C73B-4915-AF8D-83D22BD58AA8}</TargetProductCode>
        <TargetVersion Validate="true" ComparisonType="Equal" ComparisonFilter="MajorMinorUpdate">6.8.3175</TargetVersion>
        <UpdatedVersion>6.8.3180</UpdatedVersion>
        <TargetLanguage Validate="false">0,1033,1043,2057,1036,1031,1040,1045,1034</TargetLanguage>
        <UpdatedLanguages>1034</UpdatedLanguages>
        <UpgradeCode Validate="true">{8E9E5B2B-6216-4D98-A792-979326435833}</UpgradeCode>
    </TargetProduct>

    <TargetProductCode>{831ADA8C-C73B-4915-AF8D-83D22BD58AA8}</TargetProductCode>

    <SequenceData>
        <PatchFamily>831ADA8CC73B4915AF8D83D22BD58AA8</PatchFamily>
        <Sequence>8.3175.21893.51393</Sequence>
        <Attributes>1</Attributes>
    </SequenceData>

</MsiPatch>
</msiar:MsiPatchMetadata>


Bisher habe ich mich da nicht rangetraut - aber vielleicht hat ja jemand einen Tipp für mich.

Gruß Markus
Editor
Nov 18, 2015 at 1:24 PM
Weshalb wendest Du dich nicht an den Hersteller der Anwendung? Der ist dein Ansprechpartner.

Die Fehlermeldung ist recht eindeutig:

Das Element 'http://www.microsoft.com/msi/patch_applicability.xsd:TargetLanguage' ist ungültig - Der Wert '0,1033,1043,2057,1036,1031,1040,1045,1034' ist gemäß seinem Datentyp 'http://www.microsoft.com/msi/patch_applicability.xsd:ValidateLanguage' ungültig -- Die Zeichenfolge '0,1033,1043,2057,1036,1031,1040,1045,1034' kein gültiger Int32-Wert.

In einem Integer Wert gibt es nun mal nur Zahlen und keine Kommas. Zusätzlich ist der Wert auch viel zu groß für ein Integer Feld.
Nov 30, 2015 at 10:19 AM
Edited Nov 30, 2015 at 2:12 PM
Hallo Winfried,

so als Abschlusszusammenfassung.

Ich habe mich an deinen Rat "mich an den Hersteller zu wenden" versucht und die letzten Tage "etwas" telefoniert. Da ich bereits schonmal die Ehre hatte mit der Hotline zu telefonieren wusste ich eigentlich schon vorher wie das endet.

Die Supporthotline der Telefonanlage kann mir auf die genannte Fehlermeldung keine Antwort geben - da sie ja nur die Software zur Verfügung stellen - die zwar Geld kostet - aber da wir in unserem Fall eine andere als die empfohlene Installationsvariante wählen sie hier keinen Support geben (können).

Auch der Hersteller der Anlage (Alcatel) verweist im Support auf den gleichen Ausspruch - zu den Entwicklern ist kein durchkommen (dazu sind wir als Endkunde zu trivial). Man verweist letztendlich auf eine wesentlich teurere Alternative (Client/Server Lösung) und auf die Installationsmethode via GPO (wo ich auch nicht weis ob diese letztendlich funktioniert).

Ich werden jetzt noch deinen Rat mit Uninstall2Install ausprobieren (welches übrigens bei Java toll funktioniert) ansonsten bleibt nur die enttäuschende manuelle Installation

Gruß Markus

UPDATE:
Leider bringt mir auch das Unistall2Install nichts.

Laut Anleitung macht das Script folgendes:

Msiexec.exe /i {Name der MSI} /qn

für meine Installation bräuchte ich allerdings folgendne Befehl

Msiexec.exe /update {Name der MSP} /qn

Dieser Befehlt hat zumindest so auf der Kommandozeile funktioniert - echt ärgerlich wenn man zwar eine MSP Datei hat diese aber (richtigerweise) vom WPP nicht akzeptiert wird weil die Entwickler gepfuscht haben___
Editor
Dec 8, 2015 at 9:24 PM
Hmm, Du könntest natürlich in einem Batch den Aufruf eintragen und die Batch als Computerstartupscript laufen lassen. Oder die Batch im WPP als Custom Update einbinden.
Dec 14, 2015 at 7:51 AM
Hallo Winfried,

vielen Dank für die Idee - nach ein paar Tests und Überlegungen stehe ich wieder mal auf dem Schlauch.... und bräuchte wieder eure Erfahrung und/oder Hilfe ;-)
  1. Ich erstelle eine Batch Datei
    -- in dieser steht nichts anderes als: "Msiexec.exe /update {Name der MSP} /qn"
  2. Im WPP erstelle ich ein Custom Update
    -- dort wähle ich die Option "Allow to execute a file"
  3. Ich gebe den Pfad vor (oder auch die Datei!?) und keinen Parameter (der steht ja in der Batch)
  4. Im Updatefenster füge ich dann die Batchdatei und die MSP Datei hinzu
    -- und danach ist es ja der "normale" Ablauf
Aber irgendwie klappt das nicht - das Update wird zwar angezeigt aber die Datei nicht ausgeführt - was mache ich hier falsch? Mit den benutzerdefinierten Updates habe ich erst recht keine Erfahrung - muss ich hier noch weitere Punkte hinzufügen? Knackpunkt ist wahrscheinlich auch der Datenpfad?!?

Mal wieder vielen Dank im voraus

Gruß Markus
Editor
Dec 14, 2015 at 7:37 PM
Hi,

auf keinen Fall darfst Du mit Laufwerksbuchstaben arbeiten! Immer mit UNC-Pfaden. \Server\Freigabe\Datei Und achte darauf, dass auch die Authentifizierten Benutzer Leserechte auf die Freigabe haben. In den Authentifizierten Benutzern sind auch alle Computerkonten enthalten.

Im Punkt 3 gibst Du den UNC-Pfad zur Batch an, zumindest hab ich das noch so im Kopf, richtig?
Die Batch brauchst Du IMHO nicht im Updatefenster erneut angeben.

In %windir%\Temp gibt es AFAIR auch eine Logdatei von den Custom Updates. Schau auch mal dort hinein. Ich hab das nur einmal versucht und mir dann meine eigene Uninstall2Install.exe erstellt. ;)