Zum 11. August 2026 hat Microsoft ja einen Schwung Sicherheitsupdates für diverse Microsoft Produkte (Office, Windows etc.) veröffentlicht. Die ganz großen Katastrophen scheinen nach dem Einspielen der Sicherheitsupdates ausgeblieben zu sein. Hier im Blog liegen mir aber Lesermeldungen zu Problemen (Outlook, Windows etc.) vor, die ich kurz in einer Nachlese zusammen fasse.
Outlook Classic: Bilder aus Signatur verloren
Microsoft hat für Office und dessen Anwendungen zahlreiche Sicherheitsfixes bereitgestellt (siehe Patchday: Microsoft Office Updates (11. August 2026) hier im Blog). Dabei scheint auch etwas an der Darstellung von Bildern in Signaturen von Outlook Classic kaputt gegangen zu sein. Blog-Leser Stefan schreibt in diesem Kommentar:
Bei uns sind nach dem Update bei vielen Usern die Bilder in der Signatur weg. Stattdessen wird nur noch "rotes x" angezeigt. Selbst wenn man diese manuell wieder einfügt ist es nach dem speichern wieder futsch. Outlook Classic.
Es betrifft beim Leser die Microsoft 365-Build 20228.20188, ein weiterer Leser nennt Microsoft Office 2021 LTSC mit Outlook 2021 LTSC ebenfalls als betroffen. Ein anderer Leser nennt Microsoft Office 2016, 2019, 2021 und 2024 als betroffen. Im Kommentarbereich des Beitrags Patchday: Microsoft Office Updates (11. August 2026) finden sich einige weitere Bestätigungen, dass diverse Office-Builds betroffen seien. Ein Leser vermutet, dass die Integration der neuen Möglichkeit, Bilder aus OneDrive einzufügen, diesen Bug provoziert hat.
Probleme mit .NET-Update KB5122104
Blog-Leser Micha hat mich zum 14. August 2026 per E-Mail kontaktiert (danke) und berichtet von schwerwiegenden Problemen mit dem .NET-Update KB5122104. Das August 2026 .NET 8.0.30 Security Update for x64 Client (KB5122104) adressiert Schwachstellen in der Microsoft .NET Runtime.
Der Leser schreibt, dass ihm seit dem Windows-Update vom 11.08.2026 (Windows 11 Pro, vollständig aktualisiert) u. a. das .NET 8.0.30 Security Update for x64 Client (KB5122104) angeboten werde. Die Installation läuft seit dem Abend des 11.08. in einer Endlosschleife:
Der Download gelingt, doch die Phase „Wird installiert" dauert viele Stunden und schlägt letztlich fehl. Nach jedem Neustart beginnt der Vorgang von vorne.
Auch am dritten Tag nach dem August 2026-Patchday hängt die Installation beim Leser bei ca. 30%, bis sie dann voraussichtlich am Abend oder in der Nacht wieder als "Fehlgeschlagen" quittiert wird. Der Leser schreibt: "Bisher habe ich online keine Berichte über ähnliche Probleme bei diesem Update gefunden.", könnte also ein Einzelfall sein.
Windows Server: Securepoint-Firewall nicht mehr erreichbar
In diesem Kommentar meldet ein Nutzer, dass die in seiner Umgebung vorhandene Securepoint-Firewall nach der Installation der Sicherheitsupdates auf Windows Server nicht mehr erreichbar seien. Deinstallation der Updates behebt derzeit das Problem. Es deutet sich ein Konfigurationsproblem an, denn der Leser schrieb in Folgekommentaren "Problem war, das der eine DC überhaupt keine DNS Anfragen mehr für irgendein Gerät gescheit beantwortet hat. In der Securepoint war nur dieser eine DNS Server für die AD Anbindung hinterlegt."
Probleme mit VMware Tools
In diesem Kommentar berichtet Marcel von bösen Problemen bei der Virtualisierung in Verbindung mit den VMware Tools. Sobald die VMware-Tools automatisch beim Reboot aktualisiert werden, gibt es in Verbindung mit dem August 2026 Patchday große Probleme.
Der Leser hat vier Systeme mit Windows Server 2019 mit entsprechenden Sicherheitsupdates August 2026 gepatcht und danach gebootet. Dann wollte der Windows Server 2019 die VMware-Tools aktualisieren und scheiterte. Es hieß, dass keine "VMtools vorhanden seien".
Die manuelle Installation der VMware-Tools von Version 13322 auf 13344 scheitert mit einem Fehler. Die Lösung des Problems besteht darin, den Ordner mit den VMware-Tools mit folgenden Befehlen:
ren "C:\Program Files\VMware\VMware Tools" "VMware Tools.old" ren "C:\ProgramData\VMware" "VMware.old"
umzubenennen, dann neu zu booten, und die Installation erneut manuell zu versuchen.
Windows friert nach 5 Minuten ein
Dann gibt es noch ein spezifisches TPM-Problem in Verbindung mit dem Update der Secure Boot-Zertifikate, welches wohl Besitzer von Systemen (z.b. eines Medion All-in-One PC, AIO-PC) betrifft. Blog-Leser Nakaschito beschrieb seinen Fehler unter Windows 11 so:
Seit ca. 2 Wochen mache ich rum weil mein Win 11 nach ca 5 Minuten einfriert. Alles probiert, nichts ging. Nirgends habe ich gefunden welcher Dienst nach ca. 5 Minuten startet. Also Rechner zurück gesetzt. Alles lief wieder normal. Bis heute.
Das Sicherheitsupdate KB5121003 hatte sich installiert und meldete einen Neustart. Habe ich gemacht. Mit dem Erfolg das der Rechner wieder aufgehängt hat. Also das Paket wieder deinstalliert. Bis jetzt läufts.
Es gibt also ein tieferliegendes Problem, auf das Leser Marco hier geantwortet hat. Er kennt das Problem von einem älteren Medion All-in-One PC. Auf einem Medion H81H3-TI mit AMI-Firmware H81TIW08.300 kommt es unter Windows 10 22H2 Build 19045.7548 zu obigem Fehlerbild.
Erklärung ist, dass der Secure-Boot-Servicing-COM-Handlers TpmTasks.dll beim Aufruf von SBServicing einen vollständigen Platform Hard Lock verursacht, sofern der automatische High-Confidence-Secure-Boot-Deployment-Pfad aktiv ist. Dann triggert ein Task dieses Einfrieren.
Mit HighConfidenceOptOut=1 läuft derselbe Task bei weiterhin aktiviertem Secure Boot fehlerfrei. Der normale UEFI-Secure-Boot-Variablenzugriffe funktionieren ebenfalls. Der Fehler liegt nach Vermutung des Leser damit sehr wahrscheinlich in einem spezifischen Firmware-/Servicing-Interaktionspfad des automatischen Secure-Boot-2023-Deployments. Bei diesem Blog-Leser lag die Ursache im Windows-Task:
\Microsoft\Windows\PI\Secure-Boot-Update
Dieser Task startet 5 Minuten nach dem Boot (PT5M) und ruft über einen COM-Handler:
C:\Windows\System32\TpmTasks.dll Data: SBServicing
auf. Dann friert das ganze System ein. Der Workaround des Leser besteht daher darin, Secure Boot aktiviert zu lassen, aber das automatische High-Confidence-Deployment zu deaktivieren. Dies hat er mit folgender Windows PowerShell-Anweisung gemacht:
New-ItemProperty `
-Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot' `
-Name 'HighConfidenceOptOut' `
-PropertyType DWord `
-Value 1 `
-Force
Vielleicht hilft es jemandem, der betroffen ist, weiter. Im Beitrag Patchday: Windows 10/11 Updates (11. August 2026) gibt es noch einige Nutzerkommentare, die Fehler (Tastatur reagiert nicht, SSO kaputt, Bug im Systray mit Ursachenbenennung) reklamieren. Sind aber wohl auch Einzelfälle.
Ähnliche Artikel:
Microsoft Security Update Summary (11. August 2026)
Patchday: Windows 10/11 Updates (11. August 2026)
Patchday: Windows Server-Updates (11. August 2026)
Patchday: Microsoft Office Updates (11. August 2026)
MVP: 2013 – 2016
Das Secure Boot Thema hatte ich am ca. 10 Jahre alten Medion Laptop meines Ex-Schwiegervaters schon nach dem Juni CU für Windows 11 24H2.
Das Gerät, das natürlich nicht offiziell Windows 11 kompatibel ist (alles erfüllt inkl. TPM 2.0, nur CPU ist Core i5-6xxx), hatte ich letztes Jahr mit den üblichen Kniffen von Windows 10 auf Windows 11 geupdatet, dabei noch das letzte verfügbare BIOS von 2017 installiert und seitdem lief es problemlos.
Bis es nach der Installation des Juni CU immer eingefroren ist – durch Testen dann bemerkt, dass es immer nach 5 Min und x Sekunden war. Mit etwas Suchen dann auch auf den Windows Task Secure-Boot-Update unter \Microsoft\Windows\PI\ gekommen, der immer 5 Minuten nach dem Booten versucht, die neuen Secure Boot Zertifikate zu installieren, was in Kombination mit dem alten BIOS reproduzierbar an die Wand scheppert.
Als Workaround erstmal den Task deaktiviert und nachdem das stabil lief, Secure Boot im UEFI-BIOS deaktiviert, bevor durch das nächste Update der Task wieder aktiviert wird und das Drama von vorne losgeht.