Am 14. April 2026 (zweiter Dienstag im Monat, Patchday bei Microsoft) hat Microsoft kumulative Updates für die noch unterstützten Client-Betriebssystem-Versionen von Windows 10 (mit ESU-Lizenz) und Windows 11 veröffentlicht. Hier einige Details zu diesen Updates, die Schwachstellen sowie Probleme beheben sollen.
Details zu den per Updates geschlossenen Sicherheitslücken sind im Beitrag Microsoft Security Update Summary (14. April 2026) beschrieben.
Updates für Windows 11
Eine Liste der Windows 11 Updates lässt sich auf dieser Microsoft-Webseite abrufen. Ich habe nachfolgend die Details herausgezogen. Für die oben erwähnten Windows 11 Version stellt Microsoft nun folgende Updates bereit.
Update KB5083769 für Windows 11 24H2-25H2
Das kumulative Update KB5083769 für Windows 11 24H2-25H2 beinhaltet Qualitätsverbesserungen sowie Sicherheitspatches. Mit diesem Update werden verschiedene Sicherheitsverbesserungen an internen Betriebssystemfunktionen vorgenommen. Microsoft listet im Supportbeitrag einige Details zu Fixes, u.a. folgende, auf.
- [Secure Boot]
- New! The status of Secure Boot certificate updates on your device may be displayed in the Windows Security app (Settings > Privacy & security > Windows Security). Learn more about the status alerts via badges and notifications. These enhancements are disabled by default on commercial devices.
- 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.
- [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.
- [Reset this PC (known issue)] Fixed: This update addresses an issue that might cause device reset to fail when using the "Keep my files" or "Remove everything" options. This might occur after installing the March 2026 (KB5079420) Hotpatch security update.
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 Windows 11 Servicing Stack Update integriert. Vom Update ggf. verursachte Probleme sind im Support-Beitrag aufgeführt.
Update KB5082052 für Windows 11 23H2
Das kumulative Update KB5082052 für Windows 11 23H2 Enterprise und Education beinhaltet Qualitätsverbesserungen sowie Sicherheitspatches.
- [Secure Boot]
- New! The status of Secure Boot certificate updates on your device may be displayed in the Windows Security app (Settings > Privacy & security > Windows Security). Learn more about the status alerts via badges and notifications. These enhancements are disabled by default on commercial devices.
- 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.
- [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. Ergänzung: Beachtet meinen Nachfolgebeitrag Remote Desktop-Phishing-Schutz im April 2026-Update verursacht Verwirrung.
- [Sign-In] Fixed] After you install the Windows update released on or after March 10, 2026, some users might experience an issue signing in to apps with a Microsoft account. Even when the device has a working Internet connection, a "no Internet" error appears during sign in and prevents access to Microsoft services and apps such as Microsoft Teams.
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 Windows 11 Servicing Stack Update integriert. Bekannte, vom Update ggf. verursachte Probleme werden, im Support-Beitrag aufgeführt.
Windows 11 23H2 Home und Pro sind aus dem Support gefallen und haben zum 11. November 2025 letztmalig ein Update erhalten.
Updates für Windows 10
Windows 10 22H2 ist im Oktober 2025 aus dem Support gefallen und es gibt nur noch Updates im ESU-Programm. Eine Liste der Updates lässt sich auf dieser Microsoft-Webseite abrufen. Ich habe nachfolgend die Details herausgezogen.
Update KB5082200 für Windows 10 Version 21H2 – 22H2
Das kumulative Update KB5082200 enthält diverse Sicherheitsfixes und ist für Windows 10 21H2 Enterprise LTSC sowie ESU-Maschinen mit 22H2 verfügbar. Als Fixes listet der Supportbeitrag folgendes auf:
- [Sign-In] Fixed: After you install the Windows update released on or after March 10, 2026, some users might experience an issue signing in to apps with a Microsoft account. Even when the device has a working Internet connection, a "no Internet" error appears during sign in and prevents access to Microsoft services and apps such as Microsoft Teams.
- [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 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.
Microsoft weist darauf hin, dass dieses Update Qualitätsverbesserungen am Servicing Stack (ist für Microsoft Updates verantwortlich) durchführt. Dieses Update wird automatisch von Windows Update heruntergeladen und installiert, ist aber auch im Microsoft Update Catalog und per WSUS sowie WUfB erhältlich. Beachtet die ggf. im Support-Beitrag beschriebene Hinweise zur Installation (vorausgesetztes SSU) und zu ggf. bekannten Problemen.
Update KB5082123 für Windows 10 Enterprise 2019 LTS
Das kumulative Update KB5082123 (wird unter Windows 10 v1809 einsortiert, bezieht sich aber auf Windows 10 2019 Enterprise LTSC und IoT Enterprise LTSC) und beinhaltet Sicherheitsfixes sowie folgende Korrekturen.
- [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 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 Installationsvoraussetzungen und Hinweise auf eventuell vorhandene Probleme.
Update KB5082198 für Windows 10 Version 1607
Für Windows 10 1607 Enterprise LTSC steht das Update KB5082198 zur Verfügung. Dieses Update adressiert Sicherheitsprobleme sowie die beschriebenen Korrekturen, wird automatisch von Windows Update heruntergeladen und installiert, steht aber auch im Microsoft Update Catalog als Download zur Verfügung (nach der KB-Nummer suchen lassen). Vor der manuellen Installation muss das aktuellste Servicing Stack Update (SSU) installiert werden. Details sind im jeweiligen KB-Artikel zu finden.
Für die restlichen Windows 10 Versionen gab es kein Update, da diese Versionen aus dem Support gefallen ist. 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
KB5082419 – NET Framework 3.5, 4.8.1 (für Win10 21H2 und 22H2)
KB5084067 – NET Framework 3.5, 4.8, 4.8.1 (für Win10 21H2)
KB5084068 – NET Framework 3.5, 4.8, 4.8.1 (für Win10 22H2)
KB5082420 – NET Framework 3.5, 4.8.1 (für Win11 24H2)
KB5082417 – NET Framework 3.5, 4.8.1 (für Win11 25H2)
Microsoft .NET Desktop Runtime 8.0.26
*ttps://dotnet.microsoft.com/en-us/download/dotnet/8.0
Microsoft .NET Desktop Runtime 9.0.15
*ttps://dotnet.microsoft.com/en-us/download/dotnet/9.0
Microsoft .NET Desktop Runtime 10.0.6
*ttps://dotnet.microsoft.com/en-us/download/dotnet/10.0
Safe OS (WinRE):
KB5082239 – Safe OS – Windows 10 Version 1607
KB5082240 – Safe OS – Windows 10 Version 1809
KB5082241 – Safe OS – Windows 10 Version 21H2
KB5082242 – Safe OS – Windows 11 Version 23H2
KB5083826 – Safe OS – Windows 11 Version 24H2 und 25H2
KB5083817 – Safe OS – Windows 11 Version 26H1
KB5082243 – Safe OS – Windows Server 21H2
KB5082235 – Safe OS – Windows Server 23H2
KB5082237 – Safe OS – Windows Server 24H2
MSFT hat jetzt noch KB5087371 Safe OS für Windows 10 21H2/22H2 nachgeschoben, das WinRE erst auf 10.0.19041.7177 mit dem aktuellem Boot Manager bringt.
Es ist bisher aber nur per Online Update verfügbar. In Update Catalog und WSUS fehlt es nach wie vor.
Ohne dieses Update bekommt man u. U. beim Rollback ein kaputtes System. Also Vorsicht oder WinRE selbst von einem bereits aktualisierten System kopieren.
Diese Problem betrifft wohl auch noch ältere Windows 10 und einige Server Versionen. Also auch dort Vorsicht bis das allgemein verfügbar ist.
Windows 11 23H2, 24H2, 25H2 und 26H1 sind aber nicht betroffen gewesen.
Groß genug muss die Recovery Partition unabhängig hiervon sein, damit sich die winre.wim auch aktualisieren lässt.
Das KB5087371 installiert das KB5082241.
Letzteres ist oben in der Liste und im Catalog drin, allerdings nur als cab und man muss es manuell mit dism installieren.
Ich hatte KB5082241 am Patchday manuell installiert, inklusive vorheriger SSU-Installation.
Die Version ist bei beiden identisch 10.0.19041.7177.
Die neue WinRE.wim benötigt 567.423.165 Byte Speicherplatz.
Im Vergleich dazu benötigte die originale WinRE.wim 443.881.289 Byte.
Bzgl. NET Framework, es gibt eine neue Kategorie für WSUS
".NET Framework 3.5"
Darin war gestern nur das KB5084165 für 26H1 ARM64 enthalten.
5x MS Windows 11 25H2 Enterprise aktualisiert. 2-4 Neustarts. Bislang keine Probleme feststellbar.
Das Update zum Remote Desktop Client ist ja mal klasse.
Man muss die RDP Dateien nun digital signieren, sonst kann der User die Sicherheitswarnungen nicht mehr "für immer" bestätigen.
Das soll Sicherheit bringen. Also ich weiss ja nicht. Gibt es bekannte Betrugsfälle in welchen ein User auf Fremde RDP Verbindungen zugegriffen hat und dadurch zu schaden gekommen ist? Ich vermute mal wenn das der Fall ist, dann hätte der User auch die Sicherheitsmeldung abgenickt.
Oben steht, dass die Warnung nur beim ersten Ausführen der RDP-Datei aufkommt. Falls das stimmt und man die Warnung bestätigt, wäre das ja quasi "für immer", oder?
Wir hatten das heute auch schon bei einem User, auf dessen Client gestern das April-Update installiert wurde. Auf dem RDS-Server ist es noch nicht installiert.
Mal schauen, was da noch kommt.
Es kommen zwei Meldungen, die eine kann man per Häkchen deaktivieren, die zweite nicht, bei der steht es auch explizit dran, dasss die gesetzten Häkchen nur bis zum Sitzungsneustart gelten, sprich, fliegt man mal aus dem VPN und will wieder rein muss man neu das Häkchen bspw für Zwischenablage setzen.
https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remotepc/understanding-security-warnings
(siehe reg key ganz unten auf der Seite)
Ach wer lesen kann … bis zum Schluss
Danke! :c)
Den nun einmalig beim Aufbau der ersten RDP-Verbindung angezeigten Bestätigungsdialog kann man (bei Bedarf für bestimmte Szenarien innerhalb Organisationen) wie folgt per Gruppenrichtlinie (Registry-GPP) oder alternativ via Login-Skript deaktivieren / unterdrücken:
[HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client]
"RdpLaunchConsentAccepted"=dword:00000001
Dieser Registry-Wert wird beim Bestätigen des Dialogs auch gesetzt.
Dabei muss allerdings beachtet werden: Die Konfiguration ist benutzerspezifisch und muss daher dann auch für jeden Benutzer separat konfiguriert werden!
Eine offizielle Microsoft Dokumentation dazu habe ich bisher allerdings leider nicht gefunden, aber im Praxistest funktioniert es bisher einwandfrei!
Den nun einmalig beim Aufbau der ersten RDP-Verbindung angezeigten Bestätigungsdialog kann man (bei Bedarf für bestimmte Szenarien innerhalb Organisationen) wie folgt per Gruppenrichtlinie (Registry-GPP) oder alternativ via Login-Skript deaktivieren / unterdrücken:
[HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client]
"RdpLaunchConsentAccepted"=dword:00000001
Dieser Registry-Wert wird beim Bestätigen des Dialogs auch gesetzt.
Dabei muss allerdings beachtet werden: Die Konfiguration ist benutzerspezifisch und muss daher auch für jeden Benutzer separat konfiguriert werden!
Eine offizielle Dokumentation dazu habe ich bisher allerdings leider nicht gefunden, aber im Praxistest funktioniert es bisher einwandfrei!
Ich habs gerade hier getestet. Selbst bei signierten RDP Files ist kein "schnelles verbinden" mehr möglich, es erscheint immer ein Fenster mit Aussteller und welche Features aktiv sein sollen (Clipboard, Printer…).
Tolles Update.
Zertifikate selbst signiert oder über die ganze Litanei mit CA, etc.?
It not depend …. My users have rdp file, signed with certificate deployed by trusted CA. Certificate hash is deployed (complete nonsense btw) by GPO (Windows Components/Remote Desktop Services/Remote Desktop Connection Client/Specify SHA1 thumbprints of certificates representing trusted .rdp publishers). So that file is "2times trusted". Moreover another GPO (System/Credentials Delegation) named exactly that server (it's about use same login cred as you logged on). And … server use tls cert from same CA.
And everyone have this popups about "unsecure" rdp connections.
Hier auch so. Die RDP Dateien sind mit einem mit dem Domänen-Root-Zertifikat signierten Herausgeberzertifikat signiert. Das zusätzliche Fenster mit Aussteller und Features (Clipboard, Printer …) wird immer angezeigt. Einzig die Voreinstellung der Features lässt sich speichern. Damit gewöhnt man dem Benutzer das unbedachte klicken gerade zu an, da er nicht mehr lesen wird was dort steht und ob der Herausgeber bekannt ist oder nicht. Gut gemeint, schlecht gemacht.
Also trotz Domänen-CA-Kette der Warnhinweis?
Womit, bzw. wogegen soll man die RDP-Dateien denn signieren?!?
Ja.
Vermutlich funktioniert es selbst mit RDP Dateien nicht, wenn Microsoft diese selber signieren würde. Die Sache wurde nicht zu Ende gedacht. Helfen würde zum Beispiel eine Gruppenrichtlinie mit einer Liste von Herausgeberzertifikaten denen man als Organisation vertraut. Damit könnte dann die Warnung unterdrückt werden wenn alles passt und trotzdem vor potenziell gefährlichen Verbindungen gewarnt werden die der Organisation nicht bekannt sind. Die Liste müsste als Computer-GPO realisiert werden, damit der Nicht-Admin-User diese nicht manipulieren kann. Müsste – so oder etwas Ähnliches gibt es aber bisher leider nicht. Man kann es somit aktuell nur ganz abschalten, mit einem in den Kommentaren genannten Registry-Werten, oder die zusätzliche Klickerei dem Anwender zumuten.
So bekommt ihr die Warnmeldung bei signierten Dateien weg:
https://www.reddit.com/r/sysadmin/comments/1sm61eo/comment/ogclwab/
Danke für den Tipp! Funktioniert perfekt so.
Bei uns funktionieren auf den bereits mit Update versehenen Rechnern die .rdp-Dateien auf die Terminalserver weiterhin ohne Meldung.
Das entsprechende Zertifikat ist allerdings auch über GPO in Windows-Komponenten/Remotedesktopdienste/Remotedesktopverbindungs-Client in der Option "SHA1-Fingerabdrücke von Zertifikaten angeben, die vertrauenswürdige RDP-Herausgeber darstellen" hinterlegt.
Habt ihr das auch oder "nur" ein Zertifikat der lokalen PKI verwendet? Letzteres hat bei uns auch bisher schon zu Rückfragen bei Benutzung geführt.
Hier funktioniert die Unterdrückung der zusätzlichen Warnung wenn das Herausgeberzertifikat von der Domänen-CA (Enterprise CA) signiert wurde und der Rechner Mitglied der Domäne ist und das Herausgeberzertifikat in der Registry eingetragen ist. Ist der Rechner nicht Mitglied der Domäne haben wir folgendes gemacht:
https://borncity.com/blog/2026/04/16/remote-desktop-phishing-schutz-im-april-2026-update-verursacht-verwirrung/#comment-252809
Beachtet meine Hinweise und Zusammenfassung im Nachtrags-Blog-Beitrag:
Remote Desktop-Phishing-Schutz im April 2026-Update verursacht Verwirrung
Das mit dem RDP ist mal wieder ein Murks von Microsoft. Kann aber temporär deaktivert werden.
Powershell:
Set-ItemProperty -Path "HKCU:\Software\Microsoft\Terminal Server Client" -Name "AuthenticationLevelOverride" -Value 0
"A future Windows update might remove support for this setting, even on older versions of Windows. Plan to transition your environment to work with the new security dialog."
Wenn das witklich kommt, bleibt nur mehr ein alternativer Client wie Parallels oder ein Command-Aufruf wie aus dem Keepass heraus :-/ .
Das ist auch nicht der Regkey aus der offiziellen MS-Doku. Wo hast du den her? Macht der noch irgendwas Anderes?
Das ist der "alte" Key wo die Abfrage nach dem gültigen Zertifikat unterbunden wird, das ist aber was anderes als die jetzige RedirectionWarningDialogVersion .
Hallo,
Microsoft says that Administrators can temporarily disable these protections by going to the HKLM\Software\Policies\Microsoft\Windows NT\Terminal Services\Client Registry key and modifying the RedirectionWarningDialogVersion value so it is set to 1.
However, as RDP files have historically been abused in attacks, it is strongly recommended to keep these protections enabled.
Updates für Windows 10 22H2 sind nicht im WSUS drin.
Da finden sich nur Updates für Windows 10 1607 und für keine andere Windws 10-Version.
Lt. Syncronisierungsbericht des WSUS wurden die Updates ihm auch nicht angeboten.
Da hakt es anscheinend bei Microsoft.
Die Onlinesuche auf den Windows 10-Rechnern dagegen findet die Updates.
Hat noch jemand den "Spaß" der nun aktivierten Smart-App-Control bei Windows 11- Rechnern? Einige PCs (ohne Domäne) haben das nun aktiv und es können dann keine Programme mehr installiert werden und auch PCVisit klappt nicht mehr. Merkwürdiger Weise Anydesk schon. Musste den Kram schon bei mehreren Geräten abschalten.
Die Vernagelung schreitet fort, eines schönen Tages nur noch Software via digital ID verifiziertem Microsoft Account, wartet es ab.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CI\Policy: VerifiedAndReputablePolicyState (REG_DWORD): 0
Dies deaktiviert Smart App Control.
Wobei ohne Domäne die Deaktivierung manuell wohl praktisch gleich schnell geht ;)
Wenn die "Smart App Control" einmal deaktiviert wurde, dann ist sie nie mehr aktivierbar.
Das sollte man als schwere Nebenwirkung immer mit dazuschreiben.
Vielleicht braucht man es in Zukunft mal, aber das geht dann nicht mehr.
Also sollte man sich vorher sehr genau überlegen, ob man das wirklich abschaltet.
Vielleicht gilt meine Behauptung aktuell nicht mehr, denn in der FAQ steht es jetzt anders drin:
Zitat:
"Ja, wenn es für Ihr Gerät verfügbar ist, können Sie smarte App-Steuerung in den Windows-Sicherheit App-Einstellungen aktivieren. Aktuelle Windows-Updates ermöglichen die Aktivierung der smarten App-Steuerung, ohne dass eine sauber Installation erforderlich ist."
*ttps://support.microsoft.com/de-de/windows/smart-app-control-h%C3%A4ufig-gestellte-fragen-285ea03d-fa88-4d56-882e-6698afdb7003
Weiß jemand, ab welchem Update Microsoft das geändert hat (falls es überhaupt geändert wurde) und ob die Reaktivierung von SAC jetzt problemlos funktioniert?
Beim BSI steht es nämlich anders:
"Benutzerinnen und Benutzer können nur entscheiden, ob SAC deaktiviert ist oder nicht, da der Deaktivierungsvorgang endgültig ist und es daher keinen Weg zurück in den aktivierten Zustand gibt."
*ttps://www.bsi.bund.de/DE/Service-Navi/Publikationen/Studien/SmartApp_Control/Smart_App_Control.html
Hier im Blog steht es ebenfalls so wie beim BSI:
*ttps://borncity.com/blog/2026/01/21/windows-11-25h2-feature-smart-app-control-macht-probleme/
Am 16.Dezember 2025 hatte Microsoft angekündigt, Smart App Control wieder einschaltbar zu machen, ohne Windows neu installieren zu müssen:
"Microsoft confirms you can soon disable Smart App Control without reinstalling Windows 11"
[…]
"This change will roll out in 2026"
*ttps://www.windowslatest.com/2025/12/16/microsoft-confirms-you-can-soon-disable-smart-app-control-without-reinstalling-windows-11/
Am 7.November 2025 wurde dieses neue Feature (SAC re-enable ohne Windows-Neuinstallation) mit Windows 11 Build 26220.7070 im Dev und Beta-Kanal veröffentlicht.
"We're updating Smart App Control (SAC) so you will now be able to switch SAC off or on without any clean install requirement."
*ttps://www.elevenforum.com/t/kb5070300-windows-11-insider-dev-and-beta-build-26220-7070-25h2-nov-7.41786/
Ob und wann dieses Feature für alle veröffentlicht wird bzw wurde habe ich noch nicht gefunden.
Dort steht, das Feature wurde bereits mit dem Februar-Update veröffentlicht:
*ttps://www.ad-hoc-news.de/boerse/news/ueberblick/microsoft-macht-windows-sicherheitsfeature-smart-app-control-flexibel/68565949
*ttps://www.windowslatest.com/2026/02/10/windows-11-kb5077181-25h2-out-with-new-features-direct-download-links-for-offline-installers-msu/
*ttps://www.bleepingcomputer.com/news/microsoft/windows-11-kb5077181-and-kb5075941-cumulative-updates-released/
Das wäre dann also Update KB5077181 (Win11 24H2 und 25H2 Rollup Februar 2026).
Builds 26200.7840 und 26100.7840
Ich habe dieses neue Feature in Zusammenhang mit diesem Updatge bei Microsoft aber bisher noch nicht dokumentiert gesehen.
Im Blog-Artikel zum Preview KB5079391 März 2026 wird es erwähnt:
"[Smart App Control] New! You can turn Smart App Control (SAC) on or off without needing a clean install."
*ttps://borncity.com/blog/2026/03/27/windows-11-24h2-25h2-preview-update-kb5079391-26-maerz-2026/
Warum wurde dieses Feature bei Bleeping Computer bereits am Patchday 10. Februar 2026 als Bestandteil des Updates erwähnt, während das selbe Feature hier im Blog erst am 26.März 2026 mit dem Preview für April 2026 erwähnt wurde?
Ist das Feature nun seit Februar oder erst seit April veröffentlicht und aktiv?
Zu KB5074105 (29.Januar 2026 Preview für Februar):
Im Changelog steht mit Datum 11.Februar 2026 (also *NACH* dem Patchday 10.Februar), dass dieses vorher dokumentierte Feature wieder entfernt wurde:
"Update: This feature, originally documented in the January 2026 non‑security update (KB5074105), has been removed from the documentation and is planned for a future release.
[Smart App Control]"
*ttps://support.microsoft.com/en-us/topic/january-29-2026-kb5074105-os-builds-26200-7705-and-26100-7705-preview-85bd25de-894a-43eb-a19b-9a59d10f194b#id0ebdj=gradual_rollout
Da hatte also der graduelle Rollout nicht zufriedenstellend funktioniert und der Rollout wurde gestoppt, vermutlich weil es Fehler gab.
Dann sind demnach also die Artikel bei Bleeping Computer und Co bezüglich des SAC-Features in den Updates Januar und Februar inzwischen als falsch anzusehen.
Das Feature hätte ausgerollt werden sollen, wurde es teilweise graduell auch, aber dann wurde es wieder zurückgezogen.
KB5077241 (Preview 24. Februar 2026 für März):
Weder im Changelog, noch im Reiter "Gradueller Rollout" noch im Reiter "Normaler Rollout" wird das SAC-Feature erwähnt.
KB5079473 (Patchday 10.März 2026):
Keine Erwähnung dieses SAC-Features.
KB5079391 (Preview 26.März 2026 für April)
Das SAC-Feature wird im Reiter "Gradfueller Rollout" erwähnt.
Es sollte also nur ein Teil der User dieses Feature erhalten.
KB5083769 (Patchday 14.April 2026):
Das SAC-Feature wird weder im Changelog noch bei "Improvementsd", noch in Reitern "Gradual Rollout" oder "Normaler Rollout" erwähnt.
Das Feature ist also weiterhin nicht allgemein verfügbar, sondern lediglich im Zustand "Gradual Rollout" seit dem KB5079391 (Preview 26.März 2026) für eine Teilmenge der User, die dieses Preview installiert hatten.
Das Feature ist also nicht ausgereift, nicht einsatzfähig und nichtmal allgemein verfügbar.
Dann bleibt es dabei, dass man dieses Feature bisher nicht folgenlos abschalten kann, denn dann kann man es bisher nicht ohne Neuinstallation von Windows bzw ohne "Zurücksetzen", was einer Neuinstallation gleichkommt, wieder aktivieren.
Das wäre also geklärt.
Und Neuinstallation dann nur mit digitaler ID und Altersnachweis?
"Wenn die "Smart App Control" einmal deaktiviert wurde, dann ist sie nie mehr aktivierbar."
Das stimmt nur halb, in der GUI kann man sie nicht mehr aktivieren. Das ist aber reine Marketing-Sprech. Wenn du Smart App Control anschließend per Regkey wieder aktivierst, geht sie wieder. Lässt sich beliebig oft wiederholen und reproduzieren.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CI\Policy
VerifiedAndReputablePolicyState = 1
Schaltet sie wieder ein.
Danach Reboot.
Ich halte deine Antwort leider für falsch.
Zitat Microsoft:
"If the system is enterprise‑managed and Smart App Control was modified via policy, the organization can centrally set VerifiedAndReputablePolicyState back to a supported value and then run CiTool.exe -r to refresh policies, but this is documented as an admin/testing scenario and once Smart App Control is turned off it cannot be turned back on without a reset or reinstall."
*ttps://learn.microsoft.com/en-us/answers/questions/5812685/windows-11-smart-app-control-blocked-everything-li
Alleine der Name dieses Registry-Schlüssels sagt schon einiges aus:
"VerifiedAndReputablePolicyState".
Wenn man die Sicherheitsfunktion einmal ausgeschaltet hatte, dann ist das System eben nicht mehr verifiziert und reputable sauber, sondern eventuell schon kompromittiert.
Daran ändert man auch nichts, wenn man einen Wert in die Registry einträgt, damit das System dann glauben soll, es sei sauber.
Das ist so wie bei einem Smartphone, das mal gerootet wurde. Es nützt dann nichts mehr, wenn man wieder unrootet, denn es wurde ein Zähler incrementiert und gewisse Apps mit erhöhtem Sicherheitsbedarf starten dann trotzdem nicht mehr.
Wenn man das SAC-Feature so einfach ein und ausschalten könnte, dann müsste Microsoft nicht so viele Monate lang testen, das Feature graduell ausrollen und wieder zurückziehen.
Stand jetzt geht es immer noch nicht und das bleibt auch so bis mir jemand eine Quelle von Microsoft zeigt, wo dieses Feature als offiziell freigegeben gilt.
Ich kann Gänseblümchen bestätigen. Hab das auch schon gemacht. Ich hatte eine uralte Anwendung aus den späten 1990ern, deren Setup sich nicht starten lies, weil Smartappcontrol den Hersteller der Software nicht ermitteln konnte. Also, aus geschaltet, Anwendung installiert, Smartappcontrol per Regkey wieder aktiviert, Setup nochmal gestartet, wurde wieder mit der gleichen Meldung verweigert.
Kann ich jederzeit reproduzieren.
Danke, hab ich dann gefunden und damit deaktiviert!
Download-Ordner (wo du das halt so liegen hast), Setupdatei suchen, rechte Maustaste, Eigenschaften, Allgemein, ganz unten "Sicherheit", "Die Datei Stammt von einem anderen Computer. …" -> [X] Zulassen -> Ok.
Viel Spaß.
Das ging schon bisher nicht immer. Ich musste letztes Jahr auf einem neuen Server ein Programm installieren, das von 200x und vor allem unsigniert war.
Letztlich war die Lösung, das Installationsprogramm mit einem Zertifikat der lokalen PKI zu zertifizieren..
Hat noch jemand unter Windows 11 das Phänomen, dass seit den Updates die Icons bei Verknüpfungen zu Ordnern auf Netzlaufwerken nicht mehr erscheinen bzw. nur noch ein "weißes Blatt" sind?
Konkretes Beispiel:
– Netzlaufwerk als Laufwerk X: gemountet
– Auf Laufwerk X: ist eine Verknüpfung zu X:\Ordner2 namens "Ordner2" hinterlegt
– Das Symbol der Verknüpfung "Ordner2" ist besagtes weißes Blatt
– Passiert sowohl bei bestehenden als auch neu angelegten Verknüpfungen
Lege ich die Verknüpfung zu X:\Ordner2 hingegen lokal an, z.B. auf dem Desktop, wird das Ordnericon ganz normal angezeigt.
Ich habe das gleiche Phänomen auf zwei getrennten Systemen, beide Windows 11 Pro 25H2, aktueller Patchstand (April 2026).
Iconcache unter %LOCALAPPDATA% habe ich bereits gelöscht und neu gestartet, ohne Effekt.
Tritt vor allem bei Sambafreigaben von Linux-NASen auf, bisher klappte es immer in der Systemsteuerung > Internetoptionen > Lokales Intranet > Sites > Erweitert und dann file://FQDN-oder-IP/ eintragen.
Ist bei uns seit einigen Updates im Windows 11 ähnlich der Fall und trotz früher funktionierender Einträge in
Systemsteuerung > Internetoptionen > Lokales Intranet > Sites >
werden dann auch wieder Datei öffnen – Sicherheitswarnung gestellt, wenn es Executables als Verknüpfung sind.
Witzige Sidenote:
Taskmanger – Windows-Explorer Task – >"Neu starten" dann erscheinen sowohl die Icons wieder als auch die Sicherheitpopups sind wieder wie gewünscht weg.
Hält aber oft nicht über den Neustart hinweg :( … MS halt
Danke für eure Antworten! Bis gestern, sprich vor den April-Updates, wurde das Icon ganz normal bei mir angezeigt. Ein Kollege, der heute die Updates bei sich auf dem System installiert hat, hat genau das gleiche Phänomen.
Ich gehe daher stark davon aus, dass es ein Bug beim April-Update für Windows 11 ist. Gut, kann man zugegebenermaßen mit leben ;-) Sieht halt nur nicht so schön aus. Den Eintrag in "Lokales Intranet" – "Sites" nehme ich mal vorerst nicht vor; will erst abwarten, ob das ggf. mit den Mai-Updates gefixt wird. Trotzdem aber danke für den Tipp.
Ja, der Windows Explorer hat schon immer seltsame Bugs.
Änderungsdatum vor 1980 wird mit Details auch nicht angezeigt.
Bei vorliegenden älteren Dateien geht das nur bis ca. 1983.
Mit dem Eigenschaften kann man jedoch das Änderungsdatum auch vor 1980 sehen.
Eben MS.
RDP Warndialog: Das ist ein absolut unbrauchbares "Feature" von Microsoft. Wasbisher geschah: Das Zertifikat des RDP-Servers (nicht die Signatur des RDP-Files) wird geprüft und der Fingerprint der vertrauenswürdigen RDS-Server-Zertifikate, Organisations-weit verteilt (GPO TrustedThumbprints). Verbindet man zu einem "falschen Server", erscheint eine Warnung (blaue Meldung), verbindet man zu einem Server ohne validierbares Zertifikat (keine passende RootCA, etc.pp.), erscheint eine gelbe Warnung, die bestätigt werden muss. Weiterhin sind die verteilten RDP-Files Oranisations-weit signiert mit dem Zertifikat der/des RDS-Hosts. Ich sehe hier also keinen Mehrwert und keinen Sinn.
Ich habe ebenfalls ausprobiert ob signierte RDP-Files (mit CodeSigning Zertifikat!) die Warnung nicht provozieren, tun sie aber trotzdem… Der entsprechende Prozess (CAPI2) gibt 0 zurück, die Kette wurde korrekt validiert. Trotzdem kommt der Dialog.
Weiterhin möchte ich anregen darüber nachzudenken was dieser Dialog denn jetzt schützen soll? Ich wähle ein einziges Mal(!) eine "böse" RDP-Datei an, setze das Häkchen, um fortan bis zum Ende aller Tage "böse" RDP-Dateien ohne Dialog öffnen zu dürfen. Hier drängt sich mir der Verdacht auf, dass a) entweder on-premises Installationen nicht mehr erwünscht sind (Azure RDS-Services sollen angeblich keine Dialoge bringen) oder b) ein KI-Quereinsteiger, ohne Grundwissen zu IT-Security-Konzepten, dies verbrochen hat. Am Ende des Tages schafft es nur Aufwand, das Anlegen einer entsprechenden GPO, welche den RdpLaunchConsentAccepted Registry-Key setzt. Dialog bestätigt, Fall geschlossen.
KB5083769 (Betriebssystembuild 26200.8246) bringt "Aufruf wurde durch Messagefilter abgebrochen"
Wie schon das März-Update, über DISM gehts aber anstrengend
Hallo, deine Rechner haben vermutlich keinen Internetzugriff?
Hallo,
hat es jemand geschafft, diese RDP-Warnung zu deaktivieren, und welchen Registrierungsschlüssel habt ihr dafür verwendet? Ich habe sie alle ausprobiert und den Computer neu gestartet, aber die Warnung bleibt bestehen.
Gestern Abend habe ich die April-Updates für Windows 11 – 25H2 installiert. Alles fehlerfrei durchgelaufen, inkl. der Reboots. Heute werden 80% meiner USB-Sticks nicht mehr angenommen, von Fehlermeldungen wie "… kann nicht installiert werden" bis zum Rechner der nach einstecken der Sticks minutenlang nicht mehr bedienbar ist, ist alles dabei. Nur die neuesten USB-Sticks laufen noch problemlos. Die älteren sind nur noch an meinem alten Windows 10 Rechner nutzbar – da aber völlig ok.
Mein W11-Rechner ist ein HP Gerät mit AMD Ryzen 7 5700 und SSD.
Hallo,
ich habe das Update für Windows 11 (KB5083769) durchgeführt und habe seitdem bei jedem Start folgendes neues Fehlerereignis in der Ereignisanzeige und zwar 3x hintereinander:
3502 OneCore-DeviceAssociationService
Muss ich handeln?
Danke vorab für die Hinweise
Volker
hier noch der "detaillierte" Fehlertext:
"Fehler beim Aufheben der Gerätetrennung (Entkoppelung)."
Ich habe ein ganz anderes Problem: seit letzten Monat werden nicht mehr alle Updates vom WSUS (Server 2019) geladen. Für die kumulativen (Monats-)Updates versucht der Rechner, eine Verbindung ins Internet (bzw. dem Proxy) aufzubauen und von dort zu laden. Was bei Rechnern ohne Internetzugang natürlich fehlschlägt (Downloadfehler – 0x80010002).
Wir haben schon Computer Configuration → Administrative Templates → Windows Components → Delivary Optimization → Download Mode auf "99 – Einfach" gestellt (100 sei für Win11 deprecated), es tritt aber weiter auf (mehrere Rechner)
Tritt das bei euch auch auf bzw. was ist die Lösung?
wie sieht deine Registry aus?
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]
"ExcludeWUDriversInQualityUpdate"=dword:00000001
"TargetReleaseVersion"=dword:00000001
"DisableWindowsUpdateAccess"=dword:00000001
"DoNotConnectToWindowsUpdateInternetLocations"=dword:00000001
"DisableDualScan"=dword:00000001
"AcceptTrustedPublisherCerts"=dword:00000001
"SetDisablePauseUXAccess"=dword:00000001
"WUServer"="https://wsus08.firma.local:8531"
"WUStatusServer"="https://wsus08.firma.local:8531"
"UpdateServiceUrlAlternate"="https://wsus08.firma.local:8531"
"SetAutoRestartNotificationConfig"=dword:00000001
"AutoRestartNotificationSchedule"=dword:0000000f
"SetPolicyDrivenUpdateSourceForFeatureUpdates"=dword:00000001
"SetPolicyDrivenUpdateSourceForQualityUpdates"=dword:00000001
"SetPolicyDrivenUpdateSourceForDriverUpdates"=dword:00000001
"SetPolicyDrivenUpdateSourceForOtherUpdates"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU]
"NoAutoUpdate"=dword:00000000
"AUOptions"=dword:00000004
"ScheduledInstallDay"=dword:00000001
"ScheduledInstallTime"=dword:00000003
"ScheduledInstallEveryWeek"=dword:00000001
"AllowMUUpdateService"=dword:00000001
"DetectionFrequencyEnabled"=dword:00000001
"DetectionFrequency"=dword:00000006
"UseWUServer"=dword:00000001
"AutoInstallMinorUpdates"=dword:00000000
"IncludeRecommendedUpdates"=dword:00000001
Hallo GP.Burth,
das kommt mir bekannt vor…
Wir haben das seit dem Patchday 03.2026.
Alle Clients, die keine Verbindung zum Inet haben, können die Updates nicht mehr vom WSUS laden.
Es betrifft aber (wie bei dir) nur die kumulativen Updates, alles Andere geht.
Ich habe letzten Monat schon was dazu geschrieben und damals alles mögliche probiert.
Sachen wie "DisableDualScan"=dword:00000001 ("Keine Richtlinie für Updaterückstellungen zulassen, durch die Windows Update überprüft wird") über GPO und einige (viele) andere Dinge und Tests.
Alles ohne dauerhaften Erfolg.
Seltsamerweise gingen letzten Monat nach der GPO "Keine Richtlinie für Updaterückstellungen zulassen, durch die Windows Update überprüft wird" die Updates, das war aber anscheinend nicht von Dauer.
Diesen Monat genau das Gleiche >> alle Clients ohne Connect zu MS laden das Update (KB5083769) nicht >> Downloadfehler – 0x80010002.
Alle Clients sind 25H2.
Ich habe für uns eine temporäre Lösung, die wird dir aber höchstwahrscheinlich nicht viel nützen…
Unser Firewall- Hersteller bietet die Möglichkeit, fertige, täglich aktualisierte IP- und Adresslisten bestimmter Dienste zu laden und diese in Regeln zu verwenden.
Ich habe nun für alle Clients die Adressen und IP's von MS Intune freigegen, nur mit den Apps MS Update und SSL.
Kein betroffener Client kann surfen, oder eine der Adressen z.B. mit dem Browser öffnen.
Hier die Seite dazu von MS (dient nur als Beispiel): https://learn.microsoft.com/de-de/intune/fundamentals/endpoints?tabs=north-america
Sofort nach Freigabe laden alle Clients die Updates normal (VOM WSUS) herunter und installieren diese.
In den FW Logs kann ich deutlich sehen, dass die Clients kurz Kontakt mit diversen MS Adressen haben, und danach das Update vom WSUS laden.
Ein Download der Updates von MS findet nicht stat.
Mir gefällt diese Lösung auch nicht, aber ansonsten bin ich auch erstmal ratlos…
Falls du aber diese Möglichkeiten so nicht hast, oder die Freigabe der Adressen nicht wünschst, hilft dir das auch nicht.
@alle: Für andere Lösungen wäre ich übrigens auch sehr dankbar.
Grüße naardes
Ich habe einen weiteren Workaround gefunden. Das Problem tritt anscheinend auf, weil der Client während der Zertifikatsprüfung die CRL aus dem Internet abrufen will. Durch verändern eines Registry Key von 0x00023c00 auf 0x00023e00 wird die CRL-Prüfung für den System Account deaktiviert. Anschließend funktioniert die Update Installation einwandfrei.
Windows Registry Editor Version 5.00
[HKEY_USERS\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing]
"State"=dword:00023e00
Da die CRL-Prüfung natürlich einen wichtigen Zweck erfüllt, kann das nur ein temporärer Workaround sein. Ich hoffe, Microsoft erkennt das Problem bald und fixt es in einem zukünftigen Update.
Seit 21.April 2026 gibt es einen Out-of-Band security-FIX gegen CVE-2026-40372 für NET Desktop 10.
Microsoft .NET Desktop Runtime 10.0.7
*ttps://dotnet.microsoft.com/en-us/download/dotnet/10.0
*ttps://devblogs.microsoft.com/dotnet/dotnet-10-0-7-oob-security-update/
10.0.7 fixt Entschlüsselungsfehler, die durch 10.06 verursacht wurden:
*ttps://github.com/dotnet/aspnetcore/issues/66335
Nach dem Update hatten wir unter Windows 25H2 bei sämtlichen Rechnern das Problem, dass Druckaufträge (in Kombination mit novell/opentext iPrint) nicht zuverlässig an den Drucker versandt werden. Problem war, dass die Gerätemetadaten durch das Update beschädigt waren. Lösen konnten wir das wie folgt:
net stop spooler
takeown /f "C:\ProgramData\Microsoft\Windows\DeviceMetadataStore" /r /d j
icacls "C:\ProgramData\Microsoft\Windows\DeviceMetadataStore" /grant Administratoren:F /t /q
Alle Dateien und Ordner aus folgenden Verzeichnissen löschen
C:\ProgramData\Microsoft\Windows\DeviceMetadataCache
C:\ProgramData\Microsoft\Windows\DeviceMetadataStore
net start spooler
PC neu starten