Microsoft beginnt, Windows Update für alle Drittanbieter-Apps zu öffnen

• Microsoft hat als Vorschau eine neue Plattform vorgestellt, die Windows Update auch für Updates von Drittanbieter-Apps öffnet
• Die neue Windows-Update-Orchestrierungsplattform ist dafür ausgelegt, alle Updates zentral zu verwalten, einschließlich Treibern und Business-Apps
• Update-Zeitpläne lassen sich anhand von Nutzeraktivität, Akkustand und Zeitfenstern mit umweltfreundlicher Energie optimieren
• Win32-, MSIX- und APPX-Apps werden unterstützt, und auch der Windows-Update-Verlauf umfasst App-Update-Historien
• Über die Grenzen von Microsoft Store oder Winget hinaus besteht die Möglichkeit, auch kundenspezifische Business-Apps einzubeziehen

---

Windows Update auf dem Weg zum Hub für alle App-Updates

• Microsoft hat kürzlich Pläne angekündigt, Windows Update über OS- und Treiber-Updates hinaus zu einer integrierten Update-Plattform für alle Apps auszubauen
• Diese Veränderung scheint insbesondere die Nachfrage in Unternehmensumgebungen nach einer zentralen Verwaltung auch interner Apps widerzuspiegeln

Überblick über die neue Orchestrierungsplattform

• Unter dem Namen Windows Update Orchestration Platform derzeit als Private Preview verfügbar
• Die Funktionalität von Windows Update wird erweitert, sodass auch App-Updates in die Terminplanung und Optimierung der Nutzererfahrung einbezogen werden

> „Wir bauen eine einheitliche intelligente Plattform, mit der sich jede Art von Update — Apps, Treiber und mehr — gemeinsam mit Windows Update orchestrieren lässt.“ — Microsoft-Produktmanagerin Angie Chen

Probleme bisheriger App-Update-Methoden

• Die meisten Windows-Apps betreiben je nach Hersteller eigene Update-Systeme
• Dadurch sind Update-Zeitpunkte und Qualität nicht konsistent
• Über den Microsoft Store lassen sich einige Apps zentral aktualisieren, viele Apps sind dort jedoch nicht gelistet oder es handelt sich um unternehmenseigene Anwendungen

Wichtige Funktionen und Vorteile

• Zeitplanung auf Basis von Nutzeraktivität, Akkustand und Zeitpunkten nachhaltiger Energieverfügbarkeit
• Integration in die Standard-Benachrichtigungs- und Verlaufs-UI von Windows Update
• Unterstützung für MSIX-/APPX-Apps sowie bestimmte Win32-Apps
• Erhält künftige Plattform-Updates automatisch
• Eröffnet die Möglichkeit, bestehende Installer zu ersetzen (z. B. könnten auch große Apps wie Adobe mit eigenem Hintergrund-Installer dazugehören)

Vergleich mit bestehenden Lösungen

Methode	Beschreibung	Wichtigster Nachteil
Microsoft Store	Verwaltet App-Installation und -Updates über den Store	Begrenzte Zahl gelisteter Apps, schwer für Business-Apps nutzbar
Windows Package Manager (winget)	Kommandozeilen-Tool für Paketinstallation und -Updates	Vor allem für Power-User und Entwickler, für normale Nutzer wenig verbreitet
Windows-Update-Orchestrierung	Kann neben OS/Treibern auch allgemeine App-Updates zentral integrieren	Derzeit noch in der Private-Preview-Phase

Ausblick

• Zunächst wird eine starke Nachfrage nach der Integration von Updates für Unternehmens-Apps erwartet
• Danach ist eine Ausweitung auf Adobe, Zoom und andere kommerzielle Software möglich
• Langfristig zielt die Richtung auf eine systemweite Vereinheitlichung von Updates ähnlich wie unter macOS

Microsoft verstärkt damit erneut den Versuch, die fragmentierte Erfahrung bei App-Updates zu vereinheitlichen, und ob Entwickler und Unternehmen aktiv mitziehen, dürfte zum Schlüsselfaktor für diesen Wandel im Ökosystem werden.

[GN⁺]

Hacker-News-Kommentare

• Unter Windows gibt es nach wie vor die Situation, dass Chrome Updates über einen speziellen Dienst abwickelt, um Probleme mit Rechteerhöhungen zu umgehen, und viele Apps wie Spotify weiterhin in AppData installiert werden; auch viele Deinstallationsprogramme funktionieren noch immer nicht richtig und hinterlassen Dateien oder andere Spuren. MSI verlangt außerdem dauerhaft, dass neue Schlüssel mit einem alten Schlüssel namens „Chain Signing“ signiert werden, was sich extrem schwierig anfühlt, wenn man Updates über einen Zeitraum von mehr als zehn Jahren verwalten muss. Hoffentlich wird das alles irgendwann sauber aufgeräumt.
  • Das Installations-/Update-Programm, das Chrome verwendet, ist das Open-Source-Projekt Omaha, und die anderen erwähnten Apps nutzen Squirrel. Beide können in AppData liegen (insbesondere Squirrel wird ausschließlich im Benutzerverzeichnis installiert). Die Philosophie von Squirrel ist, Benutzerinstallationen ohne Administratorrechte zu ermöglichen.
  • Der Grund für Installationen in AppData ist nicht, versteckt Rechteerhöhungen zu umgehen; Microsoft hat diese Art der Installation fast zehn Jahre lang empfohlen, und inzwischen halte ich Installationen in AppData für den „richtigen“ Weg, wenn ein Programm ohne Rechteerhöhung funktionieren kann.
  • Bei nicht containerisierten Apps mit Root-/Administratorzugriff halte ich es aus Sicht des Installers für nahezu unmöglich, Restdateien vollständig zu beseitigen. Solche Apps können in beliebigen Verzeichnissen Dateien anlegen und schreiben, und selbst Deinstallationsprogramme von Microsoft oder dem App-Anbieter finden nicht alle Dateien. Eine vollständige Entfernung ist schwierig, solange man nicht den gesamten Ablauf des Programms exakt nachvollzieht.
  • Auch Pakete unter GNU/Linux hinterlassen oft Restdateien.
• Ich habe UniGetUI entdeckt; es kann verschiedene Paketmanager wie WinGet und Scoop gut ansteuern und bietet Anpassungsfunktionen wie Ignorierlisten. Auf Windows würde ich normalerweise kein solches Maß an Anpassbarkeit erwarten.
• Ich habe mich immer gefragt, warum Windows nie von Anfang an ein integriertes Framework für Installation, Updates und Deinstallation wie macOS hatte. Für mich ist das eine offensichtliche, bis heute ungelöste Lücke. Selbst heute müssen Unternehmenskunden Anwendungen noch einzeln selbst paketieren, um sie zu verwalten. Ich vermute, der Grund ist, dass Microsoft anfangs das Teilen von DLLs gefördert hat und Abwärtskompatibilität gewährleisten musste, weshalb weder .MSI noch ein ausgereifteres Software-Management-Framework verbindlich eingeführt wurden.
  • Auch macOS hatte so ein integriertes Framework nicht von Anfang an. Viele Apps lassen sich zwar bequem per Drag-and-drop in den Applications-Ordner kopieren, aber bei etlichen muss man einen Installer ausführen, und oft wird zur Installation systemweiter Hilfsdateien eine Administratorbestätigung verlangt. Manche Apps starten beim Systemstart außerdem ihren eigenen Updater automatisch. Früher wurden Erweiterungen oder Kontrollfeldelemente in den System Folder installiert, wofür ein Neustart nötig war. Und viele dieser Apps hatten auch keine eigene Deinstallationsfunktion, sodass man Einstellungs- und Cache-Dateien selbst suchen und löschen musste, um sauber neu installieren zu können.
  • Aufgrund des Einflusses von MS-DOS, Microsofts erstem bekannten Betriebssystem, verhielt sich frühes Windows bei der Installation von Drittsoftware im Grunde wie DOS: Es gab kein separates Installationskonzept, sondern man führte einfach das vom Anbieter mitgelieferte INSTALL.COM oder INSTALL.EXE aus. Meist wurde im Root-Verzeichnis ein neuer Ordner angelegt und Dateien wurden hineinkopiert, in manchen Fällen musste der Benutzer den Ordner selbst erstellen und manuell kopieren. Alle App-Datenoperationen konzentrierten sich auf bestimmte Verzeichnisse wie C:\Program Files, statt wie unter UNIX auf /bin, /etc und /var aufgeteilt zu sein. MS-DOS kümmerte sich außer um IO.SYS, MS-DOS.SYS, CONFIG.SYS und AUTOEXEC.BAT praktisch überhaupt nicht um Dateiorte. Als Windows 3.x populär wurde, setzte sich diese DOS-artige Arbeitsweise fort, und ein „integriertes Installationssystem“ kam erst sehr spät. Auch .MSI wurde erst relativ spät eingeführt, weshalb viele bestehende Programme es nie übernommen haben.
  • Als ich zu macOS gewechselt bin, war ich wirklich überrascht, wie viel besser die typische Installationserfahrung im Vergleich zu Windows ist. Dass die Installation oft einfach dadurch erledigt ist, dass man die heruntergeladene Datei in einen Ordner kopiert, fand ich beeindruckend. Selbst wenn ein separater Installer nötig ist, ist es fast immer ein vertrauter, vom System bereitgestellter Ablauf und wirkt daher unkompliziert.
  • Komplexe Themen wie Treiber, Systemerweiterungen und Versionsverwaltung von Bibliotheken machen es schwer, ein integriertes System für Installation und Deinstallation zu schaffen. Wenn nicht einmal eine Internetverbindung garantiert werden kann, wird es noch schwieriger. Und selbst wenn man so eine Funktion baut, muss man Softwareanbieter noch dazu bringen, sie auch zu nutzen; außerdem besteht die Sorge, dass das Management darin eher ein neues Profitzentrum sehen könnte.
  • Große Softwareanbieter stellen in der Regel MSI-Pakete für die Verteilung per GPO bereit. Ich kann mich kaum erinnern, in den letzten zehn Jahren noch selbst paketiert haben zu müssen; meistens beschränkt sich der Aufwand auf einfache Dinge wie das Anpassen von Installationsparametern. Trotzdem gibt es noch reichlich Raum für Verbesserungen.
• Ich habe unter Windows 10 alle Updates deaktiviert und nutze es seit über einem Jahr ohne Probleme. Microsoft scheint dem Wort „Update“ selbst einen negativen Beigeschmack gegeben zu haben, und ich verstehe nicht, warum Nadella Windows so wenig Zuneigung zeigt.
  • Manche Nutzer müssten sich aus Sicherheitsgründen große Sorgen machen, wenn sie nicht updaten, aber die meisten Heim-PCs befinden sich hinter NAT, weshalb die Ausnutzung von Remote-Schwachstellen wie EternalBlue schwierig ist. Solange man sich keinen Trojaner einfängt, passiert meist nichts Großes; wenn nur der Browser aktuell ist, halte ich das in der Praxis für weitgehend sicher. Andererseits kann selbst bei einem Trojaner ohne Administratorrechte noch immer eine Dokumentenverschlüsselung oder die Teilnahme an einem Botnet möglich sein, weshalb Windows-Updates allein ohnehin nicht alle Bedrohungen abwehren.
• Ich finde, die Art von Windows Update ist den Verfahren sehr ähnlich, die alle Linux-Paketmanager verwenden. Im Vergleich zu anderen Alternativen wie Chocolatey, Scoop und WinGet wirkt Windows Update jedoch übermäßig simpel und funktional unzureichend.
  • Es ist mir fast peinlich, dass ich erst so spät erfahren habe, dass es WinGet gibt. Nachdem ich längere Zeit in Linux-Umgebungen wie Ubuntu unterwegs war, habe ich nach einem Paketmanager für Windows gesucht und ihn erst spät entdeckt.
  • Windows Update fühlt sich extrem langsam an. Wenn sich die Zahl der Update-Komponenten oder die Datenmenge verzehnfachen würde, mag ich mir gar nicht vorstellen, wie das aussähe.
• Wenn man kein Entwickler oder Power-User ist und App-Updates per Winget/Kommandozeile schwerfallen, empfehle ich die Open-Source-App UniGetUI ausdrücklich. Die UI ist intuitiv, gut gepflegt und läuft sehr angenehm.
  • Ich habe gerade erst von dem UniGetUI-Projekt erfahren; es wirkt wirklich sehr elegant. Danke fürs Teilen.
• Durch diesen Thread habe ich das wirklich großartige Tool UniGetUI kennengelernt. Ich werde es künftig unbedingt auf all meinen Windows-Geräten installieren. Das Hauptziel dieser App ist es, eine intuitive GUI für verschiedene Windows-Paketmanager wie WinGet, Scoop, Chocolatey, Pip, Npm, .NET Tool und PowerShell Gallery bereitzustellen. Es ist eine ansprechende App, mit der man Software über die unterstützten Paketmanager bequem installieren, aktualisieren und entfernen kann; siehe Link (mit 16,2k Stars).
• Ich bin skeptisch, dass diese Änderung dazu führen wird, dass selbst ein 7zip-Update 20 Minuten dauert und noch einen Neustart verlangt.
  • Ich glaube nicht, dass das zwangsläufig passieren wird. Es gibt viele Updates über Windows Update, die keinen erzwungenen Neustart verlangen, und ich denke, 7zip könnte genauso konfiguriert werden.
• Wie andere hier auch habe ich das Gefühl, dass diese Änderung schon längst überfällig ist. Der Grund ist für mich nicht einfach, wer zuerst da war, sondern dass die Ära der Win32-API und klassischer Desktop-Apps meiner Meinung nach schon vor mindestens zehn Jahren zu Ende gegangen ist. Heute sind nur noch wenige Apps auf dem Desktop installiert, und die meisten Nutzer verlassen sich stärker auf mobile Apps und den Webbrowser. Ich selbst installiere meist nur noch Utilities, und das passt auch nicht zu Microsofts Geschäftsmodell. Deshalb frage ich mich, wer eigentlich die Zielgruppe dafür ist.
• Es gibt die Sorge, dass diese Richtlinie einen gewaltigen Single Point of Failure schaffen könnte, falls es Probleme mit dem Windows-Update-Dienst gibt. Wie auch dieser Suchtrend zeigt, hat Windows Update seit Langem einen Ruf für Instabilität.
  • Wenn es wirklich der einzige Update-Weg würde, wäre die Sorge berechtigt. Aber soweit ich das verstehe, ist nicht geplant, Windows Update zum einzigen Pfad zu machen, daher halte ich die Bedenken bezüglich eines Single Point of Failure für begrenzt.