Kennzeichnung gemäß Artikel 52 Absatz 1 EU AI Act: 🌱 Rechercheunterstützung

Der Fehlercode 0x80072F8F tritt häufig auf, kann jedoch oft von Administratoren und Benutzern nicht gelöst werden. Die Ursachen für diesen Fehler können vielseitig sein. In einer Vielzahl der Probleme hilft jedoch eine simple Lösung. Ich zeige Ihnen, wie Sie mit dem Fehlercode umgehen und Ihr System wieder reparieren können.

Vorwort und Fehlerbeschreibung

Die Auswirkungen, die dieser Fehler aufzeigen kann sind umfänglich.

Die Möglichkeiten, die sich bei der Fehleranalyse und Behebung bieten, können überfordernd über einen hineinbrechen. Erst Recht, wenn man aufgrund der Vielzahl an Symptomen nicht weiß, wo man eigentlich anfangen soll. Zu vielen Fehlersymptomen kommen unzählige Behebungsmöglichkeiten. Problematisch sind aus meiner Sicht die vielen Anleitungen, die zwar die Symptome abschalten, jedoch nicht die Ursache bekämpfen.

In meinem Fall war es den Computern im Netzwerk nicht mehr möglich, optionale Features über die Einstellungen / Apps zu installieren. Es erscheint nach einer kurzen Wartezeit immer der Fehlercode 0x80072F8F. Eine detaillierte Fehlerbeschreibung gibt es nicht. Das Windows Ereignisprotokoll ist ebenso nicht besonders aussagekräftig.

Ein erster Aufschluss gab mir tatsächlich das Protokoll der Netzwerk-Firewall. Hier war bei den durch mich getesteten Clients stetig der Fehler “Connection Reset” zu erkennen. Nach dem Ausschlussverfahren habe ich die üblichen Verdächtigen (Firewall, Proxy, Netzwerkkonfiguration, …) ausgeschlossen.

Die auszurufende URL war https://sls.update.microsoft.com. Zwei Tests führten mich zunächst auf eine falsch Fährte. Zuerst versuchte ich die Seite mittels Google Chrome zu öffnen. Dort erhielt ich bereits eine Zertifikatswarnung. Ein erster Anhaltspunkt.

Mein zweiter Test, der Webseiten-Check der Firma Qualys SSL Labs: https://www.ssllabs.com/ssltest/analyz…e.microsoft.com. Hier der nächste Hammer für mich: This server’s certificate is not trusted, see below for details.

Was ist hier passiert? Hat Microsoft ein falsches Zertifikat im Einsatz? Ist das die Lösung?

Die Antwort ist einfach: Nein. Das Zertifikat wird nicht Global verteilt. Lediglich in Windows-Systemen über Windows-Update. Zumindest eigentlich.

In allen Fällen, die mir bislang untergekommen sind, ist eben dies im Zusammenhang mit dem Fehler 0x80072F8F nicht passiert. Der Zertifikatsstamm wurde auf den Rechnern, respektive der ganzen Domäne nicht aktualisiert. Die Gründe sind mir immer noch unbekannt. Denn eine manuelle Aktualisierung funktioniert problemlos. Dies werden wir in einem späteren Punkt noch erfolgreich belegen.

Zu diesem Fehler-Symptom gesellen sich noch diverse weitere, die im Zusammenspiel in Firmennetzwerken auch wechselseitige Auswirkungen auf andere Gruppenrichtlinien, Vertrauensstellungen anderer Domänen und diversen Einträgen im Fehlerprotokoll haben können. In der Ereignisanzeige deutet sich dieses Problem oft in der Quelle CAPI2 an. Sind hier viele Einträge vom Typ “Fehler” so ist davon auszugehen, das die authrootstl.cab im SYSVOL-Verzeichnis ebenfalls defekt ist. Ebenso kann es vorkommen, dass die Installation von optionalen Features nicht klappt, sowie die Ausführung von Online-Updates nicht funktioniert.

Normale Clients die nicht in Firmennetzwerken eingesetzt werden, können Probleme mit dem Ausführen von Windows-Updates, dem Einsatz des Media-Creation-Tools und anderer Software von Microsoft bekommen. Unter Anderem kann hier auch der Windows-Store betroffen sein.

Es gibt zwei Möglichkeiten das Problem zu beheben.

Lösung 1: Einzelner Clients / Server

Führen Sie das unten stehende Script in einer Powershell mit Administrator-Berechtigungen aus. Es wird ein Verzeichnis angelegt, eine Datei von Windows-Update heruntergeladen und schließlich entpackt und installiert.

md c:\cert
cd c:\cert
certutil.exe -generateSSTFromWU C:\cert\roots.sst
certutil -syncWithWU c:\cert\
$sstStore = ( Get-ChildItem -Path C:\cert\roots.sst )
$sstStore | Import-Certificate -CertStoreLocation Cert:\LocalMachine\Root

Wenn Sie das Script erfolgreich ausgeführt haben und das Problem sofort behoben ist, empfehle ich Ihnen dennoch einen Neustart des Systems.

Lösung 2: Fehler auf allen Endgeräten einer Domäne

Im Unternehmensumfeld kann dies auch zu einem globalen Problem werden. In meinem Fall, waren alle Clients und alle modernen Server-Versionen von dem Problem betroffen. Hier hat eine einfache Lösung den Erfolg gebracht, da so alle Clients automatisch repariert werden. Verbinden Sie sich mit dem Administrator-Konto Ihrer Domäne auf einen Domänen-Controller und öffnen eine Powershell mit Administrator-Berechtigungen. Geben Sie folgenden Befehl ein:

Certutil -syncWithWU -f \\ihredomain.tld\SYSVOL\ihredomain.tld\rootcert\

Danach sollten sich innerhalb weniger Minuten alle Clients in Ihrer Domäne heilen.

Bislang konnte dieses Kommando jede korrumpierte Domänenstruktur wieder reparieren und den Betrieb aller PCs wieder sicherstellen.

Bislang war es mir unmöglich zu reproduzieren, wie der Fehler verursacht wird. Wenn Sie Ergänzungen dazu haben, nutzen Sie gerne die Kommentar-Funktion unter diesem Artikel oder nutzen Sie die “Vorschläge” Funktion meines Systems.

Ich bedanke mich, das Sie diesen Eintrag gelesen haben und hoffe das Sie ebenso erfolgreich Ihr Problem lösen konnten!