Gibt es bei Euch in der Blog-Leserschaft die Beobachtung, dass die Edge WebView2-Komponente Fehler bei der Installation aufweist? Mir ist ein entsprechender Bericht aus der Leserschaft zugegangen. Hintergrund ist, dass neuere Edge-Versionen per GPO steuern können, ob WebView2-Komponente bei Edge-Updates aktualisiert werden darf. Falsche Einträge in der Registrierung verhindern dann diese Installation und führen zu Fehlern. Ich stelle den Sachverhalt mal in einem Beitrag bereit, weil sicher weitere Leser tangiert werden könnten.
Blog-Leser Martin F. hat mich vorige Woche per Mail auf ein Problem angesprochen (danke dafür), was ihm im Zusammenhang mit dem Microsoft Edge-Browser und der WebView2-Runtime-Komponente aufgefallen ist. Dort ist die betreffende Installation schlicht – ohne weitere Fehlermeldungen – gescheitert. Die Analyse hat einen interessanten Sachverhalt zu Tage gefördert.
Probleme mit dem Edge WebView2-Update
Ausgangspunkt war ein Rechner mit Windows 10, der zum Upgrade auf Windows 11 "auf den Tisch des Lesers" kam. Nach dem erfolgten Upgrade des Windows 10 Rechners meldete die Windows 11 Einstellungen-App, dass noch ein Update für Edge WebView2 installiert werden sollte. Dieses Update wird also automatisch per Windows Update angeboten und auch ausgerollt.
Update wird immer wieder angeboten
Allerdings ging das Update des Edge WebView2-Pakets schief. Die Windows Update-Seite der Einstellungen-App zeigte zuerst den Download und die Installation des Pakets. Es wurde auch kein Installationsfehler ausgewiesen, aber mit der Installation schien was nicht geklappt zu haben. Denn das Update wurde gleich wieder per Windows Update in der Einstellungen-Seite angeboten. Ein Verhalten, was so mancher Windows-Nutzer von anderen Updates kennt. Der Installationsvorgang kann dann nicht die notwendigen Bereinigungen durchführen, um alles als abgeschlossen zu kennzeichnen.
Analyse des Problems per Event-Log
Martin schrieb, dass er sich die Ereignisanzeige angesehen hat, um einen Grund für die Update-Schleife zu finden. Er schrieb, dass in der Ereignisanzeige aufgelistet wurde, dass während der Installation ein DCOM-Prozess nicht gestartet werden konnte.
Da der Befehl zum Aufruf des DCOM-Prozesses im Klartext im Eventlog aufgeführt wurde, hat der Leser im Anschluss versucht, diese Prozess manuell unter Windows zu starten. Bei diesem Vorgang wurden dann fehlende C++-Runtime-Dateien als Problem aufgelistet.
Martin kam aber zum Schluss, dass die manuelle Ausführung des Befehls zum Aufruf des DCOM-Prozesses nicht vorgesehen war und ihn erstmal auf die falsche Fährte gelockt hatte. Denn die Aktualisierung der VC++-Runtime-Bibliotheken und auch der Store-VC++-Runtime-Bibliotheken half nicht weiter.
WebView2 manuell installieren
Der Leser hat dann WebView2 manuell von den Microsoft Servern (Microsoft Update Catalog) heruntergeladen und eine Installation angestoßen. Der Installer meldete, dass eine Gruppenrichtlinie die Installation der WebView2 blockieren würde. Der Leser schrieb dazu: "Nein, das wird in der Umgebung nicht über die 'üblichen' Einträge in den Gruppenrichtlinien blockiert." Das war also irgendwie auch nicht die Ursache für das Installationsproblem.
Ursache: Registry-Eintrag blockiert die Installation
Martin ist im Web auf die Ursachensuche gegangen und ist im WebView2-Feedback GitHub-Beitrag Cannot install install Webview2 – Group Policy prevents installation fündig geworden. Der Titel des Beitrags spiegelt ja bereits das oben skizzierte Problem wieder: Angeblich blockiert eine GPO die Installation, aber es gibt keine GPO, die dafür verantwortlich ist.
Ein Betroffener schrieb, dass er bei der Installation von Visual Studio 2022 Enterprise ebenfalls auf den WebView2-Installationsfehler getroffen ist. Im Microsoft Support-Beitrag Install (WebView) heißt es, dass ab Microsoft Edge Update 1.3.127.1 und höher über eine Policy gesteuert werden kann, ob die WebView2-Laufzeitumgebung über Microsoft Edge Update installiert werden darf. Es gibt in der Registrierung einen Wert:
Install{F3017226-FE2A-4295-8BDF-00C3A9A7E4C5}
der auf 1 gesetzt sein muss, damit die WebView2 Runtime beim Update mit installiert wird. Martin schrieb mir: Weil für die Einträge Update/Install der Wert auf „0" steht, wird die Installation blockiert. Er merkt an, dass man nun manuell diese Einträge auf 1 stellen könnte. Einfacher ist es, laut Leser, im Registrierungsschlüssel:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\EdgeUpdate
alle Einträge mit Install* und Update* (statt Default kann dort auch eine GUID dahinterstehen) zu löschen. Nachfolgender Screenshot zeigt die betreffenden Einträge in der Registrierung.
Das Löschen der Einträge bewirkt, dass der Wert undefiniert und nicht mehr auf 0 gesetzt ist, wodurch die Richtlinie bei der Installation nicht mehr gezogen wird. Schon werde das Update wie gewünscht installiert, führt der Leser aus.
Martin merkte an: "Mit der nächsten Gruppenrichtlinienaktualisierung werden die Werte, falls die Aktualisierung doch mutwillig blockiert wird, wieder eingetragen. Warum diese Einträge überhaupt drin sind, da müssten wir mal Bill Gates fragen." An dieser Stelle mein Dank an Martin F., dass er seine Erkenntnisse mit der Leserschaft geteilt hat – ich könnte mir vorstellen, dass auch weitere Leute in das Problem laufen.
MVP: 2013 – 2016
Bauch Gefühl: er muss sich selber fragen, nicht Bill.
wenn die Werte bei gpupdate wiederkommen, sind sie in seinen GPOs. da sollte er lieber in die Edge Update Steuerung schauen
Install{F3017226-FE2A-4295-8BDF-00C3A9A7E4C5} -> https://gpsearch.azurewebsites.net/#15347
Installation zulassen
Computer Configuration\Administrative Templates\Microsoft Edge-Update\Microsoft Edge WebView2-Laufzeit\
Wir hatten gestern auch einen identischen Fall.
Nach Windows Updates konnte ein User Microsoft Teams nicht mehr starten.
MS Teams gab immer die Meldung aus, dass die Edge WebView 2 fehlen würde und diese installiert werden muss. Klickt man dort auf den Link und startet den Download, wird die Installation abgebrochen. Die Fehlermeldung dazu lautet, das Edge WebView 2 bereits installiert ist.
Daraufhin habe ich in Foren auch den Tipp mit dem löschen des Registry Eintrags gefunden.
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\EdgeUpdate\Clients\{F3017226-FE2A-4295-8BDF-00C3A9A7E4C5}
Danach konnten wir Edge WebView erneut ohne Probleme installieren und Teams war auch wieder lauffähig.
Ich hatte bei der Installation der Oktober-Updates auf Win11 25H2 einen ähnlichen Fall.
In diesem Fall wurde ein Teil des Updates in das Roaming-Profil installiert. Dies führte zur Anzeige von falschen Versionen.
Eine Deinstallation oder Reparatur war allerdings nicht möglich, da die Pfade zur Deinstallation nicht stimmten.
Lösung war: Den aktuellen Installer (setup.exe) aus 'C:\Program Files (x86)\Microsoft\EdgeWebView\Application\14X.X.XXXX.XX\Installer' in den Pfad des Roamingprofils einfügen, der beim Deinstallationsversuch angezeigt wurde. Zum Teil musste ich neue Ordner im Roamingprofil erstellen, da diese natürlich nicht existierten.
Anschließend über Programme hinzufügen oder Entfernen die Deinstallation auswählen und dies auf ALLEN Clients ausführen, auf denen dieses Profil seitdem angemeldet war.
Bei WebView hat sich in den letzten Tagen einiges getan.
20.10. 141.0.3537.71
21.10. 141.0.3537.85
23.10. 141.0.3537.92
28.10.141.0.3537.99
Probleme haben wir bisher keine festgestellt, verteilen das Ganze über unsere Softwareverteilung.
Zitat:
"Angeblich blockiert eine GPO die Installation, aber es gibt keine GPO, die dafür verantwortlich ist."
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\EdgeUpdate
—
Das widerspricht sich, denn "Policies" sind GPOs.
Wenn man etwas an den GPOs ändert, dann wird das unter Policies in die Registry geschrieben.
Deswegen ist die Behauptung falsch nach dem ersten Komma ("aber es gibt keine GPO, die dafür verantwortlich ist.").
Für GPO-Regeln als Ursache spricht auch, dass diese Registry-Einträge erneut gesetzt werden, nachdem man sie manuell entfernt hatte.
Da muss der Admin nochmal, ran und diese GPOs finden und entfernen.
Vielleicht sind sie bei Computer und bei User gesetzt, aber der Admin hat nur in einem der beiden Zweige geschaut.
Vielleicht gibt es auch einen Task, der ein Script startet, welches dann diese Registry-Einträge setzt.
Ich vermute die den Bug haben sind noch auf einer alten "EdgePolicy" die aktuelle ist hier: (hier auch kein Bug vorhanden, die aktuell ist installiert, per WU)
https://msedge.sf.dl.delivery.mp.microsoft.com/filestreamingservice/files/7888c5bf-1925-4012-83c0-cfaf68f8b750/MicrosoftEdgePolicyTemplates.cab
Evtl. hilft es ja auch, die zum Edge-Updater zugehörige ADMX-Vorlagendatei im Central Store seines ADs zu aktualisieren. In meiner Doku konnte ich sehen, dass mit dem Edge Version 81 (~05/2023) auch die WebView2 "Update-Richtlinie" in der msedgeupdate.admx zu finden war. Edge/WebView2 lasse ich nicht per Updater aktualisieren, entsprechend habe ich per GPO die Einstellung "Überschreibung der Update-Richtlinie" aktiviert mit "Updates deaktiviert". Die Standardeinstellung ist deaktiviert und bedeutet "Wenn Sie diese Richtlinie nicht aktivieren, werden Updates automatisch heruntergeladen und angewendet". Eine alte ADMX im Central Store sorgt dafür, dass die Standardeinstellung aktiv ist und man diese nicht ein mal konfigurieren kann.
Du würdest die Registry Settings als "Zusätzl. Reg.-einst. / Extra Registry Settings" im Report sehen und kannst diese immer per Set-/Remove-GPRegistryValue in der Powershell konfigurieren
https://www.gruppenrichtlinien.de/artikel/bearbeiten-von-zusaetzliche-registry-einstellungen-edit-extra-registry-settings-arbeiten-ohne-gpeditor
Zur Klarstellung: Es sind diesbezüglich keine Einstellungen per Gruppenrichtlinie gesetzt, das Zeugs stand da "einfach so" drin. Habs gelöscht, kam auch nicht wieder. Danach war alles okay.