Die Woche im Betrieb
Dieser Rückblick umfasst den Zeitraum vom 11. Oktober, 18 Uhr, bis zum 18. Oktober 2026, 18 Uhr, Europe/Berlin. Vier Entwicklungen verdienen im lokalen IT-Betrieb Aufmerksamkeit: die Durchsetzung sicherer AD-FS-Berechtigungen, Sicherheitsupdates für SQL Server, neue PowerShell-Wartungsversionen und eine Exchange-Störung nach Windows-Updates. Entscheidend ist die Funktionsprüfung nach dem Eingriff. Ein erfolgreicher Installer reicht dafür nicht. Die folgenden Maßnahmen sind betriebliche Empfehlungen und von den Veröffentlichungsangaben der Hersteller zu unterscheiden. Anmeldung und Mailverkehr haben Vorrang; zugleich muss ein erprobter Weg zur Wiederherstellung verfügbar bleiben.
AD FS: Berechtigungen nach Beginn der Durchsetzung prüfen
Mit den Windows-Sicherheitsupdates vom 13. Oktober setzt Microsoft die Absicherung des DKM-Containers (Distributed Key Manager) von Active Directory Federation Services (AD FS) standardmäßig durch. Dieser Container enthält Schlüsselmaterial zum Schutz der Föderationszertifikate. Windows Server 2016, 2019, 2022 und 2025 korrigieren unsichere Berechtigungen nun automatisch, sofern Administratoren die automatische Korrektur nicht gezielt deaktivieren. Bei Server 2012 und 2012 R2 bleibt eine manuelle Korrektur nötig. Neu ist diese Durchsetzungsphase für CVE-2026-56155. Die Schwachstelle selbst wurde bereits im Juli dokumentiert.
Vor dem Update sollten alle Föderationsfarmen, ihre Dienstkonten und die Verantwortlichen der angebundenen Anwendungen erfasst werden. Bestehende Berechtigungen sichern und anschließend typische Anmeldungen testen. Microsoft erläutert im überarbeiteten KB5121391, dass bereits ein Farmmitglied das gemeinsame Verzeichnisobjekt ändern kann. Eine Ausnahme auf nur einem Server genügt deshalb nicht. Im Protokoll AD FS/Admin meldet Ereignis 1133 sichere Berechtigungen; 1136 und 1137 erfordern eine Untersuchung. Wer die automatische Korrektur aussetzt, sollte Grund, Verantwortlichen und einen Termin für das Ende der befristeten Sicherheitsausnahme festhalten.
SQL Server: den passenden Sicherheitsbuild auswählen
Für SQL Server erschienen am 13. Oktober neue Sicherheitspakete. In den hier betrachteten Zweigen mit kumulativen Updates bringt KB5126934 SQL Server 2022 CU27 GDR auf 16.0.4305.5. KB5126967 aktualisiert SQL Server 2025 CU9 GDR auf 17.0.5015.4. Beide Pakete betreffen Windows und Linux und schließen unter anderem Lücken zur entfernten Codeausführung. Sie sind von der Anfang Oktober behandelten Funktion für Linux-Massenimporte zu unterscheiden. Die genannten Builds gelten für diese Wartungszweige; sie sind keine pauschalen Zielstände für sämtliche SQL-Server-Installationen.
Vor der Paketauswahl werden Version, Wartungszweig, Betriebssystem und Rolle in einer Verfügbarkeitsgruppe je Instanz dokumentiert. Ich empfehle eine nachweislich wiederherstellbare Datenbanksicherung und zunächst das Update einer repräsentativen Testinstanz. Danach die tatsächlich genutzten Datenbankoperationen der Anwendung prüfen. Dazu gehören bei Bedarf geplante Jobs, Zugriffe über Verbindungsserver und Replikation. Bei Clusterdiensten müssen Reihenfolge und Abnahmekriterien für einen Failover vor dem Wartungsfenster feststehen. Anschließend zählen Build und Funktionstest jedes Knotens. Ein erfolgreich aktualisierter Primärknoten belegt weder den Zustand eines übersehenen Sekundärknotens noch den einer selten genutzten Berichtsinstanz.
PowerShell: die Laufzeit geplanter Aufträge testen
Das PowerShell-Projekt veröffentlichte am 13. Oktober die Versionen 7.6.7, 7.5.12 und 7.4.21. Alle drei Versionshinweise nennen einen toleranteren Umgang mit Ein-/Ausgabe- und JSON-Fehlern beim Lesen der benutzerspezifischen powershell.config.json sowie eine Prüfung von Sitzungseinschränkungen in Show-Command. Version 7.6.7 ändert außerdem die PATH-Behandlung bei MSIX-Installationen. Diese konkreten Wartungsänderungen sollten auf Automatisierungsrechnern getestet werden. Daraus folgt weder, dass beliebige Konfigurationsfehler unbedenklich sind, noch dass jedes Skript auf eine andere Versionslinie wechseln sollte.
Erfassen Sie die ausführbare Datei, die Aufgabenplanung, Verwaltungswerkzeuge und Dienstkonten tatsächlich starten. Die interaktive Shell eines Administrators kann neuer sein als die nachts verwendete Laufzeit. Innerhalb der gewählten Versionslinie aktualisieren und danach einen typischen Auftrag unter seinem tatsächlichen Konto mit der vorgesehenen Konfiguration und den benötigten Modulen ausführen. Exitstatus, strukturierte Ausgabe und ausgeführte Änderungen vergleichen. Bei MSIX gegebenenfalls auch die Auflösung des Programmpfads prüfen. Die vorherige erprobte Bereitstellung bleibt bis zur Abnahme verfügbar. Der Befehlsname pwsh allein beweist nicht, dass die gerade installierte Version gestartet wird.
Exchange: Mailstörungen nach Windows-Updates untersuchen
Microsoft eröffnete den Exchange-Störungsfall am 16. Oktober um 16:19 Uhr PT, also am 17. Oktober um 01:19 Uhr in Berlin. Auslöser sind die Windows-Updates vom 13. Oktober. Gemeldet werden fehlgeschlagene OWA-Anmeldungen, nicht zugestellte Nachrichten und wachsende Warteschlangen bei manchen Installationen von Exchange 2016, 2019 und Subscription Edition. Als Windows-Plattformen nennt Microsoft Server 2016, 2019, 2022 und 2025. Diese Aufzählung bestätigt nicht jede Kombination aus Exchange und Windows als unterstützt. Das Oktober-Sicherheitsupdate für Exchange muss für das Auftreten der Störung nicht installiert sein.
Bei betroffenen Mailsystemen sollten Installationszeitpunkt des Windows-Updates, Warteschlangenwachstum, Anwendungsereignisse und gemeldete Symptome zusammengeführt werden. Der vor Redaktionsschluss aktualisierte Störungseintrag verlinkt eine vorübergehende Registry-Abhilfe. Microsofts Anleitung für die beobachtete Konfiguration befolgen und die anschließende Überwachung einplanen. Danach Webanmeldung und Mailzustellung in beide Richtungen unter repräsentativer Last testen. Änderung und Verantwortlichen dokumentieren; die Maßnahme bei einer dauerhaften Lösung erneut bewerten. Die erst am 20. Oktober ergänzten FAQ liegen außerhalb des Recherchezeitraums und werden hier nicht als bereits am Sonntag verfügbares Wissen verwendet.
Fazit: den Dienst abnehmen, nicht nur den Installer
Für das nächste Wartungsfenster bleiben vier kurze Nachweise: Föderationsberechtigungen und Anmeldetests, SQL-Zielbuilds und Anwendungsprüfungen, die tatsächlich verwendete Automatisierungslaufzeit sowie der geprüfte Exchange-Mailverkehr. Jede Ausnahme und jeder fehlgeschlagene Test bekommt einen Verantwortlichen. Sicherungs- und Wiederherstellungsprüfung gehören in denselben Änderungsnachweis wie das Update. Die praktische Konsequenz dieser Woche ist konkret: Sicherheitsupdates können gemeinsame Verzeichnisberechtigungen, Datenbankverhalten und Mailverfügbarkeit verändern. Die Abnahme muss deshalb den jeweiligen Dienst über diese Grenzen hinweg prüfen.