Sophos Firewall Malware-Scanning konfigurieren und testen

Das Malware-Scanning der Sophos Firewall prüft Dateien im Webtraffic mit den integrierten Antivirus-Engines. Ein aktiviertes Web-Filtering oder eine Web Policy genügt dafür nicht: Die passende Firewall-Regel muss Scan HTTP and decrypted HTTPS verwenden, und verschlüsselter Traffic muss für eine Inhaltsprüfung entschlüsselt werden.

Dieser Artikel konzentriert sich auf Downloads über HTTP und HTTPS. Für Kategorien, URL Groups und Benutzerregeln passt Web Protection mit Web Policies. Unbekannte Dateien kann Zero-Day Protection zusätzlich analysieren; E-Mail-Traffic wird separat über Mail Protection geschützt.

Geltungsbereich, Voraussetzungen und Lizenzen klären

Das klassische Malware-Scanning ist protokoll- und regelgebunden. Für Webdownloads braucht man Web Protection; die Base License allein enthält Web Malware Protection nicht. Zero-Day Protection ist eine eigene Subscription und ergänzt den Antivirus-Scan, ersetzt ihn aber nicht. Für SMTP, POP3 und IMAP ist Email Protection erforderlich. Den tatsächlichen Status und das Ablaufdatum kontrolliert man unter Administration > Licensing; Subscribed oder Evaluating muss beim benötigten Modul stehen. Eine mit dem Internet verbundene Firewall synchronisiert die Lizenzen automatisch alle 24 Stunden. Wirkt der Stand veraltet, erzwingt Administration > Licensing > Synchronize eine Aktualisierung.

Vor der Änderung sollten folgende Voraussetzungen erfüllt sein:

• Die zu bearbeitende Firewall-Regel, ihre Rule ID und Position sowie der aktuelle Zustand ihrer Scanoptionen sind dokumentiert.
• Für HTTPS ist entschieden, ob DPI Engine oder Web Proxy entschlüsselt; der Testclient vertraut der verwendeten Signing CA.
• Web Exceptions und SSL/TLS Exclusion Rules für den Testpfad sind bekannt.
• Ein isolierter Testclient, ein Wartungs- beziehungsweise Pilotfenster und Zugriff auf Log Viewer stehen bereit.
• Unter Backup and firmware > Backup and restore existiert ein aktuelles Backup. Zusätzlich werden die wenigen betroffenen Werte notiert, damit ein Rollback nicht unnötig die gesamte Konfiguration zurücksetzt.

FTP und E-Mail verwenden andere Schalter als Webtraffic. Scan FTP for malware wird in der passenden Firewall-Regel aktiviert; das globale Limit steht unter Web > General settings > Maximum file scan size for FTP. Für E-Mail wählt man am Ende der Firewall-Regel die tatsächlich verwendeten Protokolle IMAP, IMAPS, POP3, POP3S, SMTP und/oder SMTPS; Add ports ergänzt fehlende Standardports. MTA- und Legacy-Policies, Quarantäne und Attachment-Aktionen werden danach unter Email gepflegt. Der primäre E-Mail-Scanner liegt unter Email > General settings > Malware protection. Diese separaten Pfade werden hier abgegrenzt; ihre vollständige Einrichtung gehört in den verlinkten Mail-Protection-Artikel.

Auch Dateityp-Kontrollen sind kein Virennachweis. Eine Web Policy kann Downloads nach Dateityp erlauben oder blockieren, und eine E-Mail-Policy kann Attachments behandeln. Erst ein korrelierter Malware-Logeintrag belegt, dass der Antivirus-Scanner den Inhalt erkannt hat.

Was für einen wirksamen Scan zusammenpassen muss

Das Ergebnis entsteht aus mehreren Ebenen:

• Die richtige Firewall-Regel muss den Clienttraffic tatsächlich treffen.
• Scan HTTP and decrypted HTTPS aktiviert das Malware-Scanning für diesen Regelpfad.
• Web > General settings bestimmt Engine, Scanverhalten, Grössenlimits und die Behandlung nicht scanbarer Inhalte.
• HTTPS-Inhalte werden nur geprüft, wenn DPI oder Web Proxy die Verbindung entschlüsselt.
• Web Exceptions dürfen das Malware-Scanning nicht unbeabsichtigt überspringen.
• QUIC muss kontrolliert werden, weil QUIC-Traffic nicht wie klassisches HTTP und HTTPS gescannt werden kann.

Eine Web Policy und Malware-Scanning lösen unterschiedliche Aufgaben. Die Web Policy entscheidet beispielsweise über Kategorien oder Dateitypen. Der Antivirus-Scan untersucht den Dateiinhalt auf bekannte Malware und PUAs. In einer Firewall-Regel kann Malware-Scanning deshalb auch mit Web policy: None aktiv sein. Umgekehrt bedeutet eine ausgewählte Web Policy nicht automatisch, dass Downloads auf Malware geprüft werden.

Single oder Dual Engine wählen

Unter System services > Malware protection wird die primäre Antivirus-Engine festgelegt. Sophos Firewall verwendet Sophos und Avira; die gewählte Primary Engine scannt bei Single engine allein und bei Dual engine zuerst.

Die globale Auswahl für Webtraffic liegt unter:

Web > General settings > Malware and content scanning

• Single engine: verwendet nur die Primary Engine. Das benötigt weniger Ressourcen und bietet die beste Performance. Für Zero-Day Protection muss Sophos die Primary Engine sein.
• Dual engine: lässt zuerst die Primary und danach die zweite Engine prüfen. Das erhöht die Erkennungsbreite, benötigt aber mehr Zeit und Ressourcen.

Für normale Clientnetze ist Single engine mit Sophos als Primary Engine ein nachvollziehbarer Ausgangspunkt, wenn Durchsatz und Latenz wichtig sind. Dual engine passt, wenn maximale Erkennungsbreite höher gewichtet wird und die Appliance den zusätzlichen Aufwand unter realer Last tragen kann. Die Entscheidung sollte nicht nur nach Datenblattwerten fallen: Ein Pilot mit typischen Downloads, Videokonferenzen und Softwareverteilung zeigt die tatsächliche Auswirkung besser.

⚠️ Ein Wechsel der Primary Engine oder von Single auf Dual wirkt global auf passende Scanpfade. Vor einer Änderung müssen bestehende Web-, FTP- und Mail-Policies sowie Zero-Day Protection berücksichtigt und ein Rückweg dokumentiert werden. Ein Wechsel der globalen primären Antivirus-Engine kann auch eine lokal festgelegte Antivirus-Engine ändern. Nach dem Wechsel werden deshalb die lokalen Engine-Auswahlen kontrolliert.

Machine-Learning-Erkennung der Scan Engine steuern

SFOS 22 kann Machine Learning, kurz ML, global für die Sophos Scan Engine und danach getrennt für Funktionsgruppen aktivieren. ML sucht verdächtige Muster, die in der Signaturdatenbank noch fehlen können. Es erweitert damit die Erkennung schneller oder neuer Bedrohungen, erhöht aber auch das Risiko von False Positives.

Zuerst wird der aktuelle Zustand lesend gesichert:

show scanengine

Die dokumentierten Standards sind global ml_scan on, für Web Proxy und DPI Engine ml_web_detection off, für Email ml_email_detection on sowie für WAF und FTP Proxy ml_legacy_detection off. Ist ml_scan global off, kann ML in den einzelnen Funktionsgruppen nicht wirksam eingeschaltet werden. Die Feature-Schalter bestimmen, ob eine ML-Erkennung dort eine Blockaktion auslösen kann.

Die vollständige CLI-Syntax lautet:

set scanengine ml_scan <on|off>
set scanengine ml_web_detection <on|off>
set scanengine ml_email_detection <on|off>
set scanengine ml_legacy_detection <on|off>
set scanengine thread_count <1-128|default>

thread_count gilt pro Scan Engine. Der Bereich reicht von 1 bis 128; default berechnet die Anzahl dynamisch aus den verfügbaren CPUs. Eine feste Threadzahl wird nicht als allgemeines Performance-Tuning übernommen. Sie braucht reproduzierbare Scannerlast, CPU- und Speichermessung, Durchsatztest und in der Regel eine konkrete Supportvorgabe. Die ältere Option max_buffer_size ist veraltet und wird nicht mehr verändert.

⚠️ ML kann legitime Dateien oder Traffic fälschlich blockieren und erzeugt bei Erkennungen Telemetrie für Sophos Labs. Aktivierung, Datenschutz, betroffene Datenpfade und False-Positive-Prozess werden deshalb vor dem Rollout geklärt; ein globales Abschalten auf Verdacht ist ebenso wenig ein sauberer Fix wie eine ungeprüfte Freigabe.

Der Pilot beginnt mit genau einer Funktionsgruppe und einem kontrollierten Client oder Mailfluss. Vorher und nachher werden show scanengine, Policy, Blockaktion, Log Viewer, Anwendungsergebnis, CPU und Scanzeit verglichen. EICAR bestätigt den normalen Malware-Scan, beweist aber keine ML-Erkennung eines neuen Musters. Der Rollback stellt die mit show scanengine gesicherten Werte wieder her und wird nicht blind mit den Produktdefaults gleichgesetzt.

Scanverhalten festlegen

Unter Web > General settings werden neben der Engine weitere Schutzentscheidungen getroffen.

Nicht scanbare Inhalte

Action on malware scan failure legt fest, was mit Inhalten passiert, die nicht vollständig geprüft werden können. Das kann bei verschlüsselten oder beschädigten Archiven sowie bei zu tief verschachtelten Dateien vorkommen. Sophos Firewall scannt Archive bis zu 16 Komprimierungsebenen.

Block bietet den stärkeren Schutz, kann aber legitime passwortgeschützte oder defekte Dateien stoppen. Allow erhält den Geschäftsprozess, lässt dafür ungeprüften Inhalt passieren. In normalen Clientnetzen ist Block der sicherere Ausgangspunkt. Wenn eine Fachanwendung dadurch ausfällt, sollte zuerst der konkrete Dateipfad untersucht werden, bevor die globale Einstellung gelockert wird.

Dateigrössen und Streaming

Do not scan files larger than setzt die maximale Scan-Grösse für HTTP und HTTPS. Grössere Dateien werden nicht gescannt. Bei komprimierten Dateien zählt die Grösse des Archivs, nicht die mögliche Grösse nach dem Entpacken. Für FTP gibt es mit Maximum file scan size for FTP einen eigenen Grenzwert.

Ein kleiner Grenzwert verbessert nicht automatisch die Sicherheit, sondern kann grosse Installer oder Archive ungeprüft passieren lassen. Ein sehr hoher Wert kann dagegen Downloadzeit und Ressourcenverbrauch erhöhen. Der Wert muss deshalb zu Softwareverteilung, Updatepaketen und Appliance-Leistung passen.

Unter Web > General settings öffnet man Advanced settings, um Scan audio and video files zu erreichen. Scan audio and video files erweitert den Scan auf Medieninhalte, kann Streaming aber beeinträchtigen. Die Option sollte nur aktiviert werden, wenn der Schutzbedarf die zusätzliche Last und mögliche Unterbrechungen rechtfertigt. Nach der Auswahl der gewünschten Web-Scaneinstellungen übernimmt man die Änderungen mit Apply.

PUAs behandeln

Block potentially unwanted applications erkennt Programme, die nicht zwingend Malware sind, aber beispielsweise Adware, unerwünschte Fernsteuerung oder riskante Systemänderungen mitbringen können. Ein Eintrag unter Authorized PUAs sollte nur nach Prüfung von Datei, Quelle, Einsatzzweck und Owner erfolgen. Eine pauschale Freigabe schwächt den Schutz für alle passenden Scanpfade.

Malware-Scanning in der Firewall-Regel aktivieren

Die Regel liegt unter:

Rules and policies > Firewall rules

Für eine typische Client-Internetregel wird unter Web filtering Folgendes geprüft:

1. Source zone und Source networks entsprechen dem Clientnetz.
2. Destination zone ist WAN, und die Services decken den vorgesehenen Webtraffic ab.
3. Log firewall traffic ist aktiviert.
4. Scan HTTP and decrypted HTTPS ist aktiviert.
5. Block QUIC protocol ist aktiviert, wenn der Webtraffic über den kontrollierten TCP-Pfad laufen soll.
6. DPI oder Web Proxy ist bewusst gewählt.
7. Use Zero-day protection ist nur zusätzlich aktiviert, wenn unbekannte Dateien analysiert werden sollen.

Ein kompaktes Regelbeispiel:

Rule name: LAN_USERS_WEB
Source zones: LAN
Source networks and devices: LAN_CLIENTS
Destination zones: WAN
Destination networks: Any
Services: HTTP, HTTPS
Web policy: LAN_STANDARD_WEB
Scan HTTP and decrypted HTTPS: On
Block QUIC protocol: On
Use web proxy instead of DPI engine: Off
Log firewall traffic: On

Das Beispiel verwendet den DPI Engine. LAN_USERS_WEB, LAN_CLIENTS und LAN_STANDARD_WEB sind Beispielnamen und werden durch die eigenen Objekte ersetzt. Für einen reinen Malware-Scan darf Web policy auch None sein. Die Services sollten nur die tatsächlich benötigten Protokolle enthalten; Any wäre breiter als für dieses Webbeispiel nötig. Eine allgemeinere Regel oberhalb von LAN_USERS_WEB kann den Traffic vorher übernehmen; deshalb gehören Rule ID und Regelreihenfolge immer zur Abnahme. Die Grundlagen erklärt Firewall-Regeln verstehen und sauber aufbauen.

HTTPS: DPI oder Web Proxy richtig ergänzen

Scan HTTP and decrypted HTTPS entschlüsselt HTTPS nicht selbst. Die Option scannt nur unverschlüsseltes HTTP und HTTPS-Inhalte, die ein anderer Teil der Konfiguration bereits entschlüsselt hat.

DPI Engine

Beim DPI Engine erfolgt die Entschlüsselung über:

Rules and policies > SSL/TLS inspection rules

Eine passende SSL/TLS-Inspection-Regel muss den Testclient und das Ziel treffen und Action: Decrypt verwenden. Die Clients müssen der verwendeten Signing CA vertrauen. Planung, Pilot und Ausnahmen beschreibt TLS Inspection schrittweise ausrollen; die Zertifikatsverteilung steht unter CA-Zertifikat für HTTPS Scanning installieren.

Web Proxy

Beim Proxy-Pfad werden in der Firewall-Regel Use web proxy instead of DPI engine und für HTTPS zusätzlich Decrypt HTTPS during web proxy filtering aktiviert. Unter Web > General settings kann der Proxy danach in zwei Modi scannen:

• Batch: lädt die Datei zuerst vollständig auf die Firewall und gibt sie erst nach dem Scan weiter. Das bietet die strengere Prüfung, kann Downloads aber spürbar verzögern.
• Real-time: reicht Teile des Downloads weiter, schliesst die Übertragung jedoch erst ab, wenn der Inhalt als sauber bewertet wurde.

Bei Batch kann der vorgelagerte Download zur Firewall die volle Bandbreite nutzen und dadurch andere Webzugriffe beeinträchtigen. Im allgemeinen Proxy-Scanpfad erfolgt Traffic Shaping sowohl bei Batch als auch bei Real-time bei der Weitergabe an den Browser, nicht als Zusage einer Begrenzung dieses vorgelagerten Batch-Downloads. Für Direct Web Proxy gilt die ausdrückliche Ausnahme: Eine Traffic Shaping Policy greift dort nicht. Vor einem Scanmoduswechsel den bisherigen Wert dokumentieren; mit denselben repräsentativen Downloads WAN-Auslastung, Client-Downloadzeit, Scanresultat und Rule ID vergleichen. Bei einer Regression den vorherigen Scanmodus wiederherstellen, statt gleichzeitig Engine oder Policy zu ändern.

Der DPI Engine arbeitet immer im Real-time-Modus. Proxy und DPI sollten nicht nur wegen eines einzelnen Fehlers gewechselt werden, da sich Funktionsumfang, Ports, Logs und Benutzerverhalten unterscheiden.

Die Entscheidung zwischen Real-time-DPI, Batch- oder Real-time-Proxy und der sichere Pilotwechsel stehen in DPI Engine oder Web Proxy richtig wählen.

Ausnahmen und QUIC kontrollieren

Eine Web Exception kann Malware and content scanning überspringen. In diesem Fall wird für den passenden Traffic automatisch auch die Zero-Day-Analyse übersprungen. Ausnahmen sollten deshalb einen engen Host- oder URL-Bezug, einen klaren Owner und ein Review-Datum haben.

QUIC beziehungsweise HTTP/3 verwendet meist UDP 443. Sophos Firewall kann diesen Traffic nicht wie klassischen Webtraffic scannen. Block QUIC protocol blockiert in der betreffenden Firewall-Regel ausgehendes UDP auf Port 80 und 443, damit kompatible Clients auf TCP und HTTPS zurückfallen. Hintergründe und Tests stehen unter QUIC und HTTP/3 richtig blockieren.

Funktion mit einem sicheren Test prüfen

Ein grüner Policy Test oder eine aktivierte Checkbox beweist noch keine Inhaltsprüfung. Der Test muss von einem Client hinter der betroffenen Firewall-Regel ausgehen; ein Download direkt von der Firewall prüft einen anderen Trafficpfad.

Für die Prüfung des Sophos-Firewall-Webpfads ist auf der SophosTest-Seite für Web Security gezielt die Aktion Anti-virus EICAR test vorgesehen. Soll der Transport der standardisierten Testdatei unabhängig von dieser Testseite geprüft werden, verwendet man stattdessen eine Variante der EICAR Anti-Malware Testdatei. EICAR ist keine echte Malware, wird von Antivirus-Produkten aber absichtlich wie Malware erkannt. Reale Schadsoftware gehört nicht in ein Produktivnetz; die Testdatei wird weder geöffnet noch ausgeführt.

Praktischer Ablauf:

1. Einen isolierten Testclient und die erwartete Firewall Rule ID festlegen. Temporäre Allow-Ausnahmen sind für diesen Test nicht nötig. Reagiert der Endpoint-Schutz zuerst, wird er nicht abgeschaltet; das Ergebnis wird stattdessen als nicht eindeutiger Firewall-Test gewertet.
2. Zeitpunkt, Client-IP, gewählte Test-URL und erwarteten Scanpfad notieren.
3. Im Log Viewer die Module Firewall, SSL/TLS inspection, Web filter und Malware öffnen.
4. Bei HTTPS prüfen, ob die Verbindung tatsächlich mit Decrypt verarbeitet wird.
5. Auf SophosTest Anti-virus EICAR test ausführen oder genau eine EICAR-Downloadvariante laden. Erwartet wird, dass die Firewall die Übertragung vor dem vollständigen Download unterbricht.
6. Prüfen, ob das Malware-Log eine Antivirus-Erkennung für denselben Client, dieselbe Rule ID, dieselbe URL und denselben Zeitpunkt zeigt.
7. Die Testseite schliessen und eventuell entstandene Teil- oder Testdateien sowie Browser-Cache-Artefakte nach dem Endpoint-Prozess entfernen; ein quarantänisiertes Objekt nicht wiederherstellen oder ausführen. Temporäre Testeinstellungen zurücknehmen und mit einem normalen Download prüfen, dass der Webzugriff weiterhin funktioniert.

Eine Blockseite allein genügt nicht. Die Web Policy, eine Dateityp-Regel, ein Endpoint-Produkt oder bereits die Kategorie der Testseite kann ebenfalls blockieren. Entscheidend ist der korrelierte Malware-Eintrag der Firewall. Im Syslog erscheint ein Web-Malware-Treffer mit log_type="Anti-Virus"; die Komponenten sind je nach Protokoll HTTP oder HTTPS, der Subtype bei einer Erkennung Virus.

Wenn der Log Viewer nicht erklärt, ob der lokale Antivirus-Dienst arbeitet, kann in der Advanced Shell während eines kontrollierten Tests zusätzlich das Service-Log beobachtet werden:

tail -f /log/avd.log

Mit Ctrl+C wird die Anzeige beendet. avd.log hilft bei Dienst- und Engine-Fehlern, ersetzt aber nicht die Policy- und Verbindungsdaten im Log Viewer. Eine ruhige Datei beweist ebenfalls nicht, dass der Scan inaktiv ist. Die Logzuordnung erklärt Sophos Firewall Services und Logs.

Typische Fehler gezielt eingrenzen

• Web Policy aktiv, aber keine Malware-Prüfung: Scan HTTP and decrypted HTTPS fehlt in der tatsächlich getroffenen Firewall-Regel.
• HTTP-Test funktioniert, HTTPS-Test nicht: Die SSL/TLS-Inspection-Regel trifft nicht, verwendet nicht Decrypt, oder der Web Proxy entschlüsselt HTTPS nicht.
• Browser verwendet einen anderen Pfad: QUIC ist erlaubt oder eine andere Firewall-Regel greift zuerst.
• Datei wird trotz richtiger Regel nicht geprüft: Eine Web Exception überspringt Malware and content scanning, oder die Datei liegt oberhalb des konfigurierten Grössenlimits.
• EICAR wird blockiert, aber nicht von der Firewall: Endpoint-Schutz, Dateityp-Regel oder Webkategorie hat früher reagiert. Rule ID und Malware-Log der Firewall prüfen.
• Legitime Archive werden blockiert: Action on malware scan failure, Verschlüsselung, Beschädigung und Verschachtelung prüfen. Nicht sofort global auf Allow wechseln.
• Dual Engine verlangsamt Downloads: Appliance-Auslastung, Dateigrössen, Parallelität und Proxy-/DPI-Modus mit Single Engine in einem kontrollierten Pilot vergleichen.
• Zero-Day Protection zeigt nichts: Klassischer Malware-Scan, HTTPS-Entschlüsselung, Dateityp, Ausnahmen und Use Zero-day protection separat prüfen.
• Scanoption fehlt oder lässt sich nicht speichern: Unter Administration > Licensing Status und Ablaufdatum von Web Protection, Email Protection oder Zero-Day Protection prüfen und danach die Lizenzen synchronisieren. Nicht durch eine breitere Allow-Regel umgehen.
• FTP-Datei wird nicht geprüft: Getroffene Rule ID, Scan FTP for malware, Service und Maximum file scan size for FTP gemeinsam kontrollieren. Der HTTP/HTTPS-Schalter aktiviert keinen FTP-Scan.
• E-Mail-Anhang wird nicht erkannt: Zuerst den tatsächlichen Mailpfad bestimmen: MTA, Legacy SMTP oder POP/IMAP. Danach die in der getroffenen Firewall-Regel ausgewählten Protokolle und Ports, die passende E-Mail-Policy, Single/Dual Antivirus, Ausnahmen und das Mail- beziehungsweise Malware-Log korrelieren.

Welche Firewall-Regel und Policy tatsächlich greift, lässt sich mit Log Viewer, Policy Tester und Packet Capture nachvollziehen.

Änderungen zustandserhaltend zurücknehmen

Ein Rollback setzt nur die Werte zurück, die im Pilot geändert wurden. Dafür werden die vorab notierten Einstellungen in umgekehrter Reihenfolge wiederhergestellt: SSL/TLS-Inspection-Regel und ihre Position, Firewall-Regel mit Rule ID und Position, Proxy-/DPI-Auswahl, Scan- und QUIC-Schalter, globale Single-/Dual-Engine-Auswahl sowie die Ausgabe von show scanengine. Eine Firewall-Regel wird nicht gelöscht und Malware-Scanning nicht global abgeschaltet, nur weil ein einzelner Download fehlschlägt.

Danach werden die Konfiguration gespeichert und zwei Kontrollen wiederholt: Ein normaler repräsentativer Download muss funktionieren, und der isolierte EICAR-Test muss wieder genau das erwartete Vorher-Verhalten zeigen. Stimmen Rule ID, Entschlüsselungsstatus oder Logaktion nicht mit der Baseline überein, ist der Rollback noch nicht abgeschlossen. Das vollständige Backup ist der Notfallweg für eine breitere Fehlkonfiguration, nicht der erste Schritt für eine einzelne Checkbox.

Sonderfall beim Upgrade auf SFOS 22.0 GA

Unter NC-177529 ist ein eng begrenzter Upgradefehler für SFOS 22.0 GA Respin Build 411 dokumentiert. Während dieses Upgrades können vorübergehend Meldungen wie Malware Unscannable auftreten, häufig für www.msftconnecttest.com. In diesem Moment ist die neue Sophos-Scan-Engine noch nicht verfügbar, wenn nur sie als Single Engine eingestellt ist. Im Legacy Web Proxy erscheinen dann Blockseiten, beim DPI Engine können Seitenaufrufe abbrechen; die Unterbrechung kann ungefähr eine Minute länger dauern. Vor jedem Upgrade wird zusätzlich geprüft, welche Maintenance Release aktuell ist und welche Upgradepfade gelten; der verlinkte Upgrade-Check führt durch diese versionsabhängige Kontrolle.

Wer gezielt auf diese GA-Version aktualisiert, stellt vor dem Upgrade unter Web > General settings von Single engine auf Dual engine um und nach abgeschlossenem Upgrade wieder auf die zuvor verwendete Single engine zurück. Diese temporäre Massnahme ist keine allgemeine Empfehlung für MR1, MR2 oder spätere Releases. Den gesamten Upgradepfad und weitere Blocker beschreibt der SFOS 22 Upgrade-Check.

FAQ