KB5132061 hängt, SQL Server leckt, Skripte fallen durch – Grams IT

Zwei Tage nach dem Patchday im November hat Microsoft zwei Probleme offiziell bestätigt. Das Sicherheitsupdate KB5132061 für Windows 11 lässt sich auf einem Teil der Geräte nicht installieren und bricht mit 0x80070306, 0x800f0989 oder 0x800f0993 ab. Und auf Servern sammeln SQL-Server-Linked-Server-Abfragen offene Verbindungen zu Oracle- und PostgreSQL-Datenbanken an, bis die Leistung in die Knie geht. Das zweite Problem ist das unangenehmere, und es stammt gar nicht vom November-Patchday, sondern schon aus dem Oktober.

Dazu kommt eine dritte Baustelle, die kein Fehler ist, sondern Absicht: Windows prüft seit dem November-Update die Kodierung signierter PowerShell-Skripte strenger. Skripte, die gestern noch als gültig signiert durchliefen, können heute als „NotSigned“ gelten.

Ich habe die Berichte von BleepingComputer, ComputerBase, Neowin und WinFuture gegen die Microsoft-Quellen gelegt: die Supportseiten der Updates und das Windows Release Health Dashboard. Hier steht, was Microsoft tatsächlich sagt, was nur Vermutung ist und was Sie jetzt tun sollten.

KB5132061 Installationsfehler: wer betroffen ist

KB5132061 ist das Sicherheitsupdate vom 10. November 2026 für Windows 11. Laut Microsofts Supportseite hebt es die Versionen 26H2, 25H2 und 24H2 auf die Builds 26300.9974, 26200.9974 und 26100.9974. Mitgeliefert wird das Servicing Stack Update KB5132688.

Am 11. November hat Microsoft auf derselben Seite einen Known Issue ergänzt: Auf manchen Geräten schließt die Installation nicht ab. Die Geräte versuchen es immer wieder oder zeigen einen der drei Fehlercodes. Den entscheidenden Satz zitiert BleepingComputer aus der Service-Meldung im Admin Center: „This issue affects a limited number of devices“. Gemeint sind Geräte, auf denen vorher das optionale, nicht sicherheitsrelevante Oktober-Preview KB5127936 installiert wurde. Wer das Preview nicht hatte, ist nach Microsofts Aussage nicht betroffen.

Ein Detail, das in den Berichten untergeht: KB5127936 vom 28. Oktober gab es laut Supportseite nur für Windows 11 26H2 und 25H2 (Builds 26300.9818 und 26200.9818). Ob 24H2-Geräte das Problem überhaupt haben können, sagt Microsoft nicht ausdrücklich. Nach der Logik der Meldung eher nicht, aber das ist meine Schlussfolgerung, keine Microsoft-Aussage.

Die automatische Reparatur über Windows Update

Microsoft verteilt kein neues Update. Die Reparatur läuft laut Supportseite automatisch auf betroffenen Geräten, die mit dem Internet verbunden sind und über Windows Update in den Einstellungen aktualisieren. Zeitrahmen: 24 bis 48 Stunden ab dem 11. November 2026, 10:00 Uhr pazifischer Zeit. Danach soll das Gerät KB5132061 von selbst herunterladen und installieren. Neowin betont, dass Nutzer dafür nichts manuell herunterladen müssen.

Umgerechnet heißt das (eigene Rechnung, PST ist UTC−8, MEZ UTC+1): Das Fenster begann am 11. November um 19:00 Uhr MEZ und endet spätestens am 13. November gegen 19:00 Uhr MEZ. Wer am Freitagabend noch hängt, soll sich laut Microsoft an den Support wenden.

Wie die Reparatur technisch funktioniert, verrät Microsoft nicht. Eine Ursache nennt das Unternehmen ebenfalls nicht.

Zeitleiste: Am 13.10. erscheint das Oktober-Update, das das SQL-Server-Problem auslöst; am 28.10. das Preview KB5127936; am 10.11. KB5132061; am 11.11. bestätigt Microsoft beide Probleme; das Reparaturfenster für KB5132061 endet am 13.11. gegen 19 Uhr MEZ, der SQL-Fix ist noch offen.

Die Zeitleiste zeigt, warum ich die beiden Themen getrennt behandle: Das Installationsproblem ist eine Sache von drei Tagen. Das SQL-Server-Problem läuft seit dem Oktober-Patchday und hat noch kein Ende.

Windows Sandbox als Ursache: unbestätigt

Windows Latest brachte am 11. November die Windows Sandbox ins Spiel. Ein Nutzer fand in seinen Installationsprotokollen einen Fehler zu einer Datei, die von der Sandbox verwendet wird, deaktivierte das Feature und konnte das Update danach installieren. Derselbe Bericht nennt aber auch Fälle ohne aktivierte Sandbox. ComputerBase übernimmt das ausdrücklich als Vermutung.

Was belegt ist: KB5127936 enthielt laut Microsoft einen Fix für die Sandbox, die sich unerwartet mit Fehler 0x80370106 schließen konnte. Das Preview hat also Sandbox-Komponenten angefasst. Ob das die Ursache ist, weiß niemand außerhalb von Microsoft. Ich würde die Sandbox nicht vorsorglich auf allen Clients abschalten, sondern das Reparaturfenster abwarten.

Noch ein Hinweis, weil der Link durch die Berichterstattung wandert: Der Thread in Microsoft Q&A zu 0x800f0993 enthält keine Microsoft-Antwort. Geantwortet haben ein „Independent Advisor“ und ein automatisch erzeugter KI-Block. Die Tipps dort (Update-Komponenten zurücksetzen, SoftwareDistribution und catroot2 löschen, Neuinstallation über die Wiederherstellung) sind Standardrezepte, keine offizielle Lösung für dieses Problem.

SQL Server Linked Server: offene Verbindungen nach Windows-Updates

Das zweite Problem steht im Release Health Dashboard für Windows Server 2025 seit dem 11. November, 15:11 Uhr PT, mit Status „Confirmed“. Microsoft schreibt, dass nach den Windows-Updates vom 13. Oktober 2026 und späteren auf Servern „connections created by SQL Server linked server queries might remain open“. Statt sich nach der Abfrage zu schließen, sammeln sich die Verbindungen zu externen Datenbanken an. Nach längerer Laufzeit wird der Server langsamer.

Betroffen sind Linked-Server-Abfragen, die über OLE-DB-Provider auf externe Datenbanken zugreifen. Oracle und PostgreSQL nennt Microsoft ausdrücklich als bekannt betroffen, die Formulierung lässt weitere Provider offen. Als auslösende Updates führt Microsoft unter anderem KB5126646 (Windows Server 2025, Build 26100.33650) und auf der Statusseite für Windows 11 25H2 KB5127648 (Build 26200.9711) auf, beide vom 13. Oktober.

Die Liste der betroffenen Plattformen ist lang:

Client: Windows 11 26H1, 25H2, 24H2 und 23H2, Windows 10 Version 1809 und Windows 10 Enterprise LTSC 2019
Server: Windows Server 2025, Windows Server 2022, Windows Server Version 1809, Windows Server 2016, Windows Server 2012 R2 und Windows Server 2012

Wer den November-Patch eingespielt hat, ist damit nicht aus dem Schneider. Das November-Update behebt den Fehler nicht, es ist in der Formulierung „and later“ eingeschlossen.

Workaround und angekündigtes Out-of-Band-Update

Microsoft bietet für Unternehmensgeräte eine Mitigation an, die es nur über den Microsoft Support for business gibt. Öffentlich dokumentiert ist sie nicht. Als Übergangslösung nennt Microsoft zwei Dinge: inaktive Verbindungen manuell schließen oder den SQL-Server-Dienst neu starten. Beides kann laufende Abfragen oder Transaktionen abbrechen, und das Problem kommt nach einiger Zeit wieder.

Der eigentliche Fix soll als Out-of-Band-Update „in the next few days“ kommen. Ein Datum gibt es nicht. BleepingComputer berichtet dasselbe und nennt keine weiteren Details.

Mich ärgert an diesem Fall weniger der Fehler selbst als die Zeitspanne. Zwischen dem auslösenden Update und der Bestätigung liegen fast vier Wochen. Wer in dieser Zeit einen langsam werdenden SQL Server mit Neustarts am Leben gehalten hat, hat vermutlich an seiner eigenen Konfiguration gezweifelt, nicht an Windows.

Signierte PowerShell-Skripte: strengere UTF-8-Prüfung

Das dritte Thema hat WinFuture am 12. November aufgegriffen. Es steht als gewollte Änderung in den Release Notes zu KB5132061 und ist in zwei Microsoft-Supportartikeln vom 10. November ausführlich beschrieben. Microsoft spricht in der Anleitung zur Kodierung signierter Skripte von „stricter encoding validation for PowerShell script signing and signature verification“.

Konkret: Bisher hat Windows ungültige Bytes in einer UTF-8-Datei bei der Signaturprüfung stillschweigend durch Ersatzzeichen ersetzt. Die Prüfung lief trotzdem durch. Jetzt lehnt Windows solche Dateien ab. Wie Windows die Kodierung erkennt, bleibt dagegen gleich. Ist ein BOM (Byte Order Mark) vorhanden, entscheidet dieses. Sonst wertet Windows die ersten 32 Bytes aus und nimmt im Zweifel die Systemcodepage.

Betroffen sind laut Microsoft Windows 11 von 23H2 bis 26H2, Windows 10 Enterprise LTSC 2021 sowie Windows Server 2016, 2019, 2022 und 2025. Die Symptome:

Get-AuthenticodeSignature meldet NotSigned, obwohl das Skript signiert war.
Set-AuthenticodeSignature scheitert mit UnknownError und der Meldung „No mapping for the Unicode character exists in the target multi-byte code page.“
Unter App Control for Business (WDAC) können betroffene Skripte im ConstrainedLanguage-Modus landen.

Microsoft weist selbst darauf hin, dass diese Symptome auch andere Ursachen haben können. Deshalb erst scannen, dann reparieren.

Das Reparaturskript von Microsoft

Für größere Skriptbestände stellt Microsoft das Beispielskript Repair-SignedPowerShellUtf8.ps1 bereit. Es braucht Windows PowerShell 5.1 in einer FullLanguage-Sitzung und kennt drei Modi:

Scan (Standard) verändert nichts und meldet je Datei den Problemtyp, etwa MalformedUtf8, Utf8WithoutBom oder NotValidInCodePage, dazu den Signaturstatus.
Repair erzeugt eine Kopie, die die bestehende Signatur behält. Microsoft nennt das ausdrücklich eine Übergangslösung, weil der Text dabei nicht korrigiert wird.
ConvertToUtf8Bom erzeugt eine Kopie als UTF-8 mit BOM und entfernt die alte Signatur. Das ist der empfohlene Weg, danach müssen Sie die Kopie prüfen und mit Ihrem Zertifikat neu signieren.

Die Quelldatei fasst das Skript nie an. Ergebnisse landen in neuen Dateien mit .repaired oder .utf8bom im Namen. Ein Scan über einen ganzen Ordner sieht so aus:

powershell

.\Repair-SignedPowerShellUtf8.ps1 -Path C:\Scripts -Recurse

Zwei Einschränkungen nennt Microsoft: Für die Fälle Utf8WithoutBom und NotValidInCodePage sollte Repair auf einem Rechner mit derselben Codepage laufen, auf dem das Skript signiert wurde. Bei der Konvertierung werden ungültige Bytes durch U+FFFD ersetzt, also muss jemand den Text vor dem Neusignieren lesen. Ist die Signatur nicht zu retten und fehlt das Zertifikat, bleibt nur die Bitte an den Herausgeber um eine korrigierte, signierte Fassung.

Meine Einschätzung, nicht Microsofts: Deutschsprachige Umgebungen dürften überdurchschnittlich oft betroffen sein. Ein Anmeldeskript mit „Laufwerksverknüpfung für Bürgerbüro“ im Kommentar, vor Jahren als ANSI oder als UTF-8 ohne BOM gespeichert, ist genau der Fall, den die neue Prüfung trifft. Umlaute in Kommentaren reichen dafür.

Was das für Kommunen und Fachverfahren bedeutet

Linked Server sind in der Verwaltung keine Exotik. Wo ein Fachverfahren auf SQL Server läuft und Daten aus einer Oracle- oder PostgreSQL-Datenbank eines anderen Verfahrens braucht, ist ein Linked Server oft die pragmatische Brücke, manchmal eingerichtet vom Hersteller und seit Jahren nicht mehr angesehen. Genau dort fällt das Problem spät auf: Ein nächtlicher Abgleich, der jede Nacht ein paar Verbindungen mehr offen lässt, macht sich erst nach Tagen bemerkbar.

Prüfen Sie deshalb zuerst, ob Sie überhaupt Linked Server mit OLE DB haben. Auf jeder SQL-Server-Instanz zeigt diese Abfrage, welche Linked Server mit welchem Provider eingerichtet sind:

sql

SELECT name, provider, data_source
FROM sys.servers
WHERE is_linked = 1;

Steht dort ein Oracle-Provider (etwa OraOLEDB.Oracle) oder ein Provider, über den Sie PostgreSQL ansprechen, lohnt der Blick auf die Gegenseite. Bei PostgreSQL zeigt pg_stat_activity die offenen Sitzungen, bei Oracle v$session. Wächst die Zahl der inaktiven Sitzungen vom SQL-Server-Host stetig, sind Sie betroffen. Dann ist der Anruf beim Microsoft-Support die sauberere Lösung als ein nächtlicher Dienst-Neustart per Aufgabenplanung, auch wenn Letzterer verlockend ist. Bei einem Fachverfahren eines Herstellers sollten Sie diesen zusätzlich informieren, bevor Sie an der Instanz Hand anlegen.

Beim Installationsproblem ist die Lage für verwaltete Umgebungen entspannter. Preview-Updates landen in den meisten Verwaltungen nicht auf den Arbeitsplätzen, und dann ist das Problem gar nicht da. Eine Einschränkung sollten Sie aber kennen: Microsoft beschreibt die automatische Reparatur für Geräte, die über Windows Update in den Einstellungen aktualisieren. Ob sie auch auf Clients ankommt, die ihre Updates über WSUS oder Configuration Manager beziehen, steht nicht in der Meldung. Wenn bei Ihnen einzelne Testgeräte mit dem Oktober-Preview in der Schleife hängen, kontrollieren Sie nach Freitagabend, ob KB5132061 dort durchgelaufen ist.

Die PowerShell-Änderung betrifft alle, die mit der Ausführungsrichtlinie AllSigned oder mit App Control arbeiten. Dazu gehören Anmeldeskripte per Gruppenrichtlinie, geplante Aufgaben auf Servern und Skripte, die ein Dienstleister signiert ausliefert. Ein Scan über die Skriptablagen (SYSVOL, das Skript-Repository, die Aufgabenordner) kostet wenige Minuten und zeigt, ob Handlungsbedarf besteht. Bei Skripten von Dienstleistern sollten Sie nicht selbst neu signieren, sondern eine korrigierte Fassung anfordern.

Eine gute Nachricht für Exchange

Damit der Rückblick nicht nur aus offenen Baustellen besteht: Ein weiteres Problem aus dem Oktober ist mit dem Patchday erledigt. Nach dem Oktober-Update KB5126646 konnten sich Nutzer bei manchen lokalen Exchange-Servern nicht an Outlook im Web anmelden, Mails blieben im Postausgang hängen. Ursache war laut Release Health ein neues Standardlimit von 512 gleichzeitigen Endpoint-Lookup-Aufrufen im Endpoint Mapper, das unter Last zu knapp war. Das November-Update KB5131080 für Windows Server 2025 behebt das. Wer den Registry-Workaround aus dem Exchange-Team-Blog gesetzt hat, braucht ihn nach dem Update laut Microsoft nicht mehr.

Fazit

Das Installationsproblem mit KB5132061 trifft nur Geräte mit dem Oktober-Preview und sollte sich bis Freitagabend von selbst erledigen. Ärgerlich, aber überschaubar. Wer Preview-Updates auf produktiven Geräten meidet, hat hier wieder einmal recht behalten.

Das SQL-Server-Problem ist ernster. Es betrifft praktisch jede unterstützte Windows-Server-Version seit dem Oktober-Patchday, der November-Patch löst es nicht, und der Fix hat noch kein Datum. Prüfen Sie heute, ob Ihre SQL-Server-Instanzen Linked Server mit OLE DB zu Oracle oder PostgreSQL nutzen. Wenn ja: Verbindungszahlen auf der Gegenseite beobachten, bei steigender Tendenz die Mitigation beim Microsoft-Support anfordern, und das Out-of-Band-Update einspielen, sobald es da ist.

Die strengere PowerShell-Prüfung halte ich für richtig. Eine Signaturprüfung, die kaputte Bytes wegretuschiert, ist keine. Trotzdem sollten Sie vor dem nächsten Montagmorgen Ihre signierten Skripte mit Repair-SignedPowerShellUtf8.ps1 scannen, statt es über fehlende Netzlaufwerke zu erfahren. Ich ergänze diesen Artikel, wenn Microsoft das SQL-Update veröffentlicht.

Quellen: