14 replies to this topic

[AlexMueller]

:huh: Ich bin mir ganz sicher, daß der Windows Installer 3.1 einen Kompatibilitätsbruch zum früheren Windows - Installer mitbringt, ich weiß nur noch nicht, woran genau das liegt.

Der Hintergrund: Ein Kunde von mir arbeitet mit reinem Windows 2000, ein Server, viele Clients. Software verteilen wir per Gruppenrichtlinie, ich baue MSI - Dateien, und verteile die damit. Die MSI - Dateien erstelle ich mit dem Visual Studio Installer von Microsoft, ein kleines Add-On zum Visual Studio 6, was kaum einer kennt, weil es nur recht versteckt bei Microsoft zum Download angeboten wurde.

Seit gestern abend weigert sich der Gruppenrichtlinien - Dialog urplötzlich, meine MSI - Dateien anzunehmen, obwohl sich nur eine Winzigkeit in der Datei verändert hat. Was konnte es sein ? Ich nahm eine andere MSI - Datei von einer anderen Zweigstelle, die dort einwandfrei verteilt wurde ... auch die wurde nicht mehr akzeptiert. Die Fehlermeldung lautete: "Das Hinzufügen ist fehlgeschlagen. Die Bereitstellungsinformationen konnten vom Paket nicht abgerufen werden. Stellen Sie sicher, daß das Paket richtig ist."

Was konnte es sein ? Irgendwas mußte von Betriebssystemseite anders sein als letzte Woche. Und klar, ich hatte gerade per Microsoft Windows - Update den Server gepatcht, hatte alle "wichtigen Updates" aufgespielt. Was für ein Zufall, daß ich mich daran erinnerte, daß auch der WinInstaller 3.1 in den letzten Tagen von Microsoft verteilt worden ist.

Also habe ich ihn manuell deinstalliert, in der Software-Übersicht wird er als "Windows Installer" aufgeführt. Und siehe da, danach wurde mein Paket wieder angenommen.

Die Deinstallation war allerdings etwas seltsam, ich bekam gesagt, daß mehrere andere Patches dann auch wieder entfernt werden, und der Server hing sich beim Runterfahren auf.

OK, jetzt beschäftigt mich natürlich die Frage: Was kann das für eine Inkompatibilität sein ? Kann es ein Property oder so etwas ähnliches sein ? Vielleicht ist es auch nur ein Merge-Modul oder so etwas ? Kann man das debuggen, oder systematisch herausfinden ?

Der Link mit Detailinfos von Microsoft, den Stefan Krueger auf der Startseite anbietet, ist leider kaputt.

Ich werde weiter forschen, und wäre dankbar, wenn jemand anders auch etwas dazu beitragen kann.

Alex Müller
www.a-m-i.de

[Meyer]

HI.

Wir hatten das gleiche Problem.
Wir hatten in dem Projekt eine Verknüpfung erzeugt, welche auf eine .EXE zeigte.

Diese .EXE liegt unter allen Workstations auf Laufwerk P:
Dies ist ein Netzlaufwerk. Wir hatte allerdings vergessen dieses Laufwerk auch auf dem Server zu mappen.

Evtl. ist es bei dir ja das gleiche Problem ?

[Stefan Krueger]

Der Knowledge Base Artikel und auch der Download scheinen im Moment bei Microsoft nicht verfügbar zu sein. Ich verusche herauszufinden, warum.

[AlexMueller]

Hallo Meyer,

nein, ich arbeite grundsätzlich so, daß ich mich bei der Angabe der MSI - Datei durchhangele von \\SERVERNAME\... bis zur Datei.

Man kriegt ja auch ne Warnung, wenn mans nicht so macht.

Trotzdem danke für den Tip.

Nein, es ist ausgeschlossen, daß es ein Flüchtigkeitsfehler war, ich habe an mehreren Standorten den Beweis, daß es der WinInstaller 3.1 sein muß.

[Stefan Krueger]

Ich weiss nicht ob es damit zusammenhängt, aber Microsoft hat den MSI 3.1 vorübergehend vom Netz geneommen wegen irgendwelcher Probleme (siehe aktuelle Meldung)

[AlexMueller]

Danke für den Link an Stefan Krueger. Ich kann mir aber nicht vorstellen, daß das von Microsoft beschriebene Problem mit meinem Zusammenhängt.

Microsoft sagt, es liegt an der Windows File Protection, und Pakete, die DLLs enthalten, die von der WFP betroffen sind, machen den Ärger. In der Tat enthält mein Paket jede Menge solcher DLLs, und zwar die ganzen runtime - DLLs von Visual Basic und Visual C++. Aber: Ich habe praktisch nur MSMs eingebunden, die offiziell von Microsoft kommen. Ich kann mir echt nicht vorstellen, daß diese "offiziellen" MSMs nicht durch die WFP durchkommen, denn auf welchem Betriebssystem wären die denn dann noch nutzbar ?

Außerdem: Ich hätte logisches Verständnis für ein Verhalten, daß ein Zielrechner das Paket per GPO installiert kriegen soll, und sich weigert wegen WFP. Aber: Ich kriege ja schon eine Fehlermeldung, wenn ich nur versuche, das Paket in die GPO einzufügen; zu dem Zeitpunkt ist doch noch gar nicht klar, auf welche Bestriebssysteme das Paket drauf soll.

Also bin ich mal gespannt, wie sich die Sache weiterentwickelt. Ich helfe mir zur Zeit mit manueller Deinstallation des MSI 3.1, aber das ist auf Dauer auch keine Lösung.

[Stefan Krueger]

[AlexMueller]

Bei Windows XP Clients gibt es offensichtlich noch ein zusätzliches Problem, die beschriebene Umgehung funktioniert dort nicht.

Ich bekomme den Windows Installer 3.1 dort ganz offensichtlich nicht in der Software - Liste angezeigt, kann ihn also auch nicht manuell deinstallieren. Ich habe bisher nur einen XP Client untersucht, wir haben fast keine, aber hier war es definitiv der Fall, daß unter "Windows Installer 3.1" kein Eintrag da war. An diesem Standort ist der 2000 - Server bereits auf den alten WinInstaller reduziert worden, und das Paket wird unter Windows 2000 Clients wieder erfolgreich verteilt.

Der XP - Rechner, in derselben GPO, bekam das Paket früher immer, und bekommt es jetzt nicht mehr. OS - mäßig steht er auf "Auto-Update". Er muß also den neuen WinInstaller 3.1 haben.

[Stefan Krueger]

Hast du das Häkchen bei "Updates zeigen" gesetzt?

[AlexMueller]

Zum WinXP: Dort gibt es das Häkchen gar nicht im oberen Teil der Softwareliste, obwohl ich als "Administrator" angemeldet bin. Seltsam.

Ich habe heute den MSI 3.1 V 2 runtergeladen und auf meinem eigenen System getestet (Win2003 SP1), dort konnte ich das Paket, welches beim Kunden nicht angenommen wurde, in die Gruppenrichtlinie einfügen. Ein gutes Zeichen.

Der Kunde hat Win2000 SP4, insofern steht dort ein Test noch aus.

Ich sag Bescheid, wenn ich es getestet habe, voraussichlich letzte Mai - Woche ("Never change a running system", hähä).

[Stefan Krueger]

[AlexMueller]

Zum XP: Sehr guter Hinweis, werde ich prüfen, kann ich mir aber nicht vorstellen, weil (wie gesagt) "AutoUpdate" eingestellt ist, und das SP2 ja dabei auch mitkommt, wenn ich mich nicht ganz irre.

Interessant: Microsoft bietet den WinInstaller 3.1 (V2) unter der Versionsnummer 3.1.4000.2435 an.

Letzte Woche habe ich auf meinem Notebook (Win 2003 SP1) per AutoUpdate die Aufforderung erhalten, den WinInstaller 3.1 (ohne weitere Angaben) zu Installieren als wichtiges Update. Hab ich heute getan. Ich bekam die Version 3.1.4000.1823 installiert und habe jetzt das Gefühl, daß die fehlerhafte V1 noch verteilt wird .... also Vorsicht. Wenn ich mehr weiß, sage ich Bescheid.

[AlexMueller]

OK, ich habs versprochen, also berichte ich auch ausführlich.

Der GAU ist eingetreten, es sieht aus, als seien die Schäden durch den neuen Installer irreparabel.

Zur Erinnerung: Bis Anfang Mai, als der Installer 3.1 V1 automatisch per Windows-Update auf den Server kam, haben wir viele Jahre unsere Software erfolgreich über die GPOs verteilt.

Ich habe also diese Woche eine neue Verteilung anstossen müssen, und habe zunächst einmal versucht, den Installer 3.1 V2 auf dem Server zu installieren. Danach den Server gebootet, die alten Pakete raus aus der GPO, die neuen rein, und die Clients testweise gestartet. Das Fatale: Die alten Pakete werden deinstalliert, jedoch wird die neue Version nicht installiert.

Also, der vorerst letzte Rettungsversuch: manuelle Deinstallation des Windows Installer 3.1 aus der "Sofware" - Liste heraus, neu booten. Zunächst die Analyse der Datei msiexec, sie erscheint in der Version 2.6, so wie auch auf einem "frischen" Win2000 SP4 - System.

Doch der Fehler bleibt derselbe. Der Client zeigt ganz kurz an "XY wird installiert", aber das wars dann. Im Eventlog finden sich folgende Informationen (in dieser historischen Reihenfolge):
- Hinweis, daß die GPO entdeckt wurde und angewendet werden soll
- ID 102: "Die Installation der Anwendung X in der Richtlinie Y ist fehlgeschlagen. Fehler: Die Installationsquelle für dieses Produkt ist nicht verfügbar. Stellen SIe sicher, daß die Quelle vorhanden ist, und Sie Zugriff darauf haben"
- ID 108: "Die Änderungen an den Softwareeinstellungen wurden nicht angewendet. Änderungen an der Software konnten nicht übernommen werden."
- ID 1000: "Die clientseitige Erweiterung 'Anwendungsverwaltung' der Gruppenrichtlinie empfing Flags(1) und hat einen Fehlerstatuscode (1612) zurückgegeben"

Dabei ist mir der 1612 durchaus bekannt, den habe ich in der Vergangenheit meist mit korrektem DNS beheben können.

Aber hier ist alles anders; ich habe überprüft:
- DNS ist absolut sauber, es gibt nur je einen Server pro Standort, und der ist per IP-Adresse als einziger eingetragen.
- Quelle ist auch OK. Ich habe stets voll qualifizierte Pfade benutzt in der Form \\<IP-Adresse>\Freigabe\Paket.msi
- Berechtigungen sind auch clean. Es ging ja auch früher immer, aus derselben Quelle. Ich habe sicherheitshalber auch noch "Authentifizierte Benutzer" und "Domänen-Computer" als Berechtigung im Freigabepfad reingenommen, alle Clients sind member der Domäne.
- Ich habe auch testweise eine ganz neue GPO angelegt und es damit probiert, aber auch das schlug fehl.

Nebenbei, es waren 90 / 50 PCs an den beiden Standorten, die ich dann von Hand installieren durfte, damit am nächsten Morgen die Produktion weitergeht. So was prägt :-)

Was bleibt zu tun ?

Alternative 1: Ein Microsoft Support - Call war meine erste Idee. Unterstützen die Win2000 noch ? Aber wenn wir das machen, dann sind erfahrungsgemäß etliche Experimente in verschiedenen Sitzungen nötig (man holt sich Rat in Amerika, da wird aber gerade nicht gearbeitet ...), und das fatale ist ja, das die Deinstallation immer funktioniert, aber nur die :-(

Alternative 2: Meine eigentliche Anwendung, eine EXE, ist nur ein Link auf eine freigegebene EXE auf dem Server. Was ich als MSI - Pakete verteile, sind die COM - DLLs. Ich werde also einen Startup - Code in die EXE einbauen, die die MSI - Pakete sozusagen beim Aufruf automatisch checkt und über den msiexec installiert, und erst dann weitermacht. Mal sehen, obs klappt. Problem wird die Berechtigung sein (Aufrufer-Kontext = minimale Berechtigung), aber auch das läßt sich lösen.

Vielleicht hat ja noch jemand anderes ähnliche Erfahrungen gemacht und kann hier etwas dazu sagen. Ich meld mich wieder.

[Cybot]

Hi!
Das klingt nach viel nerviger Arbeit! Dennoch finde ich die ausführliche Schilderung sehr gut (vielen Dank dafür) und ich bin sehr gespannt, ob es für das Problem eine Lösung gibt. Viel Glück!

[AlexMueller]

So, ich habe mich für Alternative 2 entschieden (Bootcode), und es funktioniert.

Und weil es ein Tag Arbeit war, habe ich mir gleich noch einen halben Tag dazu genommen, um die Technik einmal detailliert für die Nachwelt zu dokumentieren:

http://www.a-m-i.de/...nstallation.php

Da ich jetzt unabhängig von den Gruppenrichtlinien bin, und meine MSIs so oder so Zwangs-installiert werden, werde ich wohl (mit diesem sicheren Gefühl) trotzdem noch Alternative 1 durchziehen, weil es mich einfach interessiert, was da los ist.

Denn: Microsoft erstattet hinterher die Kosten eines Support - Falles zurück, wenn es sich bei der Problem-Ursache um einen Fehler von Microsoft handelt. Die Aussichten sind glaub ich nicht schlecht :-)

Ich sag Bescheid, wenns was neues gibt.

Alex Müller