Das zum 14. April 2026 für Windows Server 2025 freigegebene Sicherheitsupdate KB5082063 verursacht bei einigen Systemen Installationsfehler. Hier im Blog haben sich Administratoren gemeldet, die den Error 0x80073712 erhalten (hier gibt es eine Lösung). Microsoft hat inzwischen zudem den Installationsfehler 0x800F0983 bei einigen wenigen Maschinen bestätigt.
Update KB5082063 scheitert mit Error 0x80073712
Ich hatte im Blog-Beitrag Patchday: Windows Server-Updates (14. April 2026) über die von Microsoft bereitgestellten Sicherheitsupdate für Windows Server berichtet. Blog-Leser Martin schreibt in diesem Kommentar, dass sich das 2026-04 Sicherheitsupdate (KB5082063) (26100.32690) auf keinem der Kundensysteme mit Windows Server 2025 Standard installieren lässt. Die Installation scheitert immer mit dem Fehler 0x80073712. Martin gibt an, die Server in Deutsch aufgesetzt zu haben. Auch die Ausführung der Befehle:
dism.exe /online /cleanup-image /restorehealth sfc /Scannow
brachte keinen Erfolg. In Folgekommentaren wie diesem bestätigen Blog-Leser das obige Fehlerbild mit einem Installationsabbruch mit Error 0x80073712. Allerdings trifft es nicht alle Windows Server 2025-Instanzen. Aktuell deutet die Kommentarlage darauf hin, dass es an speziell gebrandeten Server-Varianten liegen könnte, die mit OEM-Branded Installationsmedien (HPE oder DELL) aufgesetzt wurden.
Ergänzung: Gemäß Analyse von Blog-Leser CWallner in nachfolgendem Kommentar habe ich die Lösung in den Beitrag Windows Server 2025: Fehler 0x80073712 bei KB5082063 durch Media Player-Sprachpakete herausgezogen. Vielleicht hilft es.
KB5082063 wirft Error 0x800F0983
Über die patchmanagement.org-Mailing-Liste ist mir die Meldung Microsofts untergekommen, dass das Update KB5082063 für Windows Server 2025 bei der Installation den Error 0x800F0983 auslöst.
Microsoft hat bei der Auswertung der Diagnosedatenberichte zu fehlgeschlagenen Update-Installationen für die am 14. April 2026 veröffentlichten Windows-Sicherheitsupdates einen wiederkehrenden Fehler auf Windows Server 2025-Geräten festgestellt. Bei einer begrenzten Anzahl betroffener Server kann es zu einem Installationsfehler kommen, der mit dem Fehlercode 800F0983 einhergeht.
Microsofts Entwickler untersuchen dieses Problem derzeit aktiv und werden weitere Informationen bereitstellen, sobald mehr Details vorliegen.
Ergänzung: Es gibt ein Out-of-Band-Update zum Beheben des Fehlers (siehe Windows Server Out-of-Band-Updates (19.4.2026) zur Fehlerkorrektur).
Ähnliche Artikel:
Microsoft Security Update Summary (14. April 2026)
Patchday: Windows 10/11 Updates (14. April 2026)
Patchday: Windows Server-Updates (14. April 2026)
Patchday: Microsoft Office Updates (14. April 2026)
Remote Desktop-Phishing-Schutz im April 2026-Update verursacht Verwirrung
Windows 11 April 2026-Updates (KB5083769, KB5082052) triggern BitLocker Recovery
Windows Server 2025: Update KB5082063 liefert Error 0x800F0983, 0x80073712
Windows Server 2025: Fehler 0x80073712 bei KB5082063 durch Media Player-Sprachpakete
Windows Server 2016-2025: Reboot von Domain Controllern durch April 2026-Update (KB5082063 etc.)
Windows April 2026-Updates verursachen Anmelde-Probleme
Windows Server Out-of-Band-Updates (19.4.2026) zur Fehlerkorrektur
MVP: 2013 – 2016
Exakt dasselbe auf einem System bei uns hier gehabt. Die meisten Server mit 2025 liefen durch, aber bei einem exakt das Gleiche. DISM und SFC haben das bei uns korrigiert, aber im Artikel fehlt was – oder unabsichtlich nicht vollständig?
Wir hatten folgendes gemacht – zum Teil weil aus der Vergangenheit so bekannt. Reihenfolge könnte man teilweise abändern – es hat sich aber trotzdem so bewehrt:
1.) dism /online /cleanup-image /startcomponentcleanup
2.) Mount-DiskImage -ImagePath "U:\ISO\WindowsServer2025_DE.iso"
(Pfad wo halt die passende ISO liegt)
3.) dism /Get-WimInfo /WimFile:D:\sources\install.wim
(ISO wird als virtuelles Laufwerk eingebunden. Für gewöhnlich der nächste freie Laufwerksbuchstabe. Befehl zeigt die Installationsvarianten auf der DVD an)
4.) dism /online /cleanup-image /restorehealth /source:wim:D:\sources\install.wim:3 /limitaccess
(Pfad zum virtuellem Laufwerk und die Nummer passend zur Installationsvariante wie Standard/Datacenter und Server Core)
5.) sfc /scannow
6.) Neustart, denn teilweise werden da noch Angelegenheiten finialisiert.
7.) Nun alles andere Updates installieren lassen (diesen Monat z.B. .NET)
8.) Neustart und erst jetzt das Problem Update
Klappte so bereits mehrfach zuverlässig. Dieses Mal und auch bei den letzten Male…
Anmerkung: restorehealth klappt meistens nicht ohne korrekter Quelle – zumindest nach meinen Erfahrungen. Teilweise soll "dism /online /cleanup-image /restorehealth /source:E:\sources\sxs /limitaccess" funktionieren. Da ist z.B. die Installationsvariante egal. Es muss nur 2025, 2022, etc. sein. Ich kann das bislang nicht bestätigen.
edit: es gibt auch ISO wo keine WIM liegt, sondern das "modernere" Dateiformat. Auch das würde gehen… – da müsste ich aber selbst etwas in unserer Doku nachschaun. Das weiß ich aus dem Gedächnis jetzt auf die Schnelle nicht.
Hi zusammen,
mein 2025er vServer von Strato hat das Problem ebenfalls.
@Andyt: hast Du im Nachgang mal mit winver überprüft ob auch wirklich die aktuelle Build-Nummer angezeigt wird?
Bei mir wars nämlich so, dass der erste Installationsversuch mit 0x80073712 fehlgeschlagen ist. Nach einem Retry ist es dann aber vermeintlich erfolgreich durchgelaufen und wollte einen Reboot. Nach einem Reboot zeigte Windows Update in der History das Update als erfolgreich installiert und auch wenn ich es aus dem Microsoft Update Catalog runterlade und manuell ausführen möchte sagt er "nicht nötig, da bereits installiert".
ABER: winver zeigt nach wie vor den alten Build (26100.32522) an.
Und Windows Update bietet das angeblich erfolgreich installierte KB5082063 in Endlosschleife zum Download an (Installation läuft wieder in 0x80073712).
Gruß
Ben
Nein, ist hier korrekt. Davor ist es aber nie installiert worden und wurde vermutlich auch nicht als installiert angezeigt. Die Installation war dabei immer über den WSUS – selbst der Versuch. Dort wird es nun (nach dem oben angeführten Prozess) auch nicht mehr als notwendig angezeigt.
Windows Server 2025 Domain Controller scheinen auch in ein Problem rennen zu können: https://learn.microsoft.com/en-us/windows/release-health/status-windows-server-2025#domain-controllers-may-restart-repeatedly-after-installing-april-security-update
Den ersten Absatz evtl. ausblenden, da das PAM Feature wohl nicht soooo verbreitet sein wird. Der Zweite Absatz betrifft dann aber "manche (andere) Umgebung":
-> After installing the April 2026 Windows security update (KB5082063) and rebooting, non‑Global Catalog (non‑GC) domain controllers (DCs) in environments that use Privileged Access Management (PAM), might experience LSASS crashes during startup. As a result, affected DCs may restart repeatedly, preventing authentication and directory services from functioning, and potentially rendering the domain unavailable.
-> In some environments, this issue can also occur when setting up a new domain controller, or on existing DCs if authentication requests are processed very early during startup.
Zum Fehler 0x80073712:
In unserer Windows Server 2025 (24H2) Umgebung habe ich durch Analyse der CBS.Log-Datei herausgefunden, dass die Update-Installationsprobleme mit der unsäglichen Kombination aus aktivierter Desktop-Experience (die den Windows Media Player Legacy App als FoD aktiviert) und Installation von Sprachpaketen zusammenhängt.
Während des Patchens scheitert die Installation der benötigten Komponenten für das de-DE Sprachpaket des Media Players.
Im Log schaut das dann analog so aus:
Line 1206611: 2026-04-16 14:12:35, Error SXS Component metadata corrupt for Microsoft-Windows-MediaPlayer-autoplay.Resources, version 10.0.26100.1, arch amd64, culture [l:5]'de-DE', nonSxS, pkt {l:8 b:31bf3856ad364e35}: STATUS_SXS_COMPONENT_STORE_CORRUPT
Line 1206612: 2026-04-16 14:12:35, Error SXS WIL Origination: onecore\base\servicing\turbostack\lib\staging.cpp(3999)\TurboStack.dll!00007FFE0A52E50B: (caller: 00007FFE0A519CF9) Exception(505) tid(c4) C015001A The component store has been corrupted.
Line 1206622: 2026-04-16 14:12:35, Error SXS Component metadata corrupt for Microsoft-Windows-MediaPlayer-Setup.Resources, version 10.0.26100.1, arch amd64, culture [l:5]'de-DE', nonSxS, pkt {l:8 b:31bf3856ad364e35}: STATUS_SXS_COMPONENT_STORE_CORRUPT
Die Lösung für uns bestand dann darin, nicht nur das Media Player FoD zu deaktivieren, sondern er musste komplett aus dem Online-Image entfernt werden (PowerShell):
Get-WindowsPackage -Online | Where {$_.PackageName -like "*MediaPlayer*"} | Remove-WindowsPackage -Online -NoRestart
Danach ließ sich der KB5082063 sowohl über Microsoft Update als auch WSUS installieren.
Microsoft hat ganz offensichtlich das dynamische Patching von Feature on Demand in Kombination mit Sprachpaketen für dieses kumulative Update verbockt.
Als Alternative für den (abgekündigten) Windows Media Player Legacy App empfiehlt Microsoft selbst die Nutzung des "modern" Media Players aus dem Microsoft Store, der als MSIX-Installation verfügbar ist.
Wir selber haben uns für eine weit verbreitete open source-Alternative entschieden.
Herzlichen Dank,
das kann ich so bestätigen.
In der CBS.log sind bei mir die gleichen Zeilen zu finden.
Nach dem Entfernen des Media Players lässt sich das Update problemlos installieren.
Auch von mir ganz herzlichen Dank an Dich, CWallner!
Nach der Entfernung des WMP inkl. der Packages wurde das Update erfolgreich installiert, auch der Patchlevel in winver hat sich nun auf 26100.32690 erhöht und Windows Update hält sich nun auch für "Up to date"
Vielen Dank für die Analyse und Hilfestellung.
Bei uns hat es allerdings mit der Deinstallation nicht geklappt.
PS C:\WINDOWS\system32> Get-WindowsPackage -Online | Where {$_.PackageName -like "*MediaPlayer*"} | Remove-WindowsPackage -Online -NoRestart Remove-WindowsPackage : Das angegebene Paket ist kein gültiges Windows-Paket.
In Zeile:1 Zeichen:77
+ … ame -like "*MediaPlayer*"} | Remove-WindowsPackage -Online -NoRestart
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Remove-WindowsPackage], COMException
+ FullyQualifiedErrorId : Microsoft.Dism.Commands.RemoveWindowsPackageCommand
Hatt Vielleicht noch jemand eine Idee, an was es liegen könnte?
Hi Darkfreake,
wenn es Dich tröstet: ich war auch zuerst zu doof zum Lesen und bin in den gleichen Fehler gerannt :D
"Die Lösung für uns bestand dann darin, -> nicht nur das Media Player FoD zu deaktivieren <-, sondern er musste komplett aus dem Online-Image entfernt werden"
Den markierten Part hab ich zuerst auch überlesen… Du musst bevor Du die Windows Packages entfernen kannst unter Optional Features (einfach im Startmenü danach suchen) die "Windows Media Player Legacy App" deinstallieren – danach kannst Du den PowerShell-Befehl ausführen.
Gruß
Ben
Moin Ben,
besten Dank für den Hinweis….jetzt hat es auch geklappt
Ich hatte den Mediaplayer vorher über die Command line deinstalliert, anscheinend ist das was anderes als über die Gui. Ich habe den Mediaplayer letztendlich wieder installiert, um ihn dann per Gui wieder zu deinstallieren, dann klappte es auch per PS :-).
Aktuelles Update ist jetzt auch durch….das Wochenende kann kommen :-)
Super! Vielen Dank!
Remove-WindowsPackage hat bei mir zwar nicht funktioniert, aber Remove-WindowsCapability hat das Problem behoben.
Bei 500 Windows 11 25H2 Clients, haben bei uns ca. 150 den 0x80070306 als Installationsfehler. Scheint also nicht nur Server zu betreffen..
Das müsste dann ja bei der Installation von KB5083769 (für Windows 11 24H2 und 25H2) passiert sein.
Dieses lief hier allerdings problemlos durch, mit oder trotz aktiviertem Feature [Medienfeatures –> Windows Media Player Legacy (App)].
Gestern erfolgreich installiert. Quelle des Pakets ist hier der interne WSUS.
Sowohl Windows 11 25H2 als auch die Media Player Legacy App sind in Deutscher Sprache. Gibt es da noch zusätzliche Deutsche Sprachpakete?
Genau das Problem habe ich auch. Ich habe aber gesehen, dass das Update Probleme auf DCs macht, dass die teilweise einfach neu starten. Vielleicht auch gut so. Es wird leider immer schlimmer.
Kann bitte jemand mit dem Bug einmal versuchen, den Mediaplayer mit folgendem Befehl zu deinstallieren:
Remove-WindowsPackage -PackageName Microsoft-Windows-MediaPlayer-Package~31bf3856ad364e35~amd64~~10.0.26100.1742 -Online -NoRestart
Statt 10.0.26100.1742 eine Vorgängerversion – je nach Patchstand.
Die Scripte liefen hier in Fehler, da es sich bei den abhängigen Sprachpaketen nicht um entfernbare Pakete handelt.
Alle Pakete mit Build 26100.1742 (Patchlevel "1742" ist der wichtige Teil) sind staged Checkpoint und damit unlöschbar, da höhere Builds diesen ursprünglichen ersten Checkpoint brauchen für die differentiellen binären Updates.
Man muss also zuerst das Paket mit der höheren Build-Nummer deinstallieren.
Außerdem musst du vorher das Feature on Demand "Windows Media Player Legacy App" deakivieren, entweder in der GUI oder mit Remove-WindowsCapability in Powershell.
Hallo zusammen,
danke an alle für die vielen Tipps!
Gibt es auch einen Tipp für die Behebung des Problems, wenn die Fehlermeldung 0x80070306 lautet? Das OS ist Windows Server 2025 Standard mit Desktop Experience in der englischen Sprachversion. Danke!