[English]Der zum 19. Januar 2020 in der Desktop-Version für Linux, macOS und Windows in der Version 88.0.4324.96 herausgegebene Chrome-Browser lässt sich in der MSI-Variante wohl nicht auf frischen Systemen ohne ältere Chrome-Version installieren.
Anzeige
Sicherheit: Chrome 88.0.4324.96 schließt 36 Schwachstellen
Ich hatte im Blog-Beitrag Chrome 88.0.4324.96 fixt 36 Schwachstellen auf das Browser-Update hingewiesen. Beim Chrome 88 handelt es sich um einen neuen Entwicklungszweig, bei dem sowohl FTP- als auch Flash-Support entfallen sind. Zudem schließt dieses Sicherheitsupdate 36 Schwachstellen in den älteren Browserversionen.
MSI-Datei erzeugt Error 1722
Blog-Leser Bernie hat sich mit diesem Kommentar gemeldet und berichtet über einen Installationsfehler, den ich kurz aufgreifen möchte. In seiner Unternehmensumgebung wird der Chrome Browser automatisiert über ein Software Deployment Tool verteilt. Die automatischen Updates von Chrome über dessen Updater sind per GPO deaktiviert. Zur Installation der jeweils neuen Chrome-Versionen über das Software Deployment Tool wird eine für Unternehmen bereitgestellt MSI-Datei des Browsers verwendet. Im Einsatz sind Systeme mit Windows 10 Enterprise 1809.
Beim testweisen Ausrollen des neues Chrome 88.0.4324.96 mittels der MSI-Datei es auf zwei Windows 10 Testmaschinen gab aber plötzlich auf einem PC den Installationsfehler 1722. Bei Google gibt es diesen Thread zum Error 1722, der aber im aktuellen Fall nicht weiter half. Der Unterschied zwischen den beiden Testmaschinen war:
- System 1: Auf der Maschine mit Windows 10 Enterprise 1809 war die Vorgängerversion des Chrome-Browsers installiert; die Installation der Aktualisierung lief durch.
- System 2: Auf der Maschine mit Windows 10 Enterprise 1809 war noch kein Chrome-Browser installiert, die Installation des Chrome 88.0.4324.96 scheiterte dort mit dem Installationsfehler 1722.
Nach einigen Tests, bei dem auf System 2 dann ein Chrome 87 installiert wurde und dann der Chrome 88.0.4324.96 im Nachgang erfolgreich per MSI-Datei installiert werden konnte, steht fest, dass der MSI-Installer des Chrome 88.0.4324.96 wohl einen Fehler aufweisen muss. Der MSI-Installer der Chrome Version 87.0.4280.141 64-Bit legt unter
Anzeige
C:\Program Files (x86)\Google\Update
die Datei GoogleUpdate.exe ab und erzeugt diverse Unterordner. Der MSI-Installer des Chrome 88.0.4324.96 64-Bit macht dieses nicht. Als bei einem Testsystem mit dem betreffenden Fehler der 'fehlende Ordner' Update mit den fehlenden Dateien manuell von einem Testsystem auf den Zielrechner kopiert wurde, lief die MSI-Installation fehlerfrei durch. Danke an Bernie für die Hinweise. Vielleicht hilft es Betroffenen weiter.
Ergänzung: Gert weist in diesem Kommentar (danke dafür) darauf hin, dass inzwischen ein Bugreport Issue 1168614: Chrome standalone installer fails: GoogleUpdateHelper.msi is missingbei Google zu finden ist. Der Fehler dürfte also zeitnah korrigiert werden.
Ergänzung 2: Im Google Bug-Report findet sich der Hinweise, dass die Version 88.0.4324.104 des Chrome MSI-Installers funktioniere.
Anzeige
Auf dem Server 2019 (RDSH) lässt sich die msi ebenfalls nicht installieren.
Die Installation hängt bei "Windows Installer Coordinator".
Die GPO "Turn Off Windows Installer RDS Compatibility" schafft dabei keine Abhilfe.
Version 88.0.4324.96
GoogleChromeStandaloneEnterprise.msi
Upgrade über die vorige Chrome Version geht.
Dann warten wir mal auf ein Update..
Ich bin euch so dankbar! Das hat mich gestern irre gemacht – hab schon an mir selbst gezweifelt. Auch ich hatte bereits den Update Ordner manuell von einer anderen Maschine kopiert, aber nachdem ich die MSI gestartet habe, war der Update-Ordner plötzlich verschwunden und der Fehler trat wieder auf.
Generell habe ich festgestellt (seit Win10 pro 20H2), dass irgendwie msi-Dateien nicht so toll funktionieren. Ich habe es fast verdrängt, aber ich glaube bei Powertoys gab es auch Probleme. Irgendwie ging es dann trotzdem mit exe-Datei.
Und wenn ich mich ganz Dunkel erinnere, machen msi-Dateien mit Win10 (auch Versionen davor) des Öfteren irgendwelche Probleme.
Die MSI-Dateien für Chrome, Edge und auch Firefox sind KEINE MSI-Installer im eigentlichen Sinne sondern kapseln nur EXE-Installer. Das Problem liegt also nicht bei der MSI-Technik an sich, sondern nur daran, dass die aufgerufenen EXE-Programme nicht das tun, was sie sollen.
Hatte ich z. B. Mike Kaply (Mozilla) schon mal angetragen, im Bugtracker erhielt ich dann von einer anderen Mitarbeiterin die Antwort, das zu ändern passt nicht zum Build-Prozess und das wars dann auch.
Ist jetzt nicht so, dass es nicht machbar wäre. Ich pflege mittlerweile meinen eigenen echten(!) MSI-Installer für Firefox Release und ESR, quasi original, wenn auch manuell und derzeit nur für deutsche Lokalisierung erstellt (im Gegensatz zu FrontMotion, wo in den letzten Jahren häufiger irgendwelche Bugs drin sind, was aber den Anpassungen dort geschuldet ist). Wer Interesse hat kann von Günter sicher meine E-Mail-Adresse für den Kontakt bekommen.
Powertoys ist wieder eine andere Nummer, da wird per WiX (Windows Installer XML) ein Paket per Bootstrapper ausgeliefert (EXE-Installer, entpackt MSI + nötige Runtimes) und on-the-fly das MSI erstellt, ähnlich ist das z. B. bei den VC++ Runtimes. Das landet dann in "%programdata%\Package Cache". Dort könnte man sich das MSI für das Deployment rausklauen, zuletzt gab es aber zumindest bei den Powertoys wieder einen Parameter um das MSI zu extrahieren.
Knaller nebenbei (zum Thema Roaming Profiles): Es kam schon mehrfach vor, dass ein MSI-Installer benutzerbezogen in appdata\roaming z. B. Icons ablegt (obwohl der Installer selbst Dateien in den Programme-Ordner schreibt), die nicht über das Roaming-Profil synchronisiert werden können, weil die Sicherheitsberechtigungen keinen Vollzugriff für den Benutzer erlauben. Das tritt z. B. auch bei den Windows-ADMX-Paketen auf.
Ich hatte an anderer Stelle schon einmal gefragt:
Muss eine .msi unter Win 10 denn zwingend über die Eingabeaufforderung und wusa.exe installiert werden oder reicht ein Doppelklick auf die .msi-Datei?
Kopf kratz ob dieser Frage. So was kann man doch sehr einfach selbst testen …
Was passiert beim Doppelklick auf eine msi-Datei?
Rechtsklick und Installieren im Kontextmenü ist nicht verfügbar?
Der Laie staunt, der Fachmann wundert sich. Oder was habe ich an der Frage jetzt nicht verstanden?
Sorry…ich war gedanklich bei .msu (und nicht .msi) und habe das leider durcheinander gebracht.
Und dazu liest man meist:
"Um ein MSU-Updatepaket zu installieren, führen Sie "Wusa.exe" mit dem vollständigen Dateipfad aus."
Konkret meine ich z.B. das Update für das Entfernen von Adobe Flash Player vom 27. Oktober 2020 (KB4577586).
Dieses lässt sich ja bereits aus dem Windows Update Catalog herunterladen (aber halt als .msu). Und ich wusste nicht, ob man dieses per Doppelklick installieren kann (ich meine, dies unter Win 7 schon so gemacht zu haben), oder, ob man es zwingend über die wusa.exe und die Eingabeaufforderung installieren muss.
Und, hast Du mal eine .msu-Datei (eigenständiges Update-Installer-Paket) per Doppelklick angewählt?
Ich habe erinnerungsmäßig .msu-Dateien immer per Doppelklick installieren lassen. Bin aber unter W7 unterwegs und boote jetzt kein Win10, um zu testen.
Einig wo man fummeln muss, sind .cab-Dateien.
Aber das Ganze wird jetzt arg off topic und müllt den Kommentar-Thread hier zu.
Geht alles ganz easy per Doppelklick, noch eventuell eine Bestätigung in der "Benutzerkontensteuerung" und es flutscht. Wenn man dann Glück hat, ist alles installiert.
Bei *.cab-Dateien ist bisschen fummelei nötig, macht man ja nicht jeden Tag.
Die MSI sollte, wenn richtig erstellt, selbst an passender Stelle nach den erhöhten Rechten fragen, was bei Exchange-MSP(!)-Dateien häufiger ein Problem ist. Sonst gibts keinen Unterschied, abgesehen von vielleicht nutzerbasierter Installation, was mit MSI auch möglich wäre.
Mit der neuen Version 88.0.4324.104 ist das Problem behoben.
Boah, ernsthaft… die 88.0.4324.96 habe ich doch erst verteilt.
Aber dank' Dir für die Info! :)