Die Woche im Betrieb
Dieser Rückblick umfasst den Zeitraum vom 18. Oktober, 18 Uhr, bis zum 25. Oktober 2026, 18 Uhr, Europe/Berlin. Drei Entwicklungen betreffen den lokalen IT-Betrieb: korrigierte QNAP-Firmware, präzisierte Exchange-Hinweise und eine Wartungsversion von SQL Server Management Studio. Offen erreichbare Speichersysteme verdienen sofort Aufmerksamkeit. Mailverfügbarkeit und Datenbankdiagnose brauchen jeweils eigene Prüfungen. Die folgenden Maßnahmen sind betriebliche Empfehlungen. Sie trennen die datierte Herstellerankündigung von den Nachweisen, die ein Administrator vor dem Abschluss einer Änderung erheben sollte. Bereits behandelte Oktober-Updates greifen wir nur auf, wenn diese Woche wesentliche neue Hinweise hinzugekommen sind.
QNAP: nach dem Firmwareupdate bleiben Anwendungsprüfungen offen
QNAP hat QSA-26-18 am 22. Oktober veröffentlicht und im Stand vom 24. Oktober Firmwarekorrekturen dokumentiert. PHP2Shell, CVE-2026-109618 und CVE-2026-109619, kann entfernten Angreifern ohne Anmeldung die Ausführung von Code ermöglichen. Betroffen sind unter anderem QTS 5.2.11 und älter sowie QuTS hero h5.2.11 und älter. Die korrigierten Versionen dieser Zweige heißen QTS 5.2.11.3661 und QuTS hero h5.2.11.3661, jeweils Build 20261023. Für andere Firmwarezweige nennt die Tabelle eigene Zielversionen. Mehrere Anwendungen warten weiterhin auf Korrekturen; QuMagie steht in der Liste betroffener Produkte, fehlt aber in der Tabelle der korrigierten Versionen. Ein Firmwareupdate belegt daher nicht, dass jede installierte Anwendung abgesichert ist.
Zuerst sollten Modell, Firmwarezweig, installierte Anwendungen und erreichbare Verwaltungsoberflächen jedes Geräts erfasst werden. QNAP empfiehlt, die direkte Erreichbarkeit aus dem Internet zu unterbinden und Zugriffe auf vertrauenswürdige Netze zu beschränken. Bei Systemen mit produktiven Freigaben oder Sicherungsdaten würde ich vor dem Update abhängige Jobs, verfügbare Wiederherstellungskopien und einen Verantwortlichen für das Wartungsfenster festhalten. Die Firmware muss zum Modell passen; eine höhere Versionsnummer allein genügt nicht. Nach dem Neustart folgen die Prüfung des installierten Builds, ein Freigabezugriff mit einem normalen Benutzerkonto und eine repräsentative Sicherung mit anschließender isolierter Wiederherstellung. Noch verwundbare Anwendungen bleiben separat erfasst. Zum Abschluss der Firmwareänderung gehört ein dokumentiertes Testergebnis. Verbleibende Anwendungsrisiken brauchen eigene Zugriffsbeschränkungen und einen Nachverfolgungstermin.

Exchange: Abhilfe vor den Windows-Updates vorbereiten
Das Exchange Team hat seinen Störungsbeitrag vom 16. Oktober am 20. Oktober um häufige Fragen ergänzt. Darin liegt die Neuerung gegenüber der Vorwoche: Administratoren können den dokumentierten Registry-Eintrag vor den Oktober-Updates für Windows anlegen. Microsoft rät davon ab, diese Sicherheitsupdates aufzuschieben oder zu deinstallieren. Eine kurzfristige Folgeversion ist laut FAQ nicht vorgesehen. Der Störungsfall betrifft lokale Exchange-Installationen der Versionen 2016, 2019 und Subscription Edition. Windows Release Health nennt Server 2016, 2019, 2022 und 2025. Diese Aufzählungen bedeuten nicht, dass jede Kombination aus Exchange und Windows unterstützt wird. Der Registry-Eingriff bleibt eine Abhilfe; ein dauerhafter Fix wurde damit nicht veröffentlicht.
Vor dem nächsten Wartungsfenster sollte der Exchange-Verantwortliche Microsofts aktuelle Anleitung zu EpmapSavedContextCap prüfen. Der erforderliche Neustart und die anschließende Beobachtung gehören ausdrücklich in den Ablauf. Ich empfehle, ursprünglichen Registry-Wert, Windows-Build und Updatezeitpunkt festzuhalten, damit sich spätere Symptome der Änderung zuordnen lassen. Danach Webmail-Anmeldung, interne und externe Mailzustellung sowie Postfachoperationen testen. Das Wachstum der Warteschlangen mit dem Zustand vor der Änderung vergleichen. Eine unauffällige erste Anmeldung genügt als Abnahme nicht. Zuständigkeit für die Überwachung nach dem Wartungsfenster und die Eskalation an Microsoft Support bei erneuten Störungen vereinbaren. Die Abhilfe bleibt zur späteren Neubewertung im Änderungsnachweis. Die Klarstellung vom 20. Oktober schließt den Störungsfall nicht ab.
SSMS 22.11.1: Extended Events wieder auswerten
SQL Server Management Studio (SSMS) 22.11.1 ist am 20. Oktober erschienen. Die Version korrigiert ungültige XML-Dateinamen, die das Anzeigen erfasster Extended-Events-Daten verhinderten. Außerdem aktualisiert sie das mitgelieferte MSOLEDBSQL-MSI auf 19.4.3 und Visual Studio auf 18.11.1. Extended Events erfassen Diagnoseinformationen über Datenbankaktivitäten. Ein defektes Anzeigeprogramm kann die Fehlersuche behindern, obwohl der Datenbankdienst erreichbar ist. Hier wird das Verwaltungswerkzeug aktualisiert; ein neuer Patch für die SQL-Server-Datenbankengine ist darin nicht enthalten. Die Sicherheitsupdates für die Engine aus der Vorwoche bleiben eigene Wartungsaufgaben.
Erfasst werden sollten die SSMS-Installationen, die bei Störungen tatsächlich zum Einsatz kommen: auf Administratorarbeitsplätzen und administrativen Zugangsservern. Zunächst eine repräsentative Installation aktualisieren. Anschließend würde ich eine vorhandene Ereignisaufzeichnung öffnen und den üblichen Ablauf aus Aufzeichnung und Auswertung gegen eine freigegebene Testinstanz wiederholen. Vor der Verteilung auf weitere Arbeitsplätze folgen die Prüfung der Verbindungsanmeldung und der lokal benötigten Komponenten. Eine bekannte Diagnoseaufzeichnung beim Abnahmenachweis aufbewahren, damit ein anderer Administrator die Prüfung wiederholen kann. Die installierte SSMS-Version getrennt vom Build der SQL-Engine dokumentieren. So wird ein repariertes Diagnosewerkzeug nicht versehentlich zum Nachweis dafür, dass auch die Datenbankserver ihre erforderlichen Updates erhalten haben.

Fazit: jede Änderung braucht ihre eigene Abnahme
Für die kommende Woche stehen drei Verantwortliche und drei konkrete Ergebnisse an: ein geprüfter Firmwarestand der Speichersysteme mit Liste offener Anwendungen, ein getesteter Ablauf für Exchange-Update und Abhilfe sowie eine SSMS-Installation, die die eigenen Diagnosedaten öffnen kann. Fehlgeschlagene Prüfungen bleiben sichtbar; ein beendeter Installer schließt das Wartungsticket nicht ab. Wiederherstellungszugang und nachvollziehbare Nachweise gehören in jeden Datensatz. Die Änderungen betreffen verschiedene Ebenen. Ein erfolgreicher Neustart ersetzt deshalb weder den geprüften Speicherzugriff noch die Mailzustellung oder die funktionierende Datenbankdiagnose.