Zum 14. April 2026 (zweiter Dienstag im Monat, Patchday bei Microsoft) wurden verschiedene kumulative Updates für die unterstützten Versionen von Windows Server freigegeben. Nachfolgend habe ich die bereitgestellten Updates samt einigen Details für diese Windows Server-Versionen (von Windows Server 2012 bis 2025) herausgezogen.
Die nachfolgend aufgeführten Updates beheben die in Microsoft Security Update Summary (14. April 2026) beschriebenen und für Windows Server relevanten Schwachstellen.
Updates für Windows Server 2025
Eine Liste der Updates für Windows Server 2025 lässt sich auf dieser Microsoft-Webseite abrufen. Für Windows Server 2025 wurde das kumulative Update KB5082063 freigegeben, welches Sicherheitspatches und diverse Fixes beinhaltet.
- [Secure Boot]
- With this update, Windows quality updates include additional high confidence device targeting data, increasing coverage of devices eligible to automatically receive new Secure Boot certificates. Devices receive the new certificates only after demonstrating sufficient successful update signals, maintaining a controlled and phased rollout.
- This update addresses an issue where the device might enter BitLocker Recovery after the Secure Boot updates.
- [Kerberos protocol] This update changes the default DefaultDomainSupportedEncTypes value for Kerberos Key Distribution Center (KDC) operations to leverage AES-SHA1 for accounts that don't have an explicit msds-SupportedEncryptionTypes Active Directory attribute defined. For more information see, How to manage Kerberos KDC usage of RC4 for service account ticket issuance changes related to CVE-2026-20833.
- [Authentication] This update improves how Windows uses Kerberos encryption policies during authentication. After you install this update, Windows reads the configured policy settings as expected, which helps ensure encryption behavior is applied consistently across the domain.
- [Bluetooth] This update improves Bluetooth device management in Settings and Quick Settings, helping connected devices appear consistently and making them easier to add and manage.
- [Graphics] This update improves color rendering when printing from Win32 desktop apps.
- [Networking] This update improves reliability when Windows uses SMB compression over QUIC. After you install this update, SMB compression requests over QUIC complete more consistently, reducing the likelihood of timeouts and supporting smoother, more dependable performance.
- [PowerShell] This update improves how the Set-GPPrefRegistryValue cmdlet in PowerShell imports registry preference values. The cmdlet now preserves each imported value in full, including the final character.
- [Remote Desktop] This update improves protection against phishing attacks that use Remote Desktop (.rdp) files. When you open an .rdp file, Remote Desktop shows all requested connection settings before it connects, with each setting turned off by default. A one-time security warning also appears the first time you open an .rdp file on a device. For more information, see Understanding security warnings when opening Remote Desktop (RDP) files.
- [Texts and Fonts] This update improves Windows fonts by adding the new Saudi Riyal currency symbol. This change helps keep text clear, accurate, and visually consistent across your Windows apps and experiences.
- [Windows Deployment Services (WDS)] This update disables the "Hands-Free Deployment" feature in WDS by default and is no longer a supported feature. For more information about this change, see Windows Deployment Services (WDS) Hands-Free Deployment Hardening Guidance related to CVE-2026-0386. Siehe auch meinen Beitrag Erinnerung: Im April 2026 endet die Unterstützung für Windows Deployment Service (WDS).
Dieses Update wird automatisch von Windows Update heruntergeladen und installiert, ist aber auch im Microsoft Update Catalog und per WSUS sowie WUfB erhältlich. Im Patch ist das aktuelle Windows Servicing Stack Update integriert. Details zum Update sowie ggf. verursachte Probleme und Installationsvoraussetzungen sind im Support-Beitrag aufgeführt.
Updates für Windows Server 2022/23H2
Für Windows Server 2022 sowie sowie für Windows Server 23H2 stehen folgende Updates zur Verfügung.
Update KB5082060 für Windows Server 23H2
Eine Liste der Updates für Windows Server 23H2 lässt sich auf dieser Microsoft-Webseite abrufen. Für Windows Server 23H2 wurde das kumulative Update KB5082060 freigegeben, welches Sicherheitspatches und verschiedene Fixes beinhaltet.
- [Graphics]
- This update improves stability for certain GPU configurations. It helps games and 3D apps run more reliably during intensive graphics use.
- This update improves stability affecting certain GPU configurations, helping devices shut down more reliably.
- [Kerberos protocol] This update changes the default DefaultDomainSupportedEncTypes value for Kerberos Key Distribution Center (KDC) operations to leverage AES-SHA1 for accounts that do not have an explicit msds-SupportedEncryptionTypes Active Directory attribute defined. For more information see, How to manage Kerberos KDC usage of RC4 for service account ticket issuance changes related to CVE-2026-20833 [verlinkter Supportbeitrag geändert, der MS-Support-Beitrag verlinkt auf WDS, das dürfte falsch sein].
- [Networking] This update improves reliability when Windows uses SMB compression over QUIC. After you install this update, SMB compression requests over QUIC complete more consistently, reducing the likelihood of timeouts and supporting smoother, more dependable performance.
- [Remote Desktop] This update improves protection against phishing attacks that use Remote Desktop (.rdp) files. When you open an .rdp file, Remote Desktop shows all requested connection settings before it connects, with each setting turned off by default. A one-time security warning also appears the first time you open an .rdp file on a device. For more information, see Understanding security warnings when opening Remote Desktop (RDP) files.
- [Secure Boot] This update addresses an issue where the device might enter BitLocker Recovery after the Secure Boot updates.
- [Windows Deployment Services (WDS)] This update disables the "Hands-Free Deployment" feature in WDS by default and is no longer a supported feature. For more information about this change, see Windows Deployment Services (WDS) Hands-Free Deployment Hardening Guidance related to CVE-2026-0386. Siehe auch meinen Beitrag Erinnerung: Im April 2026 endet die Unterstützung für Windows Deployment Service (WDS).
Dieses Update wird automatisch von Windows Update heruntergeladen und installiert, ist aber auch im Microsoft Update Catalog und per WSUS sowie WUfB erhältlich. Im Patch ist das aktuelle Windows Servicing Stack Update integriert. Details zum Update sowie ggf. verursachte Probleme und Installationsvoraussetzungen sind im Support-Beitrag aufgeführt.
Update KB5082142 für Windows Server 2022
Eine Liste der Updates für Windows Server 2022 lässt sich auf dieser Microsoft-Webseite abrufen. Für Windows Server 2022 wurde das kumulative Update KB5082142 freigegeben, welches Sicherheitspatches und diverse Bug-Fixes beinhaltet.
- [Connectivity] This update improves the reliability of audio features in Windows, helping reduce system unresponsiveness related to sound or audio activity.
- [Kernel] This update improves system stability during large file operations. Users should experience fewer unexpected interruptions while working with or transferring large files.
- [Kerberos protocol] This update changes the default DefaultDomainSupportedEncTypes value for Kerberos Key Distribution Center (KDC) operations to leverage AES-SHA1 for accounts that do not have an explicit msds-SupportedEncryptionTypes Active Directory attribute defined. For more information see, How to manage Kerberos KDC usage of RC4 for service account ticket issuance changes related to CVE-2026-20833.
- [Networking] This update improves reliability when Windows uses SMB compression over QUIC. After you install this update, SMB compression requests over QUIC complete more consistently, reducing the likelihood of timeouts and supporting smoother, more dependable performance.
- [Remote Desktop] This update improves protection against phishing attacks that use Remote Desktop (.rdp) files. When you open an .rdp file, Remote Desktop shows all requested connection settings before it connects, with each setting turned off by default. A one-time security warning also appears the first time you open an .rdp file on a device. For more information, see Understanding security warnings when opening Remote Desktop (RDP) files.
- [Secure Boot]
- With this update, Windows quality updates include additional high confidence device targeting data, increasing coverage of devices eligible to automatically receive new Secure Boot certificates. Devices receive the new certificates only after demonstrating sufficient successful update signals, maintaining a controlled and phased rollout.
- This update addresses an issue where the device might enter BitLocker Recovery after the Secure Boot updates.
- [Texts and Fonts] This update improves Windows fonts by adding the new Saudi Riyal currency symbol. This change helps keep text clear, accurate, and visually consistent across your Windows apps and experiences.
- [Windows Deployment Services (WDS)] This update disables the "Hands-Free Deployment" feature in WDS by default and is no longer a supported feature. For more information about this change, see Windows Deployment Services (WDS) Hands-Free Deployment Hardening Guidance related to CVE-2026-0386. Siehe auch meinen Beitrag Erinnerung: Im April 2026 endet die Unterstützung für Windows Deployment Service (WDS).
Dieses Update wird automatisch von Windows Update heruntergeladen und installiert, ist aber auch im Microsoft Update Catalog und per WSUS sowie WUfB erhältlich. Im Patch ist das aktuell Windows Servicing Stack Update integriert. Details zum Update sowie ggf. verursachte Probleme und Installationsvoraussetzungen sind im Support-Beitrag aufgeführt.
Updates für Windows Server 2016/2019
Eine Liste der Updates für Windows Server 2016 und 2019 lässt sich auf dieser Microsoft-Webseite abrufen. Ich habe nachfolgend die betreffenden Update-Informationen herausgezogen.
Update KB5082123 für Windows Server 2019
Das kumulative Update KB5082123 steht nicht nur für Windows 10 2019 Enterprise LTSC etc. bereit, sondern auch für Windows Server 2019. Das Update beinhaltet Sicherheitsfixes, und Verbesserungen bzw. Fehlerbehebungen (auf den Registerreiter zu Server 2019 umstellen), die im Supportbeitrag aufgeführt sind.
- [PowerShell (known issue)] Fixed: After installing Windows updates released on or after January 13, 2026, Japanese language installations of Windows Server 2019 might not correctly display Japanese characters in the PowerShell console.
- [Remote Desktop] This update improves protection against phishing attacks that use Remote Desktop (.rdp) files. When you open an .rdp file, Remote Desktop shows all requested connection settings before it connects, with each setting turned off by default. A one-time security warning also appears the first time you open an .rdp file on a device. For more information, see Understanding security warnings when opening Remote Desktop (RDP) files.
- [Windows Deployment Services (WDS)] This update disables the "Hands-Free Deployment" feature in WDS by default and is no longer a supported feature. For more information about this change, see Windows Deployment Services (WDS) Hands-Free Deployment Hardening Guidance related to CVE-2026-0386. Siehe auch meinen Beitrag Erinnerung: Im April 2026 endet die Unterstützung für Windows Deployment Service (WDS).
- [Kerberos protocol] This update changes the default DefaultDomainSupportedEncTypes value for Kerberos Key Distribution Center (KDC) operations to leverage AES-SHA1 for accounts that do not have an explicit msds-SupportedEncryptionTypes Active Directory attribute defined. For more information see, How to manage Kerberos KDC usage of RC4 for service account ticket issuance changes related to CVE-2026-20833.
- [Secure Boot]
- This update enables dynamic status reporting for Secure Boot states in the Windows Security App (Settings > Update & Security > Windows Security). Learn more about the status alerts via badges and notifications. Note that these enhancements are disabled by default on commercial devices and servers.
- This update fixes an issue that could cause a device to enter BitLocker Recovery after Secure Boot updates.
- With this update, Windows quality updates include additional high confidence device targeting data, increasing coverage of devices eligible to automatically receive new Secure Boot certificates. Devices receive the new certificates only after demonstrating sufficient successful update signals, maintaining a controlled and phased rollout.
Das Update wird automatisch von Windows Update heruntergeladen und installiert, ist aber auch im Microsoft Update Catalog, per WSUS und WUfB erhältlich. Microsoft hat zudem das Service Stack Update (SSU) aktualisiert. Beachtet die im Support-Beitrag beschriebene Installationsreihenfolge, ggf. die Hinweise zu weiteren Anforderungen und eventuell vorhandener Probleme.
Update KB5078938 für Windows Server 2016
Das kumulative Update KB5078938 steht nicht nur für Windows 10 2016 Enterprise LTSC, sondern auch für Windows Server 2016, bereit. Das Update beinhaltet Sicherheitsfixes, Fehlerbehebungen und Verbesserungen, die ggf. im Supportbeitrag aufgeführt werden.
- [Windows Component Services (WinCS)] This update addresses an issue that affects Windows Component Services (WinCS) on Windows 10, version 1607 and Windows Server 2016. Some WinCS components were missing. Because of this, you could not turn on Secure Boot using WinCS.
- [Remote Desktop] This update improves protection against phishing attacks that use Remote Desktop (.rdp) files. When you open an .rdp file, Remote Desktop shows all requested connection settings before it connects, with each setting turned off by default. A one-time security warning also appears the first time you open an .rdp file on a device. For more information, see Understanding security warnings when opening Remote Desktop (RDP) files.
- [Windows Deployment Services (WDS)] This update disables the "Hands-Free Deployment" feature in WDS by default and is no longer a supported feature. For more information about this change, see Windows Deployment Services (WDS) Hands-Free Deployment Hardening Guidance related to CVE-2026-0386. Siehe auch meinen Beitrag Erinnerung: Im April 2026 endet die Unterstützung für Windows Deployment Service (WDS).
- [Kerberos protocol] This update changes the default DefaultDomainSupportedEncTypes value for Kerberos Key Distribution Center (KDC) operations to leverage AES-SHA1 for accounts that do not have an explicit msds-SupportedEncryptionTypes Active Directory attribute defined. For more information see, How to manage Kerberos KDC usage of RC4 for service account ticket issuance changes related to CVE-2026-20833.
- [Secure Boot] With this update, Windows quality updates include additional high confidence device targeting data, increasing coverage of devices eligible to automatically receive new Secure Boot certificates. Devices receive the new certificates only after demonstrating sufficient successful update signals, maintaining a controlled and phased rollout.
Das Update wird automatisch von Windows Update heruntergeladen und installiert, ist aber auch im Microsoft Update Catalog, per WSUS und WUfB erhältlich. Microsoft hat zudem das Service Stack Update (SSU) aktualisiert. Beachtet die im Support-Beitrag beschriebenen Installationsanforderungen und eventuelle Hinweise auf vorhandene Probleme.
Updates für Windows Server 2012 / R2
Windows Server 2012/R2 sind im Oktober 2023 aus dem Support gefallen und bekommen nur noch mit ESU-Lizenz Updates. Beachtet die Hinweise auf die Installationsreihenfolge für Windows Server, die Microsoft in den KB-Artikeln angibt.
Update KB5082126 für Windows Server 2012 R2
Die Update-Historie für Windows Server 2012 R2 ist auf dieser Microsoft-Seite zu finden. Für Windows Server 2012 R2 wurde Update KB5082126 (Monthly Rollup for Windows Server 2012 R2) für Systeme mit ESU-Lizenz freigegeben.
[Remote Desktop] Improved: This update improves protection against phishing attacks that use Remote Desktop (.rdp) files. When you open an .rdp file, Remote Desktop shows all requested connection settings before it connects, with each setting turned off by default. A one-time security warning also appears the first time you open an .rdp file on a device. For more information, see Understanding security warnings when opening Remote Desktop (RDP) files.
Dieses Update wird in Windows Server 2012 R2 automatisch von Windows Update heruntergeladen und installiert, ist aber auch im Microsoft Update Catalog sowie per WSUS erhältlich. Details zu Fixes sowie ggf. bekannte Probleme in Verbindung mit dem Update sind im Supportbeitrag genannt.
Update KB5082127 für Windows Server 2012
Die Update-Historie für Windows Server 2012 ist auf dieser Microsoft-Seite zu finden. Für Windows Server 2012 mit ESU-Lizenz wurde Update KB5082127 (Monthly Rollup for Windows Server 2012) freigegeben. Es enthält Sicherheitspatches und Bug-Fixes.
[Remote Desktop] Improved: This update improves protection against phishing attacks that use Remote Desktop (.rdp) files. When you open an .rdp file, Remote Desktop shows all requested connection settings before it connects, with each setting turned off by default. A one-time security warning also appears the first time you open an .rdp file on a device. For more information, see Understanding security warnings when opening Remote Desktop (RDP) files.
Dieses Update ist im Microsoft Update Catalog sowie per WSUS erhältlich. Bei einer manuellen Installation ist das neueste Servicing Stack Update (SSU) vorher zu installieren – wobei dieses SSU nicht mehr deinstalliert werden kann. Probleme im Zusammenhang mit dem Update sind im KB-Artikel angegeben.
Details zu obigen Updates sind im Zweifelsfall den jeweiligen Microsoft KB-Artikeln zu entnehmen.
Ä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
"[Remote Desktop] This update improves protection against phishing attacks that use Remote Desktop (.rdp) files"
Da wird in der IT die Telefonleitung aber glühen….
Ja, geht schon los…ich möchte mal wissen, was die MS-Vollpfosten sich wieder dabei gedacht haben? Anscheinend glauben die, alle Admins haben Langeweile…viele User klicken das sowieso einfach weg und machen weiter!
Da hat Microsoft wieder einmal ganze Arbeit geleistet… Selbst Microsoft Copilot sagt, dass Microsoft das Ganze richtig schlecht umgesetzt hat… Angeblich soll es eine Definition für eine GPO geben, um diese dämliche Warnmeldung abzuschalten, die sei aber noch nicht veröffentlicht. Ein Setzen von HKLM\Software\Policies\Microsoft\Windows NT\Terminal Services\Client\RedirectionWarningDialogVersion auf den Wert 1 verhindert das Anzeigen der Meldung jedenfalls nicht. Ich freue mich jetzt schon auf die ganzen Helpdesk-Tickets… Danke Microsoft, willkommen in den Hall of Shame!
Wenn ich folgenden Registry-Eintrag hinterlege, dann wird zumindest die neue Meldung "Öffnen einer Remotedesktopverbindung" nicht mehr angezeigt.
Bisher habe ich es nur in der Testumgebung unter Windows 11 24H2 getestet, somit unter Vorbehalt.
Inwiefern diese zusätzliche Abfrage einen Schutz bieten soll, wenn ich gleichzeitig als normaler User den Registry-Key zum Umgehen der Meldung hinterlegen kann erschließt sich mir zwar nicht aber was weiß ich schon……
HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client
RdpLaunchConsentAccepted = 1 (DWORD)
👍
Hat uns (fast) die halbe Firma lahmgelegt. Endanwender denken da sei ein Virus auf dem System und der übliche Kram. Diejenigen die sich einfach durchklicken sind mir da lieber. Es bringt auch überhaupt keinen Mehrwert. Für Enterprise-Umgebungen absolut nicht hinnehmbar.
Ich erwäge, in Zukunft wfreerdp zu nutzen (weil sich niemand durch ein RDP-Programmmenü hangeln muss) wenn man dieses sinnlose Harassment nicht dauerhaft abstellen kann (MS droht ja schon damit). Konfig ist etwas ärgerlich, aber ich habe damit Erfahrung von Linux her. Wo man nicht so behelligt wird.
Jep, hatte ich auch. Teilweise verwenden wir den kostenlosen Parallels Client für RDP, da können auch Kennwörter (dauerhaft) gespeichert werden (jaja, soooo unsicher, böse, böse).
Beachtet meine Hinweise und Zusammenfassung im Nachtrags-Blog-Beitrag:
Remote Desktop-Phishing-Schutz im April 2026-Update verursacht Verwirrung
Bezüglich der RDP Warnungen:
HKLM\Software\Policies\Microsoft\Windows NT\Terminal Services\Client
Name: RedirectionWarningDialogVersion
Typ: REG_DWORD
Daten: 1
hier die offizielle Quelle (ganz unten auf der Seite)
https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remotepc/understanding-security-warnings
Hurra, nach der Installation auf zwei Windows Server 2025 kann ich mich nicht mehr einloggen. das Passwort wird nicht mehr akzeptiert. bin mal gespannt ob ich das ohne Rollback wieder hinbekomme…
Könnte an der lang angekündigten RC4 Abschaltung liegen. Du hast noch bis Juli Zeit das in dsn Griff zu bekommen, danach ist Ende.
https://borncity.com/blog/2026/04/14/windows-haertung-neue-stufen-zum-14-april-2026/
Ich bin mir inzwischen nicht mehr so sicher, daß da nicht doch noch ein anderes Problem besteht. Einer unserer Admins hat berichtet, daß in einer neu eingerichteten Laborumgebung mit MS Windows Server 2025 dasselbe Problem aufgetreten ist. RC4-Altlasten konnten das nicht gewesen sein, weil die Umgebung nur aus einem DC und drei Mitgliedsservern besteht, die alle im Dezember 2025 völlig neu und auf neuer Hardware installiert wurden. Sie haben auch keine Verbindung zu einer bestehenden Domänenstruktur außerhalb ihrer eigenen.
wäre es sinnvoll noch vor dem installation der Patche auf dem Server mit https://www.stratesave.com/html/sidchg.html ne neue SID zu vergeben?
zusätzlich hab ich das noch gefunden
mit "klist" kann man auch RC4 prüfen
https://www.msxfaq.de/windows/kerberos/kerberos_rc4_abschaltung.htm
bei mir wären alle Server mit AES-256 vermerkt
@RMG -> Waren dies geklonte Systeme?!
Nein, aber Systeme, deren AD-Struktur über mehrere Servergenerationen weitervererbt wurde. Nach Passwortänderung geht es wieder, für die User habe ich jetzt eine erzwungen. Damit sollte es gehen.
Wenn die Domäne mit Windows Server 2003 erstellt wurde sind alle Passworte die seither nie geändert wurden noch mit RC4 verschlüsselt. Mit dem Upgrade der DC auf Server 2012 R2 wurden dann neue oder geänderte Passworte mit AES verschlüsselt wenn da für das Benutzerkonto im AD nichts anderes eingestellt wurde. Wenn ich mich richtig erinnere, haben wir dann einfach alle Passworte mit einem Änderungsdatum älter als das Upgrade-Datum der Domäne von 2003 auf 2012 geändert und gut war. Alle anderen mussten wir nicht anfassen.
Bezüglich Thema RC4-Abschaltung sehr gute Quelle:
https://www.msxfaq.de/windows/kerberos/kerberos_rc4_abschaltung.htm
Auch die Hinweise zur Änderung des Kennworts für KRBTGT aus der Quelle bei msxfaq.de sollten berücksichtigt werden, weil sonst u.U. keine Tickets mehr ausgestellt werden können, auch wenn die Benutzerkonten selbst nicht das Problem verursachen.
Wenn ein Server oder PC noch mit dem AD Account angemeldet ist dort mit Cmd das Kennwort ändern.
net user /domain administrator Test123
Dadurch setzt man den neuen AES-256 Verschlüsselungstyp und man kann sich wieder anmelden.
Bei uns lässt sich das 2026-04 Sicherheitsupdate (KB5082063) (26100.32690) auf keinem unserer Windows Server 2025 Standard Kundensysteme installieren. Er erfolgt immer der Fehler: 0x80073712. Wir haben die Server in Deutsch aufgesetzt.
Auch die Ausführung der Befehle dism.exe /online /cleanup-image /restorehealth und sfc /Scannow bringen keinen Erfolg. Da scheint meiner Ansicht ein generelles Problem noch vorzuliegen.
Gleiches Problem auch bei uns auch auf Windows Server 2025 Datacenter.
Auch das Heruntergeladene windows11.0-kb5082063-x64_2fb0b6b3988432626f68c231d154c35362ff58ea.msu brachte einen Fehler. Finde nur ich außer hier auf borncity keine Hinweise im Internet? Ist das eventuell nur die in deutsch installierte ein Problem?
Haben genau das gleich in grün. Deutscher Windows Server 2025 per Update oder msu immer der gleiche Fehler.
Da wurde ja wieder super getestet.
Hier das selbe Problem mit Windows Server 2025 Standard.
Die Installationssprache ist jedoch Englisch, allerdings ist zusätzlich das deutsche Sprachpaket installiert.
Gängige Workarounds haben bisher nicht geholfen.
Kann ich nicht bestätigen 3 Server DC, Application und RDS. Alle Win Server 2025 standard deutsch. Ohne Probleme.
Gleicher Fehle bei unseren Kunden 0x80073712. Ebenfalls deutsche Lokalisierung.
Allerdings tritt der Fehler nur bei physischen Servern und installierter HYPER V Rolle auf. Alles DELL Power Edge Server. Bei den virtuellen Servern (2025 Standard) läuft alles klaglos. Ebenfalls bei physischen Servern ohne HYPER V Rolle.
Wir haben dieses Problem bei uns durchgängig mit den Windows 2025er Servern und alle in Deutch. Ich habe testhalber mal einen auf englisch installiert. Selbes Problem. Kann es sein, dass Ihr auch ROK Lizenzen von HPE habt? Diese erstellen nur eine 100MB UEFI-Systempartition. Vielleicht liegt es daran? Wie gross ist eure UEFI-Systempartition bei den Systemen, welche den Update akzeptieren?
In einer de-de Windows Server 2025 VM hat sich KB5082063 auch problemlos installieren lassen.
Wir haben dieses Problem bei uns durchgängig mit den Windows 2025er Servern und alle in Deutsch. Ich habe testhalber mal einen auf englisch installiert. Selbes Problem. Kann es sein, dass Ihr auch ROK Lizenzen von HPE habt? Diese erstellen nur eine 100MB UEFI-Systempartition. Habe diese mal auf 500MB vergrössert, der gleiche Effekt.
Habe nun div. Tests gemacht: 2 Server mit einem WinSrv2025Std.-HPE-ROK-ISO Medium neu aufgesetzt. Einen in DE und der zweite in EN. Beide verweigerten die Installation des KB5082063. Anschliessend habe ich die Eval-ISO für den WinSRV2025Std. in DE und EN von Microsoft heruntergeladen und installiert. Bei beiden Eval-Installationen wurde das Update erfolgreich installiert. Alle 4 Server wurden auf der gleichen Hardware unter Hyper-V installiert und wurden nicht Lizenziert. Ich gehe davon aus, dass es was mit den OEM Branded Installationsmedien zu tun hat (HPE oder DELL). Diese haben ja einen sogenannten BIOS-Lock für die Lizenzierung implementiert.
Das klinkt ganz danach, das es an den OEM Branded Versionen/Lizenzen von Windows Server 2025 liegt.
Unsere Windows Server 2025 sind allesamt virtuelle Maschinen (VmWare) mit HP-ROK Lizenzen wo der Fehler damit auftritt. Server mit Windows Server 2019 (auch ROK) konnten das Update ohne Probleme installieren.
Hab das Problem hier auch mit einem HPE Server :-(
Wie jetzt? Macht Microsoft bei Servern nun doch die SecureBoot UEFI Zertifikate per Update, obwohl sämtliche Artikel behaupten bei Windows Servern müssen die Admins selbst aktiv werden? Maximal verwirrend alles
Ich verstehe das so: Die Zertifikate landen per Update in der UEFI-Standard-DB. Damit diese in der aktiven UEFI-DB angewendet werden, muss man manuell tätig werden.
Das war letzten Monat doch auch schon so und stand glaube ich auch im jeweiligem KB Artikel drin.
Die Bezeichnung "Standard-DB" ist hier aber irreführend. Es gibt eine "current" und eine "default". Microsoft kann nur die Zertifikate in der "current" austauschen, die "default" können nur vom OEM per BIOS Update ausgetauscht werden. Wurden die "default" nicht aktualisiert und du willst/musst einmal secureboot resetten, gehen dir die "current" alle flöten und du bist auf die "default" angewiesen.
VMWare 8, vCenter 8, Server 2025 Template heute geupdatet. Ausgerollte VM von diesem Template, zeigt nach Anmeldung, nur noch schwarzen Bildschirm. Versucht, im Taskmanager die explorer.exe zu starten, kein Erfolg. RDP Verbindung auf VM, ebenso schwarzer Bildschirm. Wenn ich das Template zurück in eine VM konvertiere und starte, dann erhalte ich nach der Anmeldung einen ganz normalen Desktop.
Gestern habe ich noch 2 VMs mit dem "alten" Template gebaut und die funktionieren.
Vielleicht kann jemand mein Problem bestätigen.
ist ein bekanntes Problem, aber schon seit längerem. Hängt mit dem Edge Paket zusammen.
einfach ein RunOnce mit in die Customization Specification einfügen:
powershell.exe -ExecutionPolicy Bypass -Command "& { Add-AppxPackage -Register -Path 'C:\Windows\SystemApps\MicrosoftWindows.Client.CBS_cw5n1h2txyewy\appxmanifest.xml' -DisableDevelopmentMode; Add-AppxPackage -Register -Path 'C:\Windows\SystemApps\Microsoft.UI.Xaml.CBS_8wekyb3d8bbwe\appxmanifest.xml' -DisableDevelopmentMode; Add-AppxPackage -Register -Path 'C:\Windows\SystemApps\MicrosoftWindows.Client.Core_cw5n1h2txyewy\appxmanifest.xml' -DisableDevelopmentMode; Start-Process explorer.exe }"
Ich habe auf einem 2022 Server, wo die CA installiert ist, folgenden Fehler mit dem April Update: "Das Richtlinienmodul "Windows-Standard", Methode "Initialize", hat einen Fehler verursacht. Die angegebene Domäne ist nicht vorhanden, oder es konnte keine Verbindung hergestellt werden. Zurückgegebener Statuscode: 0x8007054b (1355). Es konnte keine Verbindung mit dem Active Directory, das die Zertifizierungsstelle enthält, hergestellt werden."
Bis auf die Warnung scheint aber alles noch zu funktionieren…Zertifikate können jedenfalls noch ausgestellt werden.
Habs grad selber lösen können…Dienststart auf Automatisch (Verzögert) und alles ist fein :)
Wäre da nicht eher eine Abhängigkeit einzutragen, damit man Race Conditions vermeidet?
Da bin ich überfragt ;)
Bei uns ist es eben seit neustem so, dass die Server mit 10GBit angebunden sind und die Leistungseinstellungen des Servers hochgeschraubt wurde, sodass er eigentlich "zu schnell" startet. "Auf das Netzwerk warten" interessiert ihn nicht wirklich, und die Dienste starten zu schnell, das Netzwerk ist noch nicht verfügbar, weshalb der DC nicht gefunden wird und diese Meldung generiert. Ein paar Minuten später wird sie aufgelöst, aber durch das Verzögerte Starten kommt sie erst gar nicht mehr.
Welche Abhängigkeit würdest du vorschlagen in so einem Fall? :)
Wenn er keine Verbindung mit der Domäne herstellen kann oder sie nicht findet, klingt das meist nach einem DNS-Problem, ähnlich wie bei den Problemen mit NLA und nur einem Domänencontroller, wo das Netzwerk fälschlich nicht als Domänennetzwerk erkannt wird, weil DNS noch nicht gestartet ist. Ohne DNS ist eine Domäne nicht auffindbar. Daher würde ich zunächst vorschlagen, DNS als Abhängigkeit einzutragen, damit die Namensauflösung sicher erfolgt, wenn sie das Richtlinienmodul braucht. Wenn das allerdings nicht hilft, braucht es weitere Ermittlungen. Die physikalische Netzwerkschnittstelle wird es vermutlich nicht sein, die noch nicht bereit ist.
Hmm…also wenn ich den DNS-Dienst als Abhängigkeit eintrage, kommt die Fehlermeldung leider wieder. Aber ev. meintest du nicht den DNS-Dienst? :)
Da es eben wirklich unmittelbar nach dem Umstellen der Energieeinstellungen dieses Verhalten zeigte, hatte ich halt das Netzwerk im Verdacht. Weil auch alle anderen Dienste, speziell natürlich jene mit gMSA, starteten nicht mehr selber (manuell kein Problem), weil der DC noch nicht erreicht werden konnte. Mit verzögertem Start starten alle wieder. Nur einer benötigte eine zusätzliche Abhängigkeit. Der CA-Dienst läuft zwar nicht mit gMSA, aber hat natürlich enge Beziehungen zum DC.
Wie damals, als die PC's mit SSD's ausgestattet wurden und die dann beim Anmelden, weil zu schnell gebootet, keine Netzlaufwerke hatten. Bzw. die roten Kreuze, die sich dann ja auflösen beim Draufklicken.
Ja, ich habe den DNS-Server gemeint. Aber es ist natürlich auch möglich, dass es ganz andere Abhängigkeiten gibt, und wenn Energieeinstellungen möglicherweise eine Rolle spielten, dann kann es sich natürlich durchaus auch um ein Problem mit der Netzwerkschnittstelle als solcher handeln, denn dann wäre auch mit funktionierender Namenauflösung nichts erreichbar.
Um die erste Warnmeldung zu deaktivieren muss folgender Registry Key gesetzt werden:
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Terminal Server Client
Name: RdpLaunchConsentAccepted
Typ: REG_DWORD
Daten: 1
Danke T&M – genau danach habe ich gesucht! Wert per GPO setzen und dann ist Ruhe im Karton. :-)
Hier das ganze als "einzeiler", muss mit Adminrechten laufen:
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\Client" /v RedirectionWarningDialogVersion /t REG_DWORD /d 1 /f
Hm, also ich finde es eigentlich nicht verkehrt eine Warnung beim erstmaligen Öffnen einer RDP-Datei anzuzeigen. Das ist definitiv ein Angriffsvektor. Zumindest die meisten unserer User schätze ich so ein, dass sie dann vorsichtiger agieren würden.
Und natürlich gibt es immer ein paar User die bei jeder Kleinigkeit anrufen. Mir ist aber lieber sie geben Bescheid als es unter den Tisch fallen zu lassen, wenn es mal ernst ist. Für Unternehmensinterne ITler kann ich nur empfehlen einen Kommunikationsweg an alle User zu etablieren. Eine Rundnachricht und das ist erledigt.
Als IT-Dienstleister ist das schon schwieriger.
Die Beschreibung verstehe ich so, dass die Warnung pro Verbindung angezeigt wird. D.h. es müsste eine Mechanik geben, mit der man gezielt "seine" Verbindungen frei geben kann. Wäre natürlich schön, wenn es dazu eine Dokumentation vorab von MS gegeben hätte, anstatt das hinterher über Debuggen rausfinden zu müssen.
Ich kann auch nicht ganz nachvollziehen, warum RDP-Dateien per Default genutzt werden. Da gibt's doch sicher bessere Wege. Und "Power"-User wissen auch mit ner Warnung umzugehen.
RDP-Dateien mit einem Zertifikat signieren. Die dazugehörige GPO heißt:
"Specify SHA1 thumbprints of certificates representing trusted .rdp publishers"
Ergänzend zu Daniel – drüben im Windows 10/11-Artikel zum April Update hat Tobi einen Reddit-Post verlinkt. Im Kommentar von Cormacolinde gibt es einen Link wie man RDP-Dateien signiert und wo die GPO zu finden ist.
https://borncity.com/blog/2026/04/15/patchday-windows-10-11-updates-14-april-2026/#comment-252772
Beachtet meinen Nachfolgebeitrag Remote Desktop-Phishing-Schutz im April 2026-Update verursacht Verwirrung
Dankeschön, schaue ich mir an.
Ja, die Warnung wird bei jedem Aufruf eingeblendet. Signiert man die RDP-Datei, wird der Publisher in der Warnung mit angezeigt, aber sie erscheint dennoch jedes Mal. Bei signierten Verbindungen kann man zumindest die durchgeleiteten Ressourcen (Zwischenablage, Laufwerke) merken lassen, sonst muss man die immer wieder neu auswählen.
Was fehlt ist eine Option, die eine signierte RDP-Datei als vertrauenswürdig einstuft, sodass nicht noch einmal gewarnt wird und die Ressourcen wie voreingestellt übertragen werden. Wenn diese Warnung jedes Mal kommt, wird sie auch bei betrügerischen Verbindungen ignoriert. Da ist es sinnvoller sie gleich abzuschalten und RDP-Dateien anderweitig abzusichern.
Server 2022 macht soweit keine Probleme. Darunter waren auch DCs und Hyper-V Hosts.
Auch hier: MS Windows Server 2022 Standard (DC, physikalische Maschine), aktualisiert. 2 Neustarts. Bislang keine Probleme sichtbar.
Server 2016 scheint auch problemlos durchzulaufen.
kann es sein das die RDP Meldung nur bei Rechnern erscheint die Mitglied einer Domäne sind? Ich hatte die Meldung beim Starten der RDP auf einem Firmennotebook, wenn ich mich auf den gleichen Server verbinde mit einen Notebook was nicht Mitglied der Domäne (via VPN) ist kommt die Meldung nicht.
Anmerkung: ich bin nicht der gleiche mit der Meldung zu Server 2022 …(und Hyper-V)
Kann hier nicht nachvollzogen werden:
Windows 11 Pro 25H2 26200.8246, nicht in Domäne, mit RDP-Datei (nicht Herausgeber signiert) Verbindung zu Windows Server 2019 (nicht in Domäne) starten, alle neuen Sicherheitswarnungen werden angezeigt.
Konstellation bei mir:
Terminalserver in Domäne – Client in Domäne = Meldung
Terminalserver in Domäne – Client nicht in Domäne = keine Meldung
Hier:
Terminalserver in Domäne – Client nicht in Domäne = Meldung
Keine Ahnung warum es da unterschiedliches Verhalten gibt.
Windows Server 2022 21H2 – Die Funktion „Aktualisieren und Herunterfahren" funktioniert nicht mehr im Zuge der Installation von KB5082142. Server startet am Ende des Update-Vorgang neu anstatt herunter zu fahren. Bisher zwei virtuelle Server auf ESXi betroffen. Nicht schlimm, aber so hatte man nach dem Update immer ein Kaltstart ohne einen zusätzlichen Boot-Vorgang dazwischen.
Bei meinem Heimrechner (Windows 10 22H2) ist das genau so, aber erst seit wenigen Monaten. Vorher ging das ohne Probleme, aber MS hat es geschafft das bei einem nicht mehr supporteten OS kaputt zu machen.
Für SQL Server 2017 – 2025 gibt es diesen Monat auch wieder Updates:
https://learn.microsoft.com/de-de/troubleshoot/sql/releases/download-and-install-latest-updates
es ist immer kurios bei uns … Updates für SQL Server kommen über Windows Update rein aber muss immer den Server erst neu starten, da beim ersten Setup-Versuch das Setup abbricht.
Kennt das wer?
Die SQL Updates mögen keine pending Reboots. Entweder vorher installieren oder getrennt nach einem Neustart. Und die brauchen auch selbst einen Neustart. Die neueren kriegen aber in ein paar Tagen eh ein kumulatives Update und da ist das Sicherheitupdate auch enthalten. Und neulich gab es einen neuen Odbc 18, aber noch nicht per WSUS
Aus eigener (negativer) Erfahrung:
SQL Server Updates und Exchange Server Updates werden in unserer Umgebung immer manuell installiert.
WSUS bzw. Updates über Windows bleiben außen vor.
Download der Updates für den SQL Server, siehe:
https://learn.microsoft.com/de-de/troubleshoot/sql/releases/download-and-install-latest-updates
Mit Windows-Update auf einem Windows Server 2019 mit SQL Server 2017 scheitert hier das SQL-Update regelmässig im ersten Durchgang weil zuerst das CU vom Windows Server installiert wird. Dafür dürfte der ausstehende Reboot ursächlich sein, welcher von der CU-Installation angefordert wird. Danke an Robert G. für diesen Hinweis.
Der gleiche Update-Vorgang auf Windows Server 2022 mit SQL Server 2019 oder 2022 läuft hingegen ohne Fehler durch weil Windows Server 2022 immer zuerst das SQL Server Update installiert. Dieses Verhalten ist seit Monaten und auf verschiedenen Servern gleich.
Moin,
also alle Server gestern gemacht und heute den 2. DC
Alles ohne Probleme doch durchgelaufen … anmeldungen überall möglich. Alles super.
Mal sehen was nächstes Monat alles wieder kommt…
Schöne Restwoche
Hallo,
die Meldung ist eingentlich nicht das Störende. Das aber kein Drucker und auch kein USB Stick mit in der Sitzung verfügbar die am Client hängen ist schon sehr bedenklich. Egal was in der .rdp Verbindung hinterlegt ist. Nur wenn man einen Haken bei Drucker in der neuen Meldung setzt, wird dieser auch eingebunden.
Hat MS wieder toll hinbekommen.
Grüße an all e Mitleidenden
KB5083769 ist ein Update der Sonderklasse! Kommt da nur noch Zwangsmüll runter? –
Ganz genau 15 Tage läuft mein Win 11 endlich mal seit Jahre super rund und nun dieses Update, wow… was die absolute Härte seit Firmen Gründung ist, jedenfalls für mich!
Outlook Problem bewältigt, alles andere von Office läuft nach dem Update über anderen Konten, wow! 2 Existieren gar nicht mehr, laufen aber mit 2024 obwohl das eine ein Uraltkonto (Office 2016 / E-Mail existiert gar nicht mehr) war und das letzte alte mit 2019 bestückt. Hätten nicht die gespeicherten Dateien verrücktspielen (angeblich teilweise schreibgeschützt?) würde man gar nicht so schnell über diesen neuen suuuper Bug stolpern. Ein Bug flickt nur noch den nächsten! – 🫨 Hoffentlich klickt es mal demnächt und man erinnert sich daran das weniger mehr ist…. bevor die -23 % noch weiter in den Keller gehen.
Denn es war einmal und ist leider nicht mehr ein super Programm…
Moin, unter bestimmten Voraussetzungen können DCs mit dem April-Update in einer Rebootschleife hängen. https://administrator.de/info/patchday-domaincontroller-rebootschleife-windows-server-677672.html
Hallo, seit dem Patchday funktioniert auf unseren Win2016 Terminalservern der SMB-Zugriff nicht mehr. Keine der Freigaben funktioniert mehr. Auf "Nicht-Terminal-2016- Server" funktioniert die Freigabe.
Als weiteres Problem beim 2016er Terminalserver startet der Anmeldedienst nach einem Reboot nicht mehr Automatisch bzw. wird beendet. Meldung: Der Endpunkt ist doppelt. Anschließend kann man ihn wieder starten und er läuft.
Ist das Problem in anderen Umgebungen auch aufgetreten? Ich finde dazu nichts aktuelles im Netz.
Hallo, kann das jemand mit dem SMB Problem bei Terminalservern 2016 bestätigen?
LDAPS – Anmeldung an Drucker für Follow-me-to-print gestört, es kommt zu einem Timeout, hat jemand ebenfalls solche Probleme
eben noch mal geschaut, auf dem Printserver fehlte das aktuelle Update, auf den DC's war es bereits installiert, nach Instalation und anschliessendem Reboot alles ok
7 Out-of-Band Updates für Server wurden am 19.April 2026 veröffentlicht.
Gefixt werden Rebootschleife bei Domain Controllern und der Fehlercode 0x80073712.
Windows Server 2025: KB5091157 (OS Build 26100.32698) Out-of-band
Windows Server, version 23H2: KB5091571 (OS Build 25398.2276) Out-of-band
Windows Server 2022: KB5091575 (OS Build 20348.5024) Out-of-band
Windows Server 2019: KB5091573 (OS Build 17763.8647) Out-of-band
Windows Server 2016: KB5091572 (OS Build 14393.9062) Out-of-band
Windows Server 2025 Datacenter: Azure Edition: Hotpatch KB5091470 (OS Build 26100.32704) Out-of-band
Windows Server 2022 Datacenter: Azure Edition: Hotpatch KB5091576 (OS Build 20348.5029) Out-of-band
*ttps://www.deskmodder.de/blog/2026/04/20/windows-server-out-of-band-updates-korrigieren-startprobleme-und-installationsfehler-0x800f0983/
Hallo zusammen,
wir sind dabei die Umstellung der Secureboot Zertifikate durchzuführen. Jetzt wird nach der Installation des letzten Windows Updates die Event ID 1801 nicht mehr nach dem Start der Aufgabe zur Prüfung und Aktualisierung angezeigt.
Event ID 1801:
Aktualisierte Zertifikate für den sicheren Start sind auf diesem Gerät verfügbar, wurden aber noch nicht auf die Firmware angewendet. Lesen Sie den veröffentlichten Leitfaden, um das Update abzuschließen und den vollständigen Schutz aufrechtzuerhalten. Diese Gerätesignaturinformationen sind hier enthalten.
DeviceAttributes:
BucketId:
BucketConfidenceLevel:
UpdateType:
Weitere Informationen finden Sie unter https://go.microsoft.com/fwlink/?linkid=2301018.
Ist da was bekannt?
Hallo zusammen
Wir haben seit der Installation der Patches das Problem, dass unsere "nicht Domain-Server" nicht mehr an den WSUS rapportieren. Die Ausnahme sind Windows Server 2025 Systeme. Das Problem scheint zu bestehen, seit dem der WSUS-Server (WS2022) gepatched wurde. Es lässt sich temporär lösen, indem der "SoftwareDistribution" Ordner um-benannt wird. Danach funktioniert es für ~12 – 24 Stunden wieder.
Hat jemand hier ein ähnliches Verhalten festgestellt?