Sophos Supportticket mit Support Assistant eröffnen

Für einen neuen Supportfall gibt es zwei reguläre Wege: direkt in Sophos Fusion (ehemals Sophos Central) über das Help-Menü oder im Sophos Support Portal über den Support Assistant. Teilnehmende Central-Tenants haben zusätzlich einen eigenen Assistant als Early Access Program. Seit dem 18. Juli 2026 ersetzt der Assistant im Support Portal für eingeloggte Kunden das bisherige Formular New Technical Support Case.

💡 Wichtig: Der Support Assistant ist ein AI-gestützter Wegweiser, kein Support Engineer und noch kein eröffnetes Ticket. Vorschläge müssen vor einer Änderung fachlich geprüft werden. Ein Case ist erst erstellt, wenn Sophos eine Case-Nummer anzeigt oder per E-Mail bestätigt.

Eine gute Vorbereitung bleibt deshalb wichtiger als der neue Dialog. Bei Sophos Firewall gehören vor allem Seriennummer, Modell, Firmwareversion, Lizenzstatus, Fehlerzeitpunkt, betroffene Funktion, Logs, Screenshots und bereits geprüfte Schritte ins Beweispaket. Für die Einordnung der verschiedenen Sophos-Zugänge passt zusätzlich Sophos Portale: SophosID, Central, Support und Firewall-Zugänge.

Wann ein Sophos Supportticket sinnvoll ist

Ein Sophos Supportticket ist sinnvoll, wenn ein Problem nicht mehr nur lokal durch Konfiguration, Logs oder bekannte Betriebsprozesse geklärt werden kann.

Typische Fälle:

• Hardwaredefekt, RMA oder Verdacht auf defekte Appliance
• Lizenz- oder Accountproblem mit konkreter Seriennummer
• Firmware-, Hotfix- oder Upgradeproblem
• wiederkehrender Dienstabsturz oder unklarer Systemzustand
• VPN-, WAF-, HA-, RED- oder Routingproblem nach eigener Eingrenzung
• Fehler, der nach Logs und Reproduktion nach einem Produktproblem aussieht
• Supportanfrage, bei der Sophos Zugriff auf interne Analysedaten benötigt

Vor einem Ticket sollte man die naheliegenden lokalen Prüfungen durchführen. Bei Sophos Firewall heisst das nicht, dass alles bereits gelöst sein muss. Aber je genauer Ausgangslage, Zeitfenster und betroffene Funktion beschrieben sind, desto weniger Rückfragen entstehen.

Was Sophos Support leistet und was nicht

Sophos Support hilft bei technischen Produktproblemen und kann allgemeine Konfigurationsfragen beantworten. Der Support ersetzt aber keine vollständige Implementation, Migration oder neue Architekturplanung. Ein Ticket passt besonders dann, wenn eine Funktion trotz nachvollziehbarer Konfiguration nicht ordnungsgemäss arbeitet oder ein konkreter Produkt-, Lizenz-, Hardware- oder Softwarefehler vermutet wird.

Für diese Aufgaben ist ein normaler Produkt-Supportfall nicht der passende Hauptweg:

• neue VPN-Topologie planen
• Firewall-Regeln sauber strukturieren
• NAT oder WAF für einen neuen Dienst einrichten
• HA-Design prüfen
• Routingkonzept oder VLAN-Architektur bewerten
• bestehende Konfiguration auf Best Practices umbauen

In solchen Fällen ist Avanet Support der bessere Ansprechpartner. Dann kann die Firewall im Rahmen der Avanet Supportkonditionen geprüft, geplant oder wunschgemäss konfiguriert werden. Der Sophos Support bleibt der richtige Weg für konkrete Produktfehler und für allgemeine Hilfestellung innerhalb seines dokumentierten Supportumfangs.

Severity und Priorität richtig einordnen

Der Supportplan bestimmt Anspruch und Reaktionsziele; massgebend sind die Bedingungen des betroffenen Vertrags zum Zeitpunkt der Fallanlage. Die hier verwendeten Stufen sind deshalb bewusst nicht mit festen Zeitangaben verknüpft. Ein Reaktionsziel ist zudem keine garantierte Lösungszeit.

Die Severity wird nach der tatsächlichen aktuellen Auswirkung gewählt, nicht nach der gewünschten Bearbeitungsgeschwindigkeit. Bei einem geschäftskritischen Fall nennt man betroffene Standorte und Benutzer, fehlenden Workaround, Beginn und Zeitzone, Redundanzstatus und bereits geprüfte Massnahmen. Ändert sich die Auswirkung, wird derselbe Case mit den neuen Fakten aktualisiert statt ein zweiter eröffnet.

Voraussetzungen

Für ein technisches Supportticket braucht man in der Regel:

• SophosID für das Support Portal
• gültige Lizenz beziehungsweise aktiven Supportanspruch
• betroffene Seriennummer oder Account-Zuordnung
• bei Partnerfällen: Kundenzuordnung und relevante Lizenz- oder Seriennummer
• Produkt und Modell, zum Beispiel XGS Appliance oder virtuelle Firewall
• Firmwareversion und Build
• kurze Fehlerbeschreibung mit Auswirkung
• Zeitfenster des Problems mit Zeitzone
• vorhandene Logs, Screenshots oder Fehlermeldungen

Sophos prüft bei Supportfällen die Lizenz- und Seriennummernzuordnung. Ohne passende Lizenz oder Seriennummer kann ein Case zur Validierung an Customer Care gehen. Das verzögert die technische Bearbeitung. Wenn ein Partner den Case für einen Kunden eröffnet, müssen Kundenzuordnung und betroffene Lizenz- oder Seriennummer ebenfalls sauber angegeben werden. Falls Avanet Supportfälle im Namen eines Kunden verwalten soll, muss der Kunde Avanet als Partner den entsprechenden Zugriff erlauben.

Die Seriennummer der Firewall findet man direkt im SFOS Dashboard. Der Ablauf ist in Seriennummer der Sophos Firewall finden beschrieben.

Wenn die Anfrage einen Hardwaredefekt betrifft, sollte zusätzlich der Artikel Wie gehe ich bei einem technischen Defekt meiner Sophos Hardware vor? geprüft werden.

Supportwege einordnen

Sophos bietet mehrere Wege zum Support. Nicht jeder Weg ist für denselben Zweck gleich gut.

Typische Supportwege:

• Help-Menü in Sophos Fusion: direkter Formularweg für einen Central-Supportfall; Remote Assistance kann dabei optional freigegeben werden.
• Support Assistant im Sophos Support Portal: primärer Einstieg für eingeloggte Kunden, Self-Service, Lizenzfragen und geführte Case-Erstellung.
• Cases im Support Portal: bestehende Fälle, Historie, Anhänge, Status und Eskalation verwalten.
• Telefon: Critical- und High-Fälle eröffnen sowie dringende oder portalbezogene Zugangsprobleme klären.
• Sophos Community: nicht vertrauliche Fragen, bekannte Fehlerbilder und Austausch mit anderen Admins.
• Sophos TechVids und Docs: How-to-Themen, Konfiguration und bekannte Abläufe.

Zusätzlich testet Sophos einen Support Assistant innerhalb von Sophos Fusion als Early Access Program. Er erscheint bei teilnehmenden Tenants über das Sparkle-Symbol in der oberen Central-Leiste. Dieser EAP-Assistent ist nicht mit dem Assistant auf support.sophos.com synchronisiert; frühere Portal-Chats erscheinen daher nicht in seiner Chatliste.

Der Central-Assistent durchsucht Sophos-Dokumentation und KB-Artikel, kann über Show me my support cases bestehende Cases anzeigen und mit Create a new support case eine neue Case-Erstellung beginnen. Mit der ausdrücklichen Bitte um einen menschlichen Support Agent wird der Chat eskaliert und dabei ein Ticket zur Nachverfolgung erzeugt. Frühere Central-Chats bleiben auch nach Abmeldung oder einem Inaktivitäts-Timeout fortsetzbar. Für einen nachvollziehbaren Supportfall zählt trotzdem die bestätigte Case-Nummer, nicht nur ein begonnener AI-Chat.

Wer einen normalen technischen Firewall-Fall im Support Portal eröffnet, beginnt beim Support Assistant. Critical- und High-Fälle werden dagegen telefonisch eingeleitet, nicht über Web oder E-Mail. Bei einem Critical-Fall erstellen eingeloggte Benutzer zusätzlich zuerst den Web-Case, notieren dessen Nummer und rufen dann an; ohne Support-Portal-Account nutzt man direkt den Telefonweg For Critical Cases. Für High gilt diese Abfolge aus Web-Case, Case-Nummer und Anruf nicht. Man verlässt sich bei dringenden Fällen nicht allein auf einen Assistant-Chat. Am Telefon nennt man Produkt, Seriennummer, Auswirkung, Workaround-Status und, falls vorhanden, die Case-Nummer.

Telefonnummern können sich ändern. Im Supportbereich wählt man deshalb die eigene Region und das Land, prüft Gebührenhinweise und hält die vorhandene Case-Nummer bereit. Ist die Anmeldung am Portal nicht möglich, nutzt man dort den ausdrücklich angebotenen Telefonweg For Critical Cases und nennt zusätzlich das Zugangsproblem.

Managed-Risk-Anliegen richtig weiterleiten

Fragen zum Managed-Risk-Service und Änderungen an Scan-Einstellungen gehören nicht in einen normalen Produkt-Supportfall. Dafür in Sophos Fusion Threat Analysis Center > Cases > Create case > Managed Risk service request öffnen. Den vollständigen Ablauf erklärt Managed-Risk-Cases erstellen und verwalten.

Funktioniert dagegen ein Produkt oder die Managed-Risk-Appliance nicht ordnungsgemäss, ist Product Support der richtige Empfänger. Vor der Eskalation hilft das Managed-Risk-Troubleshooting, die sicheren Prüfungen und das passende Beweispaket einzugrenzen. Fehlertext, Zeitpunkt mit Zeitzone, sichtbaren Status, betroffenen Scan oder Appliance und bereits ausgeführte Prüfungen angeben, aber niemals Kennwörter, Tokens, private Schlüssel oder andere Geheimnisse mitsenden.

Account und Partnerzugriff vorbereiten

Für das Support Portal wird eine SophosID benötigt. Der Account sollte zur Firma, Lizenz oder zum Sophos Fusion Tenant passen, damit die betroffenen Produkte sichtbar sind. Falls die Firewall über einen Partner betreut wird, sollte vor dem eigentlichen Supportfall geklärt sein, ob der Partner die Cases verwalten darf.

Wenn Avanet einen Case im Namen eines Kunden begleiten oder mit Sophos kommunizieren soll, muss der Zugriff auf die Kundenzuordnung im Sophos Support Portal erlaubt sein.

Praktisch bedeutet das:

1. SophosID prüfen und betroffene Lizenz oder Seriennummer bereithalten.
2. Falls Avanet unterstützen soll, auf der Portal-Startseite unter My Partners beim gewünschten Partner Grant data access wählen, Bedingungen prüfen und mit Confirm bestätigen.
3. Der Partner sieht danach alle Assets des Accounts. Die Freigabe sollte deshalb nur an den vorgesehenen Partner gehen und nach dem Fall wieder geprüft werden.
4. Fehlt My Partners, muss Customer Care das Profil gegebenenfalls zuerst auf Super Customer umstellen. Bei monatlichen Lizenzen über einen MSP kann der Kunde diese Freigabe nicht selbst erteilen; der MSP eröffnet den Fall in seinem Namen.
5. Support Access auf der Firewall erst vorbereiten, wenn Sophos für den konkreten Case Remote-Zugriff benötigt.

Vor dem Ticket vorbereiten

Ein Support Case sollte so formuliert sein, dass der Support das Problem ohne Rätselraten einordnen kann.

Technische Eckdaten

Für Sophos Firewall sollten diese Angaben bereitliegen:

• Seriennummer
• Modell oder Plattform
• Firmwareversion und Build
• Lizenzstatus oder Supportplan, falls relevant
• HA-Status, falls die Firewall Teil eines Clusters ist
• betroffene Funktion, zum Beispiel IPsec, SSL VPN, WAF, RED, Web Protection oder Reporting
• genaue Uhrzeit des Fehlers mit Zeitzone
• betroffene Benutzer, Netze, Standorte oder Dienste
• letzte Änderungen vor dem Problem

Bei HA-Clustern sollten beide Nodes eindeutig dokumentiert sein. Für die Einordnung von Rollen, Seriennummern und HA-Betrieb passt Sophos Firewall HA Cluster Varianten und Betrieb.

Reproduktion und Auswirkung

Die Beschreibung sollte nicht nur sagen, dass etwas nicht funktioniert. Besser ist eine kurze, prüfbare Darstellung:

• Was wurde erwartet?
• Was passiert stattdessen?
• Seit wann tritt das Problem auf?
• Ist das Problem dauerhaft oder sporadisch?
• Wie kann man es reproduzieren?
• Welche Benutzer oder Dienste sind betroffen?
• Gibt es einen Workaround?
• Wie kritisch ist die Auswirkung auf den Betrieb?

Wenn ein Ticket nur aus einem Screenshot und einem Satz besteht, muss der Support fast zwangsläufig zurückfragen. Das kostet Zeit, besonders bei VPN-, Routing- oder HA-Problemen.

Logs und Anhänge

Bei Firewall-Problemen sind Logs oft wichtiger als lange Vermutungen. Wenn das Problem reproduzierbar ist, sollte man den Fehlerzeitraum möglichst genau festhalten und danach die passenden Logs sichern.

Je nach Problem sind hilfreich:

• Screenshot der Fehlermeldung
• Log Viewer Screenshot mit Filter
• relevante Service-Logs
• Packet Capture oder tcpdump, wenn Paketfluss unklar ist
• Firmware- oder Lizenz-Screenshot
• kurzer Netzplan oder betroffene IP-Adressen, wenn Routing beteiligt ist
• Beschreibung der bereits geprüften Regeln, NAT-Objekte oder VPN-Parameter

Für vollständige Logarchive ist Sophos Firewall Logs für Support und Analyse sichern der passende Ablauf. Welche Logdatei zu welchem Modul gehört, ist in Sophos Firewall Service Logs richtig zuordnen zusammengefasst.

Nicht jeder Anhang beantwortet dieselbe Frage:

• Welche Regel oder welches Modul hat entschieden? Log Viewer Export, Rule ID, NAT ID und betroffener Zeitraum.
• Welcher Dienst meldet Fehler? Relevante Service-Logs oder vollständiges /log-Archiv.
• Kommt Traffic an und geht er weiter? Packet Capture im WebAdmin.
• Braucht Support eine PCAP-Datei? Enger tcpdump-Mitschnitt, separat vom Logarchiv.
• Hat eine Änderung das Problem ausgelöst? Audit Trail, Änderungszeitpunkt und betroffene Objekte.

Ein breites Logarchiv ohne Fehlerzeitpunkt ist oft weniger hilfreich als ein kleineres Datenpaket mit genauer Uhrzeit, klarer Reproduktion und passendem Mitschnitt. Bei Paketflussproblemen sollte die PCAP-Datei getrennt vom Logarchiv behandelt werden, damit im Ticket klar bleibt, welche Datei Service-Logs und welche Datei Netzwerkpakete enthält.

⚠️ Logs, Screenshots und Packet Captures können interne IP-Adressen, öffentliche IPs, Benutzernamen, Hostnamen, Zertifikatsdetails oder andere vertrauliche Informationen enthalten. Vor dem Hochladen sollte klar sein, wer die Daten erhält und ob sie vorher bereinigt werden müssen.

Belege bei einer fehlgeschlagenen ITDR-Integration

Wenn die Wiederherstellungsschritte ausgeschöpft sind, ergänzen Sie den bestehenden Supportfall nur um die ITDR-spezifischen Belege. Gleichen Sie die Beobachtung vorher mit der Anleitung für die Microsoft-Entra-ID-Integration beziehungsweise den ITDR-Sensor für lokales Active Directory ab; Status und untergeordnete Integrationen werden in den ITDR Identity Settings geprüft.

• Produkt Sophos ITDR, Integrationstyp und Integrationsname sowie betroffener Sophos-Tenant und Entra-Tenant beziehungsweise AD-Domains
• exakter Fehlertext; bei Entra-Zeilen sichtbarer Health Status und betroffene Child Integrations, bei der lokalen AD-Integration sichtbare Werte für Health und Status sowie Prüfzeit mit Zeitzone
• erwartetes und tatsächliches Verhalten, Beginn und betriebliche Auswirkung sowie Zeitpunkt der letzten erfolgreichen Synchronisation
• letzte Consent-, Lizenz-, Sensor-, Domain-, Filter- oder Netzwerkänderungen und bereits ausgeführte Recovery-Schritte mit Ergebnis
• bei Entra: aktive Lizenz, geprüfte Microsoft-Quelldaten und berücksichtigter Erfassungstakt; bei lokalem AD: Windows- und .NET-Version, Synchronisationslauf sowie Resultate der getrennten DNS- und HTTPS-Prüfungen
• bereinigte Screenshots und nur die vom Support konkret angeforderten Anhänge

Geben Sie die Severity nach der tatsächlichen Auswirkung an. Kennwörter, Client Secrets, Tokens, Cookies und andere Anmeldedaten gehören weder in Beschreibung noch Screenshots oder Anhänge; legen Sie auch keine angenommenen Logpfade oder Dateien bei.

NDR-Appliance und Investigation Console

Bei einem NDR-Fall zuerst festhalten, welche Komponente betroffen ist: NDR-Integration beziehungsweise Integrations-Appliance oder die separate Investigation Console. Für eine Integrations-Appliance führt der zentrale Weg über Threat Analysis Center > Integrations > Configured > Integration Appliances. Dort Appliance-Name, Typ, sichtbaren Status, Zeitpunkt mit Zeitzone und betroffene NDR- oder Log-Collector-Arbeitslast dokumentieren; System ID und Version stehen im Appliance Manager. Im Drei-Punkte-Menü fordert Collect logs die Appliance-Logs an; ohne VM-Zugriff nennt man Sophos Support anschliessend den unter Log requested angezeigten Dateinamen. Mit berechtigtem VM-Zugriff lässt sich das Paket über Open Appliance Manager > Actions > Download Log File beziehen.

Für die Investigation Console wählt man auf der Seite Investigation Console beim betroffenen Eintrag Collect Logs. Ist die Konsole lokal erreichbar, zeigt System Details Name, Uptime, CPU-, Speicher- und Datenträgerwerte; unter Actions > Download Log File steht ein ZIP-Logpaket bereit. Health Logs liefert zusätzlich filterbare Meldungen zur Verbindung zwischen Console und zugeordneten Integration Appliances. Notiere bei allen Wegen den Fehlerzeitraum und die Zeitzone, statt unkommentierte Vollarchive hochzuladen.

Kennwörter, private Schlüssel, Tokens und Session-Cookies gehören nicht ins Ticket. Prüfe das erzeugte Logpaket vor dem Upload gemäss der eigenen Richtlinie auf vertrauliche Daten. Entferne solche Inhalte nur, wenn dies zulässig ist und die Diagnostik nicht verfälscht.

Aktiviere einen von Sophos angeforderten, komponentenspezifischen Remote Assistant erst, wenn eine Case-Nummer und ein klarer Zweck vorliegen. Bei der Investigation Console darf der Zugriff höchstens 24 Stunden, bei einer Integrations-Appliance höchstens sieben Tage aktiv bleiben. Übermittle Sophos über den vereinbarten Supportkanal ausschliesslich die erzeugte Access ID, niemals das zadmin-Kennwort. Deaktiviere den Zugriff nach Abschluss der Sitzung, auch wenn die gewählte Laufzeit noch nicht abgelaufen ist.

Consolidated Troubleshooting Report unter SFOS 22

Bei Geräte- oder Systemproblemen kann Sophos einen Consolidated Troubleshooting Report (CTR) verlangen. Unter SFOS 22 geht man zu Diagnostics > Tools > Consolidated troubleshooting report, wählt System snapshot und All log files, trägt den konkreten Grund für die Erzeugung ein und klickt auf Generate. Nach Abschluss lädt man den Report über Download herunter. Das Archiv ist verschlüsselt und wird dem bereits eröffneten Support Case hinzugefügt.

Ein solcher Report ist besonders hilfreich bei:

• Dienstabstürzen
• unklaren Systemzuständen
• wiederkehrenden Fehlern nach Updates
• Problemen, die Sophos nicht allein anhand eines Screenshots bewerten kann
• Supportfällen, bei denen mehrere Module betroffen sein könnten

Der Report ersetzt aber keine gute Fehlerbeschreibung. Uhrzeit, Zeitzone, betroffene Funktion und Reproduktionsschritte müssen trotzdem im Ticket stehen. In einem HA-Cluster sind Logs und Reports nicht zwischen Primary und Auxiliary Device synchronisiert. Wenn beide Nodes betroffen sein können, sammelt man den CTR daher auf jedem Node separat.

Support Access und Access ID

Bei Firewall-Fällen kann Sophos nach aktiviertem Support Access und der erzeugten Access ID fragen. Unter SFOS 22 liegt die Funktion unter Diagnostics > Support access. Die Firewall baut dafür über TCP 22 eine Verbindung zu *.apu.sophos.com auf. Ein vorgeschalteter Router muss diese ausgehende Verbindung zulassen. Sophos kann mit der Access ID auf WebAdmin und Shell zugreifen; Admin-Zugangsdaten werden dafür nicht weitergegeben.

Support Access sollte nur für den konkreten Case und die benötigte Dauer aktiviert werden: Support access einschalten, Dauer wählen, mit Apply bestätigen und danach die angezeigte Access ID sicher an Sophos übermitteln. Die Freigabe lässt sich jederzeit ausschalten und sollte nach Abschluss der Analyse deaktiviert werden. Für den praktischen Ablauf passt Sophos Firewall Support Access für Avanet freigeben.

Im Ticket sollte man angeben:

• ob Support Access bereits aktiv ist
• Access ID, falls vorhanden
• wie lange der Zugriff freigegeben wurde
• ob MFA oder ACL-Regeln den Zugriff beeinflussen
• ob es ein Wartungsfenster für Tests gibt

Bei einem Central-Fall wird stattdessen Remote Assistance für den Tenant verwendet. Der Pfad lautet Profil > Support settings. Der Zugriff ist standardmässig ausgeschaltet und kann für 3, 7, 14, 30 oder 60 Tage freigegeben werden. Wird Remote Assistance direkt beim Erstellen eines Central-Supportfalls aktiviert, schaltet Sophos sie nach 120 Stunden automatisch aus.

Die Freigabe erfolgt erst, wenn Case-Nummer, Zweck, verantwortlicher Admin und Laufzeit feststehen. Nach der Analyse wird sie unter Support settings vorzeitig deaktiviert und die Aktivität im Audit Log geprüft. Remote Assistance für den Central-Tenant ist nicht dasselbe wie eine Remote Assistance ID einer Firewall, eines Switches oder einer NDR-Appliance.

Partner Assistance und Enterprise Admin Access sind weitere, anders wirkende Zugriffswege. Die Abgrenzung steht in Sophos Fusion Partner Assistance und Remote Assistance absichern.

Supportfall direkt in Sophos Fusion eröffnen

Dieser Weg ist sinnvoll, wenn man bereits im betroffenen Central-Tenant arbeitet. Er ist vom tenantabhängigen Support-Assistant-EAP und vom Assistant im Support Portal zu unterscheiden.

1. Rechts oben das Help-Symbol öffnen.
2. Im Sophos Help-Menü den Pfeil neben Support center wählen.
3. Create a support case anklicken.
4. Das Formular möglichst präzise ausfüllen. Optional kann man Sophos den direkten Zugriff auf die aktuelle Central-Sitzung erlauben.
5. Mit Send absenden. Die danach angezeigte Case-Nummer notieren und mit OK bestätigen.

Wenn die optionale Freigabe beim Absenden gesetzt ist, aktiviert Sophos damit Remote Assistance. Sie wird nach 120 Stunden automatisch deaktiviert. Soll der Zugriff früher enden, öffnet man rechts oben den Accountnamen und danach Support Settings.

💡 Die erfolgreiche Übermittlung und die Case-Nummer bestätigen die Fallanlage, aber keine feste Antwort- oder Lösungsfrist. Priorität und nächster Kontaktweg richten sich nach Vertrag und tatsächlichem Impact. Critical- und High-Fälle werden telefonisch eingeleitet; bei Critical erstellen eingeloggte Benutzer zusätzlich den Web-Case, notieren die Nummer und rufen dann an.

Supportticket mit dem Sophos Support Assistant eröffnen

Das Sophos Support Portal erreicht man unter:

➜ Sophos Support Portal öffnen

Sophos startete den Assistant-Chat am 3. Juni 2026; er ist 24x7 verfügbar. Mit der tieferen Portal-Integration ab Mitte Juli wurde er zum primären Einstieg für eingeloggte Kunden. Nach der Anmeldung mit der SophosID steht der Assistant im grossen Eingabefeld auf der Startseite und zusätzlich über den schwarzen Assistant-Button unten rechts bereit. Der Menüpunkt Cases bleibt für bestehende Fälle erhalten, ist aber nicht mehr der normale Einstieg in die neue Case-Erstellung.

Den Case im Assistant starten

1. Im Support Portal anmelden.
2. Das grosse Eingabefeld oder den Button Assistant öffnen.
3. Produkt, Problem und Ziel klar benennen. Für einen Produktfehler kann der Einstieg zum Beispiel lauten: I need to open a technical support case for Sophos Firewall.
4. Fehlerbild, Business Impact und bereits ausgeführte Prüfungen ergänzen. Ein Betreff wie IPsec VPN fails after upgrade to SFOS 22.0 on XGS 2100 ist aussagekräftiger als VPN problem. Modell und Version sind Beispielwerte und müssen durch die eigene Umgebung ersetzt werden.
5. Vorgeschlagene Dokumentation und Troubleshooting-Schritte fachlich prüfen. Nicht passende oder riskante Änderungen werden nicht allein aufgrund einer AI-Antwort ausgeführt.
6. Wenn das Problem ungelöst bleibt, ausdrücklich festhalten, dass ein menschlicher Support Engineer und ein Technical Support Case benötigt werden.
7. Die geführten Diagnosefragen beantworten. Der Assistant sammelt die benötigten Angaben; vor dem Absenden prüft man insbesondere Account, Kontakt, Produkt, Lizenz oder Seriennummer, Auswirkung und Beschreibung, soweit diese Felder angezeigt werden.
8. Die Zusammenfassung prüfen und absenden. Erfolgsmerkmal ist die danach angezeigte Case-Nummer.
9. Logs, Screenshots, CTR oder PCAP-Dateien anschliessend im erstellten Case unter Cases > Case-Nummer > Upload a File hinzufügen.

Der genaue Dialog ist dynamisch. Sophos kann zuerst eine Anleitung, eine Lizenzprüfung oder weitere Fragen anbieten, bevor der Case-Pfad erscheint. Das ist noch kein Fehler. Entscheidend ist, dass die eigentliche Störung und ihre Auswirkung klar beschrieben werden und man bei weiterem Analysebedarf die Case-Erstellung bis zur Case-Nummer fortsetzt. Eine bevorzugte Support-Team-Auswahl gibt es nicht mehr; erkennt der Assistant eine unterstützte Sprache, kann er die Übergabe an das passende regionale Team anbieten.

Woran man den erfolgreichen Abschluss erkennt

Eine hilfreiche AI-Antwort oder ein angezeigter KB-Artikel ist noch kein Support Case. Erfolgreich abgeschlossen ist der Vorgang erst, wenn eine Case-Nummer angezeigt beziehungsweise per E-Mail bestätigt wird. Danach lässt sich der Fall unter Cases öffnen, ergänzen und verfolgen. Nicht-AI-Bereiche wie Cases, Accounts, Followed Cases und die normale Wissenssuche bleiben weiterhin verfügbar.

Critical- und High-Fälle erfordern telefonischen Kontakt. Bei einem Critical-Fall erstellen eingeloggte Benutzer zusätzlich den Case, notieren seine Nummer und rufen danach an. Der Assistant ersetzt diesen dringenden menschlichen Kontakt nicht.

Typische Portalfehler sicher beheben

• Anmeldeschleife, leere Seite oder fehlender Assistant: richtige SophosID und Tenant-/Accountkontext prüfen, erforderliche Cookies und Skripte zulassen und den Vorgang in einem aktuellen Browser oder privaten Fenster erneut öffnen. Bei einer möglichen Störung Eingaben lokal ohne Geheimnisse zwischenspeichern; Critical- oder High-Fälle telefonisch weiterführen.
• Produkt, Cases oder Case-Erstellung fehlen: Account- und Asset-Zuordnung, Lizenz-/Supportanspruch und bei Partnern die Kundenzuordnung prüfen. Keine fremde Seriennummer wählen; eine fehlende Zuordnung über den Account- beziehungsweise Customer-Care-Prozess korrigieren lassen.
• Der Assistant liefert nur Artikel: Problem und Business Impact präzisieren und ausdrücklich einen Technical Support Case mit menschlichem Support verlangen. Ohne Case-Nummer ist noch kein Ticket erstellt.
• Upload-Code, CAPTCHA oder SendSafely-Hinweis fehlen: Für die erste Verifizierung die E-Mail-Adresse des angemeldeten Support-Portal-Kontos prüfen und das CAPTCHA abschliessen. Erst wenn Thank you den Erfolg bestätigt, die angezeigte Submission ID notieren und die Case-Seite aktualisieren. Der aktualisierte SendSafely-Hinweis ist nur sichtbar, wenn die angemeldete E-Mail dem Case Contact entspricht. Dateien nicht ersatzweise unverschlüsselt versenden; bei Fehlern Uhrzeit und Screenshot ohne sensible Daten im bestehenden Case dokumentieren.
• Keine Bestätigung nach dem Absenden: zuerst Cases und E-Mail inklusive Spamordner nach der Case-Nummer durchsuchen. Nicht blind erneut absenden. Bleibt der Fall unauffindbar, Support mit Zeitpunkt, Account und Screenshot kontaktieren; bei dringender Auswirkung telefonisch eskalieren.

Was in die Beschreibung gehört

Eine gute Beschreibung ist kurz genug zum Lesen und konkret genug zum Arbeiten.

Praktische Vorlage:

Product:
Serial number:
License number:
Model:
Firmware version:
Support plan:
Impact:
Start time and time zone:
Affected users/sites/services:
Recent changes:
Expected behavior:
Actual behavior:
Steps to reproduce:
Checks already performed:
Support access ID:
Attachments:

Ein ausgefülltes, anpassbares Beispiel könnte so beginnen:

Product: Sophos Firewall
Serial number: [own serial number]
Model: XGS 2100 [replace]
Firmware version: SFOS 22.0 [replace with exact version and build]
Impact: Site-to-site VPN to production is down; 80 users cannot access ERP; no workaround
Start time and time zone: 2026-09-05 08:40 CEST [replace]
Recent changes: Firmware upgrade completed at 07:55 CEST
Expected behavior: IPsec tunnel establishes and production subnet is reachable
Actual behavior: Tunnel remains down; peer is reachable; authentication fails
Steps to reproduce: Disable and re-enable the affected connection once
Checks already performed: Peer reachability, matching proposals, Log Viewer at 08:43 CEST
Support access ID: Not enabled; can be enabled for an agreed window
Attachments: Filtered Log Viewer export and topology diagram; CTR available on request

Die eckigen Hinweise werden ersetzt. Benutzerzahl, ERP und Fehlerbild dienen nur als Muster; Severity und Wortlaut müssen die tatsächliche Auswirkung wiedergeben. Geheimnisse wie Kennwörter, Pre-Shared Keys, private Schlüssel oder Session-Cookies gehören nie in Beschreibung oder Anhang.

Dateien nach der Case-Erstellung hochladen

Der Portal-Upload gehört immer zu einem bestehenden Case. Man meldet sich im Support Portal an, öffnet Cases, klickt die Case-Nummer und dann Upload a File. Beim ersten Upload kann SendSafely die E-Mail-Adresse dieses Support-Portal-Kontos per Code und CAPTCHA verifizieren. Mehrere Dateien, Dateien ohne zugelassene Endung und Dateien über 100 GB müssen als ZIP hochgeladen werden; ausführbare Dateien ebenfalls. Auf öffentlichen oder gemeinsam genutzten Geräten lässt man remember me for 30 days deaktiviert.

Erst die Meldung Thank you bestätigt den erfolgreichen Upload. Die dabei angezeigte Submission ID wird bei Rückfragen notiert. Danach aktualisiert man die Case-Seite; der SendSafely-Hinweis ist nur sichtbar, wenn die E-Mail-Adresse mit dem Case Contact übereinstimmt. Eine hochgeladene Datei kann später nur sehen oder herunterladen, wer zugleich ihr Uploader und der Case Contact ist.

Bei Firewall-Regel-, NAT- oder VPN-Problemen sollte zusätzlich angegeben werden:

• Source- und Destination-Netze
• betroffener Service oder Port
• erwartete Firewall-Regel
• NAT-Regel, falls beteiligt
• VPN-Tunnel oder Remote-Access-Profil
• Log Viewer Ergebnis
• Packet Capture oder tcpdump-PCAP, falls der Paketfluss relevant ist
• Support Access ID, falls Sophos Remote-Zugriff benötigt

Für Regelanalysen kann Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture helfen, bevor der Support Case eröffnet wird.

RMA und Hardwaredefekt

Bei Hardwaredefekten braucht Sophos zusätzlich Informationen für die RMA-Abwicklung. Dazu gehören nicht nur Fehlerbeschreibung und Seriennummer, sondern auch Modell, Revision, Firmware, Lizenz, HA-Status und Versandinformationen.

Vorbereiten sollte man:

• defektes Produkt und Modell
• Seriennummer des betroffenen Geräts
• Firmwareversion
• Lizenznummer oder Lizenzzuordnung
• Fehlerbild und bereits geprüfte Punkte
• Dead on arrival, falls das Gerät direkt nach Lieferung betroffen ist
• HA-Cluster: ja oder nein
• Lieferadresse und Kontaktperson
• Telefonnummer und E-Mail-Adresse
• besondere Versandhinweise

Bei Firewalls sollte zusätzlich geprüft werden, ob ein aktuelles Backup vorhanden ist und wie die Ersatz-Firewall wiederhergestellt wird. Für Backup und Restore passt Backup und Restore auf Sophos Firewall.

Für RMA-Fälle werden die verlangten Angaben über das aktuelle Sophos Support Portal bereitgestellt und die Anweisungen im Ticket befolgt. Zusätzlich angeforderte Geräte-, Lizenz- oder Versanddaten ergänzt man direkt im betreffenden Case.

Nachfassen und Eskalieren

Nach dem Eröffnen sollte eine Bestätigung mit Case-Nummer per E-Mail eintreffen. Diese Nummer gehört in jede spätere Kommunikation. Unter Cases lässt sich der Fall öffnen, mit weiteren Angaben ergänzen und verfolgen.

Wenn ein kritischer Fall nicht schnell genug vorankommt, sollte man nicht ein zweites Ticket eröffnen. Doppelte Tickets erzeugen mehr Koordinationsaufwand und können die Bearbeitung eher verlangsamen.

Besser ist:

1. bestehende Ticketnummer bereithalten
2. Impact und Dringlichkeit konkret beschreiben
3. fehlende Logs oder Antworten nachreichen
4. bei kritischen Fällen telefonisch mit Case-Nummer nachfassen
5. im bestehenden Case Request Escalation wählen, Region und begründeten Business Impact eintragen und mit Escalate absenden
6. intern dokumentieren, wer welche Rückmeldung gegeben hat

Eine Eskalation sollte begründet sein. Sinnvolle Gründe sind zum Beispiel:

• Zielantwortzeit wurde überschritten.
• Produktiver Ausfall dauert weiter an.
• Keine Reaktion trotz nachgereichter Informationen.
• Falsche Zuordnung oder unpassende Produktkategorie.
• Case blockiert einen geplanten Wiederherstellungs- oder Wartungsprozess.

Die Eskalation sollte immer den aktuellen Business Impact beschreiben. Ein Satz wie We need an update ist schwächer als eine konkrete Aussage wie The main site-to-site VPN between headquarters and production is still down, 80 users cannot access ERP, no workaround is available. Alternativ akzeptiert Sophos eine E-Mail an supportescalations@sophos.com mit Case-Nummer, ausdrücklichem Eskalationswunsch, Grund und Business Impact. Für zeitkritische Fälle empfiehlt Sophos zusätzlich den Telefonkontakt.

Bei schwerwiegenden Security- oder Ausfallfällen sollte zusätzlich geprüft werden, ob andere Support- oder Incident-Response-Prozesse greifen. Ein normales technisches Ticket ist nicht automatisch ein vollständiger Incident-Response-Prozess.

Checkliste

• SophosID funktioniert.
• Lizenz- und Supportanspruch sind geklärt.
• Seriennummer, Modell und Firmwareversion sind dokumentiert.
• Fehlerzeitpunkt mit Zeitzone ist bekannt.
• Auswirkung auf Benutzer, Dienste oder Standort ist beschrieben.
• Letzte Änderungen wurden notiert.
• Reproduktion oder Fehlerbild ist nachvollziehbar.
• Relevante Logs und Screenshots sind vorbereitet.
• Packet Capture oder tcpdump-PCAP ist nur bei Paketflussproblemen vorbereitet.
• Vertrauliche Daten in Anhängen wurden geprüft.
• Bei RMA: Versandinformationen und HA-Status sind vorbereitet.
• Case-Erstellung über den gewählten Weg bis zur bestätigten Case-Nummer abgeschlossen.
• Ticketnummer wird intern dokumentiert.

FAQ