Patchday November 2026: Outlook zuerst, dann die Server in vier Wellen

/01Was der November-Patchday bringt — und was dieser Beitrag nicht ist

Der November-Patchday 2026 schließt eine Lücke, die bereits angegriffen wird, und sie steckt in Outlook. Auf den Servern gibt es keine gemeldete Ausnutzung, aber zwei Einträge mit CVSS 9,8, die Domain Controller und Exchange-Server treffen. Daraus ergibt sich die Reihenfolge: erst Office auf allen Arbeitsplätzen, dann ein kleiner Testring, dann die Server nach Rolle.

Zu den Zahlen. Die Release Notes des Microsoft Security Response Center (MSRC) nennen für den 10.11.2026 genau 1.094 Microsoft-CVE. Die Verteilung nach Produktfamilie: 726 Einträge für Windows, 174 für Office, 59 für SQL Server, 27 für SharePoint, 9 für Exchange Server. Dazu veröffentlicht Microsoft 165 Einträge anderer Hersteller erneut, überwiegend Chromium-Lücken für Edge. BleepingComputer zählt 1.235 und erklärt die Zählweise: nur am Patchday selbst veröffentlichte Einträge, Edge eingeschlossen. Beide Quellen sind sich in dem Punkt einig, auf den es ankommt — eine ausgenutzte Lücke, CVE-2026-124194.

In den CVRF-Daten des MSRC tragen 63 der am 10.11. veröffentlichten Microsoft-Einträge die Einstufung „kritisch“, 42 die Bewertung „Ausnutzung wahrscheinlicher“ (eigene Auszählung der Rohdaten, Stand 11.11.2026). Das klingt nach viel Arbeit, ist es für die Reihenfolge aber nicht: Alle Windows-Lücken einer Version schließt ein einziges kumulatives Update. Priorisiert wird deshalb nicht nach CVE, sondern nach Maschine — welcher Server zuerst, welcher später.

Was dieser Beitrag nicht ist: eine Wiederholung des Oktober. Wie Domain Controller gestaffelt gepatcht werden, mit Systemstatus-Sicherung, repadmin und dem PDC-Emulator am Schluss, steht im Beitrag Patchday Oktober 2026: Domain Controller richtig patchen. Dieses Vorgehen gilt im November unverändert. Hier geht es um den ganzen Betrieb: Arbeitsplätze, Terminalserver, Exchange, Dateiserver — und um die Frage, was davon zuerst drankommt.

/02Die eine ausgenutzte Lücke: Outlook gibt den NTLM-Hash preis

CVE-2026-124194 ist als „Microsoft Outlook Spoofing Vulnerability“ geführt, Einstufung „mittel“, CVSS 6,5. Wer nur nach Schweregrad sortiert, findet sie auf Seite zwanzig. Microsoft markiert sie trotzdem als einzigen Eintrag des Monats mit „Exploitation Detected“ — und das schlägt jede Einstufung.

Der Ablauf laut Microsoft: Ein Angreifer schickt eine präparierte Nachrichtendatei und bringt den Empfänger dazu, sie in Outlook zu öffnen. Outlook verbindet sich dann mit einem Netzwerkziel des Angreifers, ohne die übliche Warnung vor externen Inhalten zu zeigen. Dabei wird der NTLMv2-Hash des Benutzers offengelegt, mit dem sich der Angreifer als dieser Benutzer anmelden kann. Das Vorschaufenster ist ausdrücklich kein Angriffsweg; es braucht das Öffnen der Datei.

Für einen Betrieb mit 60 Postfächern heißt das: Es genügt eine Person, die einen Anhang aus einer plausiblen Phishing-Mail öffnet. Der abgegriffene Hash ist kein Klartextpasswort, aber er taugt für Relay-Angriffe gegen Dienste, die NTLM ohne Signierung annehmen, und er lässt sich offline angreifen, wenn das Passwort schwach ist. Von dort ist es der übliche Weg ins Netz — Lateral Movement über Freigaben und Dienste, bei denen dieser Benutzer Rechte hat.

Betroffen sind laut MSRC Microsoft 365 Apps for Enterprise sowie Office LTSC 2021 und 2024, jeweils in 32 und 64 Bit. Die korrigierten Stände nach der Microsoft-Liste der Office-Sicherheitsupdates vom 10.11.2026:

• Current Channel: Version 2610, Build 20527.20196
• Monthly Enterprise Channel: Version 2610 (Build 20527.20194), 2609 (20430.20264) oder 2608 (20326.20320)
• Semi-Annual Enterprise Channel: Version 2610 (Build 20527.20192), 2609 (20430.20262) oder 2608 (20326.20318)
• Office LTSC 2024: Version 2408, Build 17932.21140
• Office LTSC 2021: Version 2108, Build 14334.21048

In der Praxis: Diese Office-Pakete aktualisieren sich über Klick-und-Los und hängen nicht am Windows-Update. Ein Wartungsfenster für die Server brauchen Sie dafür nicht, nur geschlossene Office-Anwendungen. Der Stand steht in Outlook unter Datei, Office-Konto. Vergessen wird regelmäßig der Terminalserver: Dort läuft Office mit Shared Computer Activation für alle Sitzungen, und ein einziges veraltetes Paket betrifft dann dreißig Benutzer statt einen.

Eine Umgehung nennt Microsoft für diese Lücke nicht. Unabhängig davon gehört ausgehendes SMB vom Arbeitsplatznetz ins Internet an der Firewall gesperrt; das ist Grundhärtung gegen Hash-Abfluss jeder Art. Ob es genau diesen Angriffsweg schließt, sagt Microsoft nicht — die Sperre ersetzt das Update also nicht.

/03Was auf den Servern zählt: LDAP, Windows Search, AD DS und Exchange

Auf den Servern meldet Microsoft im November keine Ausnutzung. Vier Gruppen von Einträgen bestimmen trotzdem, welche Maschinen vorn stehen. Die Angaben stammen aus den CVRF-Daten des MSRC.

LDAP und AD DS: der Domain Controller

CVE-2026-119958 erlaubt laut Microsoft Codeausführung im Kontext des LDAP-Dienstes über eine präparierte Folge von LDAP-Aufrufen, ohne Anmeldung. In einem Netz mit Active Directory ist der LDAP-Dienst der Domain Controller. Dazu kommen zwei AD-DS-Einträge, die eine Anmeldung voraussetzen, bei denen Microsoft die Ausnutzung aber für wahrscheinlicher hält. Ein angemeldeter Benutzer ist nach einem erfolgreichen Outlook-Angriff genau das, was ein Angreifer hat. Die beiden Themen dieses Monats hängen also zusammen.

Windows Search: der Exchange-Server

CVE-2026-116928 ist der Eintrag, der am leichtesten falsch einsortiert wird. Er heißt „Windows Search“ und klingt nach Arbeitsplatz. Microsoft beschreibt den Angriff aber so: Eine E-Mail mit präpariertem Anhang geht an einen Exchange-Server, Exchange verarbeitet den Anhang automatisch für die Indizierung, und der Empfänger muss weder Mail noch Anhang öffnen. Behoben wird das mit dem Windows-Update des Servers, auf dem Exchange läuft, nicht mit dem Exchange-Update.

Der Exchange-Server braucht im November deshalb zwei Pakete: das kumulative Windows-Update und das Sicherheitsupdate KB5133453 für Exchange Server SE, das neun Exchange-CVEs schließt. Die MSRC-Daten führen für CVE-2026-118207 ausschließlich Exchange Server Subscription Edition als betroffenes Produkt. Für Exchange 2016 und 2019 gibt es kein November-Paket; was das bedeutet, steht im Beitrag zum ESU-Ende von Exchange 2016 und 2019.

Schannel und IIS: alles, was von außen erreichbar ist

Schannel ist die TLS-Schicht von Windows. CVE-2026-119952 und der IIS-Eintrag CVE-2026-119961 brauchen keine Anmeldung, haben aber laut Microsoft eine hohe Angriffskomplexität: besondere Protokolleinstellungen im einen Fall, eine gewonnene Race Condition im anderen. Für die Reihenfolge heißt das: Windows-Server, die aus dem Internet erreichbar sind — RD-Gateway, Webserver, veröffentlichte Fachanwendungen —, gehören in dieselbe Welle wie die Domain Controller.

/04Priorisierungstabelle: vier Wellen für 20 bis 150 Arbeitsplätze

Die folgende Tabelle ist unsere Empfehlung für einen Betrieb dieser Größe: zwei bis vier Domain Controller oder auch nur einer, ein Exchange- oder Mailserver, ein bis drei Terminalserver, Datei- und Druckserver, ein Virtualisierungshost. Die Fristen sind Erfahrungswerte aus dem Betrieb, keine Herstellervorgabe.

Welle 1 und Welle 2 laufen parallel, nicht nacheinander. Das Office-Update braucht keinen Test, der es aufhält; der Testring für Windows braucht drei Tage, damit ein Fehler überhaupt Gelegenheit hat aufzufallen. Der Scanner, der einmal pro Woche benutzt wird, meldet sich nicht nach zwei Stunden.

Die Zusammensetzung des Testrings ist wichtiger als seine Größe. Fünf Geräte in der IT-Abteilung testen nichts, was die Buchhaltung benutzt. Nehmen Sie je ein Gerät aus den Abteilungen mit eigener Fachanwendung, dazu den Arbeitsplatz, der am häufigsten scannt und druckt.

Bei nur einem Domain Controller entfällt die Staffelung in Welle 2 und 3. Dann testen die Arbeitsplätze und der Terminalserver zuerst, und der DC folgt in einem abendlichen Fenster mit vorheriger Systemstatus-Sicherung. Für den Hyper-V-Host gilt: erst die VMs, dann der Host — und bei einem einzelnen Host ohne Ausweichmöglichkeit ist das ein Fenster mit Komplettausfall, das angekündigt gehört.

/05Vorher testen: NTLM-Signierung und signierte PowerShell-Skripte

Die kumulativen Updates vom November bringen zwei Änderungen mit, die nichts mit einer CVE zu tun haben und trotzdem Verhalten ändern. Beide stehen in den KB-Artikeln für Server 2016, 2019, 2022 und 2025 sowie für Windows 11.

NTLM: Clients bieten Signierung standardmäßig an

Microsoft schreibt: Das Update verbessert die NTLM-Sicherheit, indem Clients die NTLM-Nachrichtensignierung für nicht anonyme Verbindungen standardmäßig anbieten. Das soll Relay-Angriffe erschweren und liefert eine Überwachung, die Verbindungen ohne Signierung sichtbar macht. Die Formulierung ist „anbieten“, nicht „erzwingen“.

Ehrlich: Ob dadurch in Ihrem Netz etwas bricht, sagt der KB-Artikel nicht, und wir haben dafür keinen Beleg. Die Kandidaten sind die üblichen — Geräte mit alter oder eigenwilliger NTLM-Umsetzung. Im Testring gehören deshalb geprüft: Scan-to-Folder am Multifunktionsgerät, Zugriff auf ältere NAS-Systeme, Fachanwendungen mit eigener Windows-Anmeldung, Zeiterfassungs- und Maschinenterminals. Zehn Minuten mit einer Liste, einmal je Gerät. Wer mit Kerberos statt NTLM arbeitet, ist von der Änderung nicht berührt.

PowerShell: strengere Prüfung signierter Skripte

Die zweite Änderung ist konkreter. Das Update verschärft die Signaturprüfung von PowerShell-Skripten um eine strengere Kodierungsprüfung. Skripte mit ungültiger UTF-8-Kodierung können an der Signaturprüfung scheitern, auch wenn sie bisher akzeptiert wurden. Microsofts Abhilfe: betroffene Skripte prüfen, als gültiges UTF-8 mit Byte Order Mark (BOM) speichern und neu signieren.

Das betrifft nur Umgebungen, die Skripte signieren — also dort, wo die Ausführungsrichtlinie Signaturen verlangt, oder wo ein Softwarehersteller signierte Skripte mitliefert. In deutschen Umgebungen gibt es eine typische Quelle für ungültiges UTF-8: Skripte, die vor Jahren in einem Editor mit ANSI-Kodierung gespeichert wurden und Umlaute in Kommentaren oder Meldungstexten tragen. Ein „ü“ in Windows-1252 ist ein einzelnes Byte, das in UTF-8 nicht für sich stehen darf.

Das folgende Skript durchsucht Verzeichnisse nach signierten Skripten und nennt deren Kodierung. Es liest nur, es ändert nichts.

# Signierte PowerShell-Skripte nach Kodierung auflisten (nur lesend)
$Pfad   = 'C:\Scripts', '\\firma.local\NETLOGON'      # anpassen
$strikt = [System.Text.UTF8Encoding]::new($false, $true)   # wirft bei ungültigen Bytefolgen

Get-ChildItem -Path $Pfad -Recurse -File -Include *.ps1, *.psm1, *.psd1 | ForEach-Object {
  $b   = [System.IO.File]::ReadAllBytes($_.FullName)
  $roh = [System.Text.Encoding]::GetEncoding(28591).GetString($b) -replace "`0", ''
  if ($roh -notmatch '# SIG # Begin signature block') { return }   # nur signierte Skripte
  $art = if ($b.Length -ge 3 -and $b[0] -eq 0xEF -and $b[1] -eq 0xBB -and $b[2] -eq 0xBF) { 'UTF-8 mit BOM' }
         elseif ($b.Length -ge 2 -and (($b[0] -eq 0xFF -and $b[1] -eq 0xFE) -or ($b[0] -eq 0xFE -and $b[1] -eq 0xFF))) { 'UTF-16' }
         else { try { [void]$strikt.GetString($b); 'UTF-8 ohne BOM' } catch { 'kein gültiges UTF-8' } }
  [pscustomobject]@{ Kodierung = $art; Datei = $_.FullName }
} | Sort-Object Kodierung, Datei | Format-Table -AutoSize

Getestet haben wir das Skript in PowerShell 7.4.2 mit sechs Probedateien: Eine signierte Datei mit ANSI-Umlauten meldet es als „kein gültiges UTF-8“, eine unsignierte Datei mit demselben Inhalt lässt es aus, die übrigen ordnet es richtig zu. Nicht getestet ist, ob Windows nach dem Update genau diese Dateien ablehnt; das Skript findet Kandidaten nach dem Wortlaut des KB-Artikels. Die Zeilen „kein gültiges UTF-8“ sind die, die Sie vor dem Rollout neu speichern und neu signieren. „UTF-8 ohne BOM“ ist gültig, entspricht aber nicht Microsofts Empfehlung.

/06Patchstand prüfen: Soll-Builds und ein Skript

Ob ein Windows-System den November-Stand hat, sagt die Build-Nummer: Hauptbuild und Revisionsnummer (UBR) aus der Registry. Die Soll-Werte aus den KB-Artikeln von Microsoft:

Der Hotpatch für Server 2025 gilt laut Microsoft für die Azure Edition und für Datacenter- und Standard-Server, die über Azure Arc angebunden sind. Wer das nicht eingerichtet hat, bekommt das reguläre Update mit Neustart. Für Windows 11 23H2 in den Editionen Enterprise und Education war der 10.11.2026 zugleich der letzte Tag mit Support; die Folgen beschreibt der Beitrag zum Support-Ende von Windows 11 23H2 Enterprise.

Das folgende Skript fragt Build und ausstehenden Neustart per PowerShell-Remoting ab und vergleicht mit der Tabelle. Server 2025 und Windows 11 24H2 tragen denselben Hauptbuild 26100; das Skript unterscheidet sie über den Installationstyp.

# Mindest-Builds nach dem Patchday vom 10.11.2026 (Quelle: KB-Artikel von Microsoft)
$Soll = @{
  'Server|14393' = 9688    # Windows Server 2016, KB5131291
  'Server|17763' = 9487    # Windows Server 2019, KB5131085
  'Server|20348' = 5870    # Windows Server 2022, KB5131090
  'Server|26100' = 33730   # Windows Server 2025: Hotpatch KB5131077; regulär KB5131080 = 33822
  'Client|19045' = 7846    # Windows 10 22H2 mit ESU, KB5131096
  'Client|22631' = 7711    # Windows 11 23H2, KB5131087
  'Client|26100' = 9911    # Windows 11 24H2: Hotpatch KB5132043; regulär KB5132061 = 9974
  'Client|26200' = 9911    # Windows 11 25H2, wie 24H2
  'Client|26300' = 9911    # Windows 11 26H2, wie 24H2
}
function Test-Patchstand {
  param([string]$Typ, [int]$Build, [int]$Ubr)
  $art = if ($Typ -like 'Server*') { 'Server' } else { 'Client' }
  $min = $Soll["$art|$Build"]
  if ($null -eq $min) { return 'unbekannt - von Hand prüfen' }
  if ($Ubr -ge $min) { 'November-Stand' } else { "offen (Soll $Build.$min)" }
}

$Rechner = 'DC01', 'DC02', 'EX01', 'FS01', 'TS01'          # anpassen
Invoke-Command -ComputerName $Rechner -ScriptBlock {
  $v = Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion'
  [pscustomobject]@{
    Typ = $v.InstallationType; Build = [int]$v.CurrentBuild; Ubr = [int]$v.UBR
    Neustart = Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired'
  }
} | ForEach-Object {
  [pscustomobject]@{
    Rechner = $_.PSComputerName; Build = "$($_.Build).$($_.Ubr)"
    Stand = Test-Patchstand $_.Typ $_.Build $_.Ubr; NeustartOffen = $_.Neustart
  }
} | Sort-Object Stand, Rechner | Format-Table -AutoSize

Zum Teststand, damit Sie wissen, worauf Sie sich verlassen: Die Vergleichslogik haben wir in PowerShell 7.4.2 mit sieben simulierten Rechnern geprüft — Server 2022 auf November-Stand, Server 2022 auf Oktober-Stand, Server Core, Server 2025 mit Hotpatch, Windows 11 mit altem und neuem Build, ein unbekannter Build. Alle sieben wurden richtig eingeordnet. Die Registry-Abfrage über Invoke-Command ist in diesem Aufbau nicht gegen echte Windows-Server gelaufen; sie entspricht der Abfrage aus dem Oktober-Beitrag. Lassen Sie das Skript zuerst gegen einen einzelnen Rechner laufen.

„Unbekannt“ ist kein Fehler des Skripts, sondern ein Befund. Dahinter steht meist eine Version, für die es kein reguläres Update mehr gibt. Und „NeustartOffen“ ist die Spalte, die in der Praxis am häufigsten überrascht: Das Update ist installiert, der Server läuft aber noch mit dem alten Code, weil niemand neu gestartet hat.

Für Exchange nennt Microsoft einen eigenen Weg: Get-Command Exsetup.exe | ForEach-Object {$_.FileVersionInfo} in der Exchange Management Shell zeigt die installierte Version, danach gehört der Exchange Server Health Checker gestartet, auf den der KB-Artikel verweist. Beides ist Stand der Microsoft-Dokumentation und von uns für diesen Beitrag nicht gegen einen Exchange-Server getestet.

/07Bekannte Probleme — und was der November repariert

Für die Server-Updates führt Microsoft zum Stand 11.11.2026 kein neues bekanntes Problem. Die Einträge in den KB-Artikeln sind Altlasten, von denen eine jetzt als behoben gilt.

Exchange-Störung aus dem Oktober: behoben

Nach dem Oktober-Update konnten Anmeldungen an Outlook im Web scheitern, Mails im Postausgang hängen bleiben und Warteschlangen wachsen. Microsoft erklärt das Problem mit den Windows-Updates ab dem 10.11.2026 für behoben und nennt die Korrektur auch in der Liste der Verbesserungen. Wer im Oktober den Registry-Workaround gesetzt hat, sollte ihn dokumentiert haben; ob er nach dem November-Update wieder entfernt werden soll, steht in den KB-Artikeln nicht. Für einen Exchange-Server, der im Oktober wegen dieser Störung zurückgestellt wurde, ist der November das Paket, mit dem er wieder auf Stand kommt.

Was sonst repariert wurde

• Drucker, die im Active Directory veröffentlicht sind, ließen sich seit dem Oktober-Update über die Einstellungen teils nicht hinzufügen (Fehler 87). Behoben.
• RD Web Access lud in Edge und Chrome nicht, wenn XSLT per Browserrichtlinie deaktiviert war. Die Seiten werden jetzt auf dem Server gerendert.
• USB-Audiogeräte der Klasse 1.0 starteten seit dem September-Update teils nicht (Code 10). Die verbliebenen Symptome sind laut Microsoft mit dem November-Update behoben.
• Ein In-Place-Upgrade von Server 2016 auf Server 2025 konnte mit Installationsmedien scheitern, die das Oktober-Update enthielten. Behoben in KB5131080.
• Unter Windows 11 konnten RDP-Verbindungen nach dem optionalen Oktober-Vorschauupdate an einem Zertifikatsabgleich scheitern. Behoben in KB5132061.

Was offen bleibt

WSUS zeigt weiterhin keine Fehlerdetails zur Synchronisierung an; Microsoft hat die Funktion entfernt, um eine frühere Lücke zu schließen, und führt den Punkt unverändert als bekanntes Problem. Der Austausch der Secure-Boot-Zertifikate läuft weiter: Geräte ohne die neuen Zertifikate starten laut Microsoft weiterhin und erhalten Updates, die Verteilung über Windows Update geht in den kommenden Monaten weiter.

Die Liste gilt für den Tag nach dem Patchday. Bekannte Probleme tauchen erfahrungsgemäß in der ersten Woche auf, nicht am ersten Tag — ein weiterer Grund für den Testring und für einen Blick in das Windows Release Health Dashboard, bevor Welle 3 beginnt.

/08Wo diese Reihenfolge die falsche ist

Die Tabelle setzt einen Betrieb voraus, in dem Arbeitsplätze Outlook als Desktop-Anwendung nutzen und Server mit festen Rollen laufen. Wo das nicht stimmt, stimmt die Reihenfolge nicht.

Ohne Outlook-Desktop fällt Welle 1 weg. Wer ausschließlich Outlook im Web oder einen anderen Mailclient nutzt, ist von CVE-2026-124194 nach den MSRC-Daten nicht betroffen; dort stehen nur die Klick-und-Los-Pakete. Dann beginnt der Monat mit dem Testring.

Mit einem Server, der alles ist — Domain Controller, Dateiablage, Druckserver und Datenbank auf einer Maschine —, gibt es keine Wellen. Es gibt ein Fenster, eine Sicherung davor und einen Plan für den Fall, dass er nicht wieder hochkommt. Ein Snapshot der VM ist dabei eine Bequemlichkeit, kein Backup; warum das bei Domain Controllern besonders gilt, steht im Oktober-Beitrag.

In Produktionsumgebungen mit Leitrechnern und Maschinenanbindung ist „binnen zwei Wochen“ oft nicht haltbar, weil der Anlagenhersteller Updates freigeben muss. Dann ist die richtige Antwort nicht, die Frist zu ignorieren, sondern das System vom Büronetz zu trennen und die Trennung zu dokumentieren.

Und wer mit Intune und Update-Ringen arbeitet, hat die Wellen bereits als Richtlinie. Die Tabelle taugt dann als Prüfung, ob die Ringe zum Monat passen — etwa ob der Pilotring wirklich Geräte aus den Fachabteilungen enthält.

/09Was warten kann — und was nicht

Nicht warten kann Office. Eine Lücke, die angegriffen wird, an einem Programm, das jeder Mitarbeiter den ganzen Tag offen hat, bei einem Update, das ohne Serverfenster auskommt: Dafür gibt es kein Argument für nächste Woche. Wenn in dieser Woche nur eine Sache passiert, dann diese.

Nicht lange warten sollten Domain Controller und Exchange. Microsoft meldet keine Angriffe, aber zwei Einträge ohne Anmeldung mit CVSS 9,8 auf genau den Systemen, an denen Anmeldung und Mail hängen. Eine Woche mit vorgeschaltetem Test ist dafür angemessen. Den Test zu überspringen, um drei Tage zu gewinnen, wäre in diesem Monat der schlechtere Tausch — wegen der beiden Verhaltensänderungen.

Warten können SQL Server, SharePoint und interne Anwendungsserver, sofern sie nicht aus dem Internet erreichbar sind. Dort ist die Freigabe des Softwareherstellers oft der eigentliche Engpass, und ein Datenbankupdate ohne Rücksprache hat schon mehr Fachanwendungen stillgelegt als jede Lücke. „Warten“ heißt hier: bis zum nächsten geplanten Fenster, nicht bis zum nächsten Quartal.

Wer den Monat nicht selbst abarbeiten will oder kann, sollte wenigstens den Nachweis haben. Die beiden Skripte aus diesem Beitrag liefern ihn: welcher Rechner auf welchem Build steht, wo ein Neustart fehlt, welche signierten Skripte auffallen. Mit Monitoring wird daraus eine Dauerprüfung statt einer Monatsaktion.

/10Häufige Fragen