Windows Server 2019: Container-Feature nicht installierbar (0x800F0831, 0x80073701)

[English]Im Umfeld des Out-of-Band-Updates für das Hyper-V-Problem mit Windows Server 2019/2022 hat mich ein Blog-Leser kontaktiert. Er hat das Problem, dass sich das Container-Feature unter Windows Server 2019 nicht als Rolle installieren lässt. Der Installationsversuch bricht mit dem Fehler 0x800F0831 ab. Hier einige Informationen zum Problem und möglicherweise Abhilfe (von Microsoft gibt es seit dem 28. Oktober 2022 einen Artikel dazu).

Eine Lesermeldung zum Problem

Es war mein Artikel Windows Server 2019/2022: Out-of-Band Updates fixen Hyper-V-Probleme (20. Dez. 2022), der Blog-Leser Georg K. Kontakt aufnehmen ließ. Bei einem Kunden ist er auf das Problem gestoßen, dass er das Container-Feature nicht auf deren Windows Server 2019 als Rolle installieren konnte. Dazu schrieb er mir:

Hallo Günter, dieser Patch [gemeint ist das obige OOB-Update für Hyper-V] hat leider auch nicht wirklich geholfen.

Ich versuche seit vorgestern auf einem Windows Server 2019 das Container Feature zu installieren, leider bricht er mir immer wieder ab.

Ich hab auch schon gesucht ob ein Update mal hängen geblieben ist, auch nicht der Fall.

Ich hab es bereits über den Server Manager wie auch über PS versucht immer das gleiche Ergebnis. Danke für einen Tipp.

(Zum Vergrößern klicken)

Der nachfolgende PowerShell-Befehl endet mit dem Fehlercode 0x800F0831, es wird eine ungültige Operation bemängelt, und die Rolle wurde nicht installiert.

Install-WindowsFeature -Name containers

In einer weiteren Mitteilung auf meine Nachfrage nach Details hat Georg dann noch folgendes geschrieben:

Das Einzige was ich bislang rausfinden konnte ist, das mir hier irgend ein Pach oder Update fehlen sollte, was aber nicht der Fall ist. Eigenartig ist nur, ich komm weder bei der PS als auch über dem Admin Center zur gleichen Fehlermeldung.

Ich habe bezüglich des obigen PowerShell-Befehls dann nach dem Fehlercode 0x800F0831 geschaut. Der steht für "You entered an invalid DWORD", was aber auch wenig hilft.

Mögliche Ansätze zur Analyse

Geht man mit den Begriffen "Windows Server 2019 Install Features Container fails" auf die Suche, gibt es mehrere Treffer – Probleme beim Installieren der Container-Rolle sind wohl häufiger. Im Technet gibt es den älteren Post Error '0x80073701' while trying to install Containers Windows feature von 2020, der dann auf veraltete Registrierungseinträge im Update-Store hinweist. Aber in der Registrierung etwas auf Verdacht zu löschen, ist etwas riskant.

Häufig liest man den Ratschlag, das Betriebssystem neu zu installieren oder eine Reparaturinstallation per Inplace-Upgrade zu versuchen. Ist aber bei Windows Server eher nicht so der Brüller. Georg meinte dazu:

Na das mit einer Reparaturinstallation, davon halte ich nix. Denn es sieht die Konstellation auch so aus, dass es sich hier um einen Servercluster von 2 ML380 mit einer Aruba Storage handelt, wo mehrere VMs bereits produktiv laufen. Das ist mir ehrlich gesagt zu heiß.

Diese Haltung kann ich sehr gut verstehen.  Im Technet-Foren-Thread findet sich noch der Hinweis auf den Technet-Beitrag Installing roles and features error 0x80073701 zu Windows Server 2016. Nutzer Venom83 hat im betreffenden Thread seine Lösung in diesem Spezialfall gepostet. Dort scheint es mit den Sprachpaketen zu tun zu haben. Eine Deinstallation hat bei diesem Fall nicht geholfen. Es hat dann eine Prüfung des Systems mittels DISM durchgeführt (siehe Windows 8: Komponentenstore reparieren) und dann die CBS.log im Ordner:

C:\Windows\Logs\CBS\

ausgewertet. Dort wurde er fündig, eine fehlende Assembly im SXS-Ordner war die Ursache. Er hat den Registrierungseintrag dann entfernt. Ob es in obigem Fall weiter hilft, ist aktuell unklar.

Bei der Suche nach dem Fehler 0x800F0831 bin ich dann noch auf den Microsoft Support-Beitrag Error 0x800f0831 when you install an update vom 28. Oktober 2022 gestoßen. Auch dort werden fehlende Pakete (ist oft einen Manifest-Datei im SXS-Assembly-Store) angesprochen, die eine Update-Installation verhindern – könnte bei der Installation einer Rolle ähnlich sein. Da hilft dann nur die Analyse der CBS.log. Aktuell ist noch offen, was die Ursache für obiges Problem ist – falls sich Georg mit neuen Erkenntnissen meldet, trage ich es nach.

Erste Erkenntnisse aus der CBS.log

Der Blog-Leser hat mir dann eine Kopie seiner CBS.log (sowie der dism.log) zukommen lassen. In der dism.log gibt es jede Menge Fehler, die habe ich dann nicht weiter ausgewertet. Interessanter fand ich die CBS.log, in der ich dann schlicht nach "Error" gesucht habe. Folgenden Ausriss fand ich interessant:

Microsoft-Windows-Xps-Xps-Viewer-Opt-Package~31bf3856ad364e35~amd64~~10.0.17763.1, applicable state: Installed
2022-12-22 12:29:06, Info                  CBS    Session: 31004152_2581324107 initialized by client DISM Package Manager Provider, external staging directory: (null), external registry directory: (null
2022-12-22 12:29:06, Info                  CBS    Client specifies manual store corruption detect or repair.
2022-12-22 12:29:06, Info                  CBS    Exec: Session processing started.  Client: Manual, Session(DISM Package Manager Provider Store Corruption Detect/Repair): 31004152_2581324107
2022-12-22 12:29:06, Info                  CBS    Reboot mark set
2022-12-22 12:29:06, Info                  CBS    Winlogon: Registering for CreateSession notifications
2022-12-22 12:29:06, Info                  CBS    Winlogon: Loading SysNotify DLL
2022-12-22 12:29:06, Info                  CBS    Winlogon: Starting notify server 
2022-12-22 12:29:06, Info                  CBS    FLOW: Entering stage: CheckCbs 
2022-12-22 12:29:15, Error                 CSI    00000001 (F) STATUS_OBJECT_NAME_NOT_FOUND #175972# from Windows::Rtl::SystemImplementation::DirectFileSystemProvider::SysCreateFile(flags = 0, handle = {provider=NULL, handle=0, name= ("null")}, da = (FILE_GENERIC_READ|DELETE), oa = @0x31273fd280->OBJECT_ATTRIBUTES {s:48; rd:NULL; on:[97]'\??\C:\Windows\Servicing\Packages\Package_3392_for_KB5017379~31bf3856ad364e35~amd64~~10.0.1.9.cat'; a:(OBJ_CASE_INSENSITIVE)}, iosb = @0x31273fd220, as = (null), fa = (FILE_ATTRIBUTE_NORMAL), sa = (FILE_SHARE_READ|FILE_SH[gle=0xd0000034]
2022-12-22 12:29:15, Error                 CSI    ARE_WRITE|FILE_SHARE_DELETE), cd = FILE_OPEN, co = (FILE_NON_DIRECTORY_FILE|FILE_SYNCHRONOUS_IO_NONALERT), eab = NULL, eal = 0, disp = Invalid)
[gle=0xd0000034]

Es wird das Paket für das Update KB5017379 bemängelt. Suche ich im Blog nach diesem Update, finde ich folgende Beiträge:

• Windows 10/Server v1909 Preview Update KB5016690 (20.9.2022)
• WSUS-Chaos: Preview-Updates für Windows und Net zum 21.9.2022 als Superseded zurückgezogen – Bestätigung durch Microsoft

Ob es daran liegt, konnte ich bisher nicht in Erfahrung bringen. Aber der zweite Artikel in obiger Liste deutet möglicherweise darauf hin, dass da was im Argen liegt. Im aktuellen Fall hilft möglicherweise ein Deinstallationsversuch für das Update – oder das Bereinigen der Registrierung, wie sie in den oben verlinkten Technet-Beiträgen skizziert wurde.