Sophos Endpoint mit Self Help und SDU diagnostizieren

Ein Endpoint-Problem wird nicht durch wahlloses Neuinstallieren gelöst. Zuerst wird eingegrenzt, ob Schutzkomponenten, Central-Kommunikation, Update, Policy, Betriebssystem oder Netzwerk betroffen sind. Endpoint Self Help liefert dafür lokale Zustände und erste Ursachen. Die Sophos Diagnostic Utility, kurz SDU, sammelt anschliessend die technischen Protokolle.

Der vollständige Weg von der Planung bis zur Betriebsübergabe ist im Endpoint-Onboarding-Pfad beschrieben.

Schnellablauf für eine belastbare Diagnose

1. Symptom, Auswirkung, Fehlerzeitpunkt mit Zeitzone und einen reproduzierbaren Test notieren.
2. Endpoint Self Help öffnen und den betroffenen Bereich sowie Network Test prüfen.
3. Nur die zum Fehler passende Zusatzdiagnose aktivieren und das Problem im vereinbarten Zeitfenster reproduzieren.
4. Debug-Logging oder Packet Capture danach zurücksetzen beziehungsweise stoppen und SDU aus demselben Zeitfenster sammeln.
5. Supportpaket geschützt übertragen und zusammen mit der eigenen Loganalyse und dem angezeigten SDU-Dateinamen dem Case zuordnen.

So bleiben Statusprüfung, Reproduktion und Beweissammlung zeitlich zusammenhängend. Reparaturen oder breite Ausnahmen beginnen erst, wenn die Beobachtung gesichert ist.

Vor der Logsammlung

Vor jeder Diagnose werden die sichtbaren Symptome dokumentiert:

• betroffener Computer, Betriebssystem und Zeitpunkt,
• lokale Fehlermeldung oder Screenshot,
• Central Health, Last Active, Agent Mode und wirksame Policies,
• letzte Installation, Aktualisierung oder Policy-Änderung,
• reproduzierbarer Test und erwartetes Verhalten.

Diese Angaben sind oft wichtiger als ein sehr grosses Logarchiv ohne Zeitbezug.

Endpoint Self Help öffnen

ESH unterstützt Sophos Fusion (ehemals Sophos Central) Windows Endpoint und Windows Server. Es wird über About > Open Endpoint Self Help Tool oder direkt aus C:\Program Files\Sophos\Endpoint Self Help geöffnet. Sichtbare Seiten hängen von Lizenz, installierten Komponenten und Agent-/Plattformgeneration ab; Legacy-Windows zeigt weniger Status und Funktionen.

Auf modernen Plattformen schliesst ESH ab Core Agent 2024.2 nach zwei Stunden ohne Interaktion und warnt fünf Minuten vorher. Ab 2024.3 prüft es beim Start automatisch Known Issues. Aktuelle Agents trennen System, Services und Update; ältere Stände können Ansichten gruppieren oder auslassen. Deshalb gehört die Agentversion zu jedem Screenshot.

Self Help eignet sich für Fragen wie:

• Läuft die erwartete Komponente?
• Ist ein Dienst gestoppt oder fehlerhaft?
• Erreicht der Agent Central und die Update-Infrastruktur?
• Gibt es einen bekannten lokalen Konfigurations- oder Berechtigungsfehler?

Ein roter Check wird mit Name, Status, Detailtext und Zeitpunkt dokumentiert. Vor einer Reparatur wird geprüft, ob die Ursache durch eine zentrale Policy oder eine Netzwerksperre erneut erzeugt würde.

Stürzt SophosDiag.exe bereits beim Öffnen ab und nennt das Windows Application Event Log eine beschädigte benutzerspezifische user.config, wird nur die im Fehler angegebene Datei unter dem betreffenden Benutzerprofil entfernt. Der versionsabhängige übergeordnete Ordner wird nicht als fixer Pfad automatisiert gelöscht. Danach wird Self Help erneut geöffnet; bleibt der Fehler bestehen, folgt SDU beziehungsweise eine Reparatur der installierten Komponente.

Self-Help-Seiten gezielt verwenden

Die einzelnen Seiten beantworten unterschiedliche Fragen. Sie werden nicht als allgemeine Ampel gelesen:

Ein Policy-Update kann bis zu fünf Minuten benötigen. Ist Override Sophos Central Policy for up to 4 hours lokal aktiv, werden neue Central-Policies zwischengespeichert und erst nach Ende des Overrides angewendet. Eine alte Policy-Zeit ist dann kein Kommunikationsbeweis.

Unter Components werden installierte, heruntergeladene und erwartete Modulversionen verglichen. Not installed, unterschiedliche Download- und Installationsstände oder mehrere Versionen werden zuerst gegen Updatezustand, ausstehenden Neustart und ein konkurrierendes Sicherheitsprodukt geprüft. Das lokale Repository wird nicht vorsorglich gelöscht. Unter System kann ein weiterhin gemeldeter Pending Restart aus Windows Update stammen; nach einer Änderung an Hardware oder Sicherheitssoftware lässt sich der Softwarestand mit der Endpoint-CLI gezielt neu einlesen, bevor eine Reparatur gestartet wird.

Im Normalfall kommen Central-Aktionen innerhalb weniger Sekunden bis Minuten an. Last Active wird dagegen höchstens ungefähr stündlich aktualisiert. Bei einer Benutzer-Policy kann der Wechsel länger dauern, weil Central-Benutzer, lokal angemeldetes Konto und die vom MCS Client erkannte interaktive Sitzung zuerst übereinstimmen müssen.

Network Test richtig interpretieren

Der Network Test prüft die Kanäle Updating, Management Communication und Sophos Extensible List (SXL). Pro Ziel versucht das Werkzeug zuerst HTTPS, danach je nach Ergebnis ICMP und DNS-Auflösung. Für die Funktion ist eine erfolgreiche HTTPS-Verbindung entscheidend. Ein Ping oder nslookup allein beweist deshalb keine funktionierende Central-Kommunikation.

Er ist die erste Prüfung bei schlechtem Update- oder Communication-Status, offline wirkendem Live Discover/Response sowie Problemen mit Real-Time Scanning, Web Control oder SXL. Er zeigt die fehlerhafte Stufe, ermittelt aber nicht selbst die Ursache in Firewall, Proxy oder DNS. Auf Windows 7/8/8.1 und Server 2008 R2/2012 kann der HTTPS-Test zu sdds3.sophosupd.net wegen fehlender Cipher Suites des Betriebssystems scheitern.

Bei einem Update Cache oder Message Relay prüft Self Help nur die DNS-Auflösung des zugewiesenen Servers. Ein grüner DNS-Test bestätigt weder Dienstzustand noch Port noch Weiterleitung. Die eigentliche Cache- oder Relay-Funktion wird separat kontrolliert.

Zwei Grenzen sind besonders wichtig:

• Nach einer geänderten Cache- oder Relay-Zuweisung muss Endpoint Self Help geschlossen und neu geöffnet werden, sonst kann der Network Test noch das alte Ziel verwenden.
• Authentifizierte Proxies werden vom Network Test nicht unterstützt und können irreführende Resultate erzeugen.

SXL-Tests benötigen eine administrative UAC-Erhöhung. Verwendet das Gerät ein Message Relay, führt Self Help den SXL-Test nicht direkt aus, weil dieser Verkehr über das Relay läuft.

Bleibt die Kommunikation fehlerhaft, werden die von Self Help angezeigten Brokeradressen mit der lokalen MCS-Konfiguration verglichen. Zusätzlich werden Routing, Windows-Hosts-Datei, Proxy und Firewall-Log geprüft. Nach einer Korrektur kann der Sophos MCS Client neu gestartet und Self Help aktualisiert werden. Ein Browserzugriff auf Central ersetzt diese Prüfung nicht.

Updatefehler ohne vorschnelle Cache-Löschung

Ein fehlgeschlagenes Update innerhalb der Sophos-Grace-Period kann vorübergehend sein. Zuerst werden Update Now, Netzwerk, Proxy, Updatequelle und Zeit des letzten erfolgreichen Updates geprüft. Erst wenn diese Prüfungen keine Ursache zeigen, kommt das von Sophos dokumentierte Zurücksetzen des lokalen AutoUpdate-Caches infrage.

Bei einem reproduzierbaren Fehler wird SophosUpdate.log mit einer zeitgleichen Paketaufzeichnung sowie Firewall- oder Proxy-Logs korreliert. Entscheidend sind DNS-Antwort, tatsächlich kontaktierter Updateserver, direkter oder proxied Pfad und der erste HTTP- beziehungsweise TLS-Fehler. Die wichtigsten Windows-Logpfade stehen unter Sophos Endpoint Windows-Logs und Dienste richtig auswerten.

Dieser Eingriff benötigt deaktivierten Tamper Protection, Administratorrechte und erzeugt einen Pending-Restart-Alert. Die Cache- und Repository-Ordner werden gesichert beziehungsweise umbenannt, nicht ungeprüft gelöscht. Danach muss ein vollständiges Update erfolgreich sein und Self Help nach Refresh wieder einen gesunden Zustand zeigen.

Performance Analysis

Seit Core Agent 2024.3 kann ESH auf Windows 10 x64 oder neuer und Windows Server 2016 oder neuer Scanner-Zusammenfassungen laden. Als Eingabe dienen Ergebnisse eines Product-Analysis-Ablaufs oder Dateien, die über SFS > Scan Summaries im Product Logging erzeugt wurden; sie dürfen von diesem oder einem anderen ESH-Gerät stammen. Die CSV-Dateien liegen standardmässig unter:

C:\ProgramData\Sophos\Sophos File Scanner\Logs\summary.<TIMESTAMP>.csv

Sie können auf einem anderen Gerät mit Endpoint Self Help analysiert werden. Die Datei zeigt, welche Prozesse und Pfade während des protokollierten Zeitfensters Scanlast erzeugten. Daraus entsteht noch keine pauschale Ausnahme. Erst werden Anwendung, Zugriffsmuster und engster technisch sinnvoller Ausschluss geprüft.

Bei der Auswertung werden zuerst Ordner mit langer kumulierter Scanzeit, danach besonders häufig geprüfte Pfade und schliesslich grosse Datenmengen verglichen. Ein häufig gescannter Pfad muss nicht derselbe sein wie der Pfad mit der höchsten Gesamtdauer. Warnt Self Help vor einer zu breiten Ausnahme, darf diese höchstens kurz zur Ursachenbestätigung dienen. Als dauerhafte Lösung wird sie auf den tatsächlich belastenden Unterordner oder Prozess eingegrenzt.

Product Analysis geht einen Schritt weiter und schaltet Schutzfunktionen geführt aus und wieder ein, um die beteiligte Komponente einzugrenzen. Dafür sind Administratorrechte und bei aktivem Manipulationsschutz das Tamper-Protection-Kennwort erforderlich. Der Ablauf gehört auf ein kontrolliertes Testgerät oder in ein Wartungsfenster: Schutzstatus und Updatezustand werden vor Beginn dokumentiert, das Ergebnis gespeichert und anschliessend alle Funktionen sowie Updates wieder auf den Ausgangszustand gesetzt. Das Werkzeug liefert eine Hypothese, aber keine automatische Freigabe für eine Ausnahme.

File Info statt Bauchgefühl

Unter Tools > File Info lässt sich eine Windows-PE-Datei lokal bewerten. Self Help zeigt SHA-256, Grösse, Application-Control-Kategorie und Produktname sowie die resultierende Policy-Entscheidung. Local Reputation berücksichtigt Sophos-Daten und kundeneigene Allowed Applications beziehungsweise Blocked Items. Sie kann deshalb von der live abgefragten Global Reputation abweichen und diese für die lokale Entscheidung übersteuern.

Der Deep-Learning-Bereich benötigt eine passende Intercept-X-Lizenz. Ein grünes Ergebnis beweist nicht, dass eine bereits erkannte Malware harmlos ist: Erkannte Malware- oder PUA-Dateien lassen sich normalerweise gar nicht in die Seite ziehen. Für eine Fehlklassifizierung werden Hash, Signatur, lokaler und globaler Lookup-Typ sowie der konkrete Policy-Entscheid gesichert und danach der dokumentierte Sample-Submission-Prozess verwendet.

Für Windows-PE-Dateien liefert File Info die vollständigsten Daten; andere Dateitypen nur eingeschränkte Angaben. Nach Run as administrator kann Windows Drag-and-drop aus einem Prozess mit tieferen Rechten blockieren; dann wird browse for a file verwendet. Reputation und Policy-Resultat sind keine Integritätsgarantie. Wo Vertrauen entscheidend ist, folgt die freigegebene Sample-Analyse.

Policy-, Service- und Operations-Status vertiefen

Zeigt die Policy-Seite veraltete Zeitstempel, wird zwischen Empfang und lokaler Verarbeitung unterschieden. McsClient.log wird auf Verbindungs- und Backoff-Einträge geprüft, McsAgent.log auf Policy-, Namespace- und Statusfehler. In der MCS-Cache-Struktur zeigen Active.policy und Latest.policy, ob eine neue Policy angekommen ist, aber lokal noch nicht aktiv wurde. Dienste werden erst nach Sicherung der Beobachtung neu gestartet; danach muss das Log den erfolgreichen Übergang bestätigen.

Auf der Operations-Seite ist nicht jedes blaue oder leere Symbol ein Fehler. Eine deaktivierte Data-Lake-Funktion, ein bewusst ausgeschlossenes Gerät oder ein erreichtes tägliches Uploadlimit werden von einem tatsächlich fehlerhaften Live-Query-Dienst unterschieden. Bei schlechtem Data-Lake-Status werden zuerst SophosLiveQueryService.log, SophosOsquery.log und der Dienstzustand geprüft.

Der Heartbeat-Abschnitt zeigt Bereitschaft, Zertifikatszustand und eine bestehende Verbindung zu einer Sophos Firewall. Ein Eintrag configured, no connection currently available beweist allein keinen Endpoint-Fehler, und der Heartbeat-Status fliesst nicht in den allgemeinen Device Health ein. Wird eine Verbindung erwartet, werden Endpoint- und Firewall-Logs anhand von Zeitpunkt und Device ID korreliert. Registry- oder Zertifikatsreparaturen aus Advanced Self Help erfolgen nur mit Export beziehungsweise Backup, deaktiviertem Tamper Protection und einem dokumentierten Rückweg.

SDU über die Oberfläche starten

In ESH wird Launch SDU geöffnet, die EULA akzeptiert und Start gewählt. Danach zeigt View log die Sammlung, Open folder öffnet sdu.log und Archive, und Submit bietet Upload oder manuelle Fallübermittlung. Unter Windows speichert sducli.exe ohne Sammeloptionen nach C:\WINDOWS\Temp\sdu-YYYYMMDD_xxxxxx_xxxxxx. Für Upload to Sophos muss sdu-feedback.sophos.com über TCP 443 erreichbar sein. Die absichtlich nicht aufrufbare Upload-URL wird in den Fall kopiert und ist am Ende von sdu.log wiederzufinden.

Das Archiv kann Hostnamen, Benutzernamen, Pfade, IP-Adressen, Prozesslisten, Konfigurationen und Ereignisse enthalten. Es gehört deshalb nicht in öffentliche Tickets, ungeschützte Fileshares oder Chatverläufe.

Ein Windows-, macOS- oder Linux-Gerät lässt sich auch aus Central diagnostizieren: My Environment > Computers & Servers, Gerät wählen, danach auf Summary > More actions > Diagnose > Run. Das SDU-Feld zeigt Status, Last Run und File Name; der Dateiname gehört in den Supportfall. Der Upload nutzt HTTPS 443 über den normalen freigegebenen Sophos-Domainpfad. Aktion und Administrator stehen unter Reports > General Logs > Audit Logs.

Ist das Gerät offline, hält Central den Auftrag höchstens 14 Tage vor. Danach wird er verworfen und muss neu ausgelöst werden. Der Befehl startet bei der nächsten Central-Kommunikation, daher werden Zeitpunkt, Datenschutzfreigabe und erwartete Gerätekonnektivität vor dem Auslösen geklärt.

Product Logging und Packet Capture

Product Logging benötigt UAC-Erhöhung. Eine Parent-Einstellung gilt für alle Children; ein Stern am Parent kennzeichnet nur auf Child-Ebene abweichende Werte. Save wendet ausstehende Level an, Revert… verwirft sie nur vor dem Speichern. Ein bereits angewendeter Level wird mit Default am geänderten Parent/Child und anschliessendem Save zurückgesetzt. Beim Schliessen setzt Revert to Default zurück, Just Close lässt Debug-Logging aktiv. ESH-Schliessen allein stoppt es also nicht.

Die Paketaufzeichnung verwendet Windows pktmon, benötigt UAC-Erhöhung und fehlt vor Windows 10 1809 sowie auf Windows Server 2016 oder älter. Das Limit ist standardmässig 512 MB und von 1 bis 9999 MB einstellbar; Windows-10-Builds vor 2004 bleiben bei 512 MB. Jeder Lauf erzeugt capture-<date><time>.etl und capture-<date><time>.pcapng unter C:\ProgramData\Sophos\Endpoint Self Help\PacketCapture; beide werden übermittelt. ESH-Schliessen stoppt die Aufzeichnung. Dateien werden nicht automatisch bereinigt und sind nach der freigegebenen Aufbewahrungsfrist manuell zu löschen.

Kann Self Help weder Logging noch Paketaufzeichnung oder SDU erhöhen, werden zuerst die Windows-UAC-Einstellungen geprüft. Insbesondere vollständig deaktiviertes UAC oder unterdrückte Elevation-Prompts können die Funktion blockieren. Microsoft-Standardwerte wiederherzustellen ist sauberer als Sophos-Werkzeuge dauerhaft über das integrierte Administratorkonto zu starten.

SDU unter Windows per Kommandozeile

Die Windows-Version liegt normalerweise unter:

C:\Program Files\Sophos\Sophos Diagnostic Utility\sducli.exe

Eine administrative Eingabeaufforderung liefert mit folgendem Aufruf die integrierte Hilfe:

& "C:\Program Files\Sophos\Sophos Diagnostic Utility\sducli.exe" -help

Wichtige Parameter sind:

Die lokal installierte -help-Ausgabe ist für die vorhandene Agentversion massgebend. Automatisierte Sammlungen werden mit Speicherlimit, sicherem Ziel und Löschfrist versehen.

SDU unter macOS per Kommandozeile

Auf einem Mac wird SDU aus dem Programmpaket gestartet:

/Library/Sophos\ Anti-Virus/Tools/Sophos\ Diagnostic\ Utility.app/Contents/MacOS/Sophos\ Diagnostic\ Utility --help

--help zeigt nur die verfügbaren Befehle und sammelt keine Diagnosedaten. Der ausführbare Sammelbefehl lautet:

/Library/Sophos\ Anti-Virus/Tools/Sophos\ Diagnostic\ Utility.app/Contents/MacOS/Sophos\ Diagnostic\ Utility --cli

--output_path="<path>" setzt den Ausgabeordner, sonst gilt das aktuelle Verzeichnis. Diese Optionen gelten ab macOS Agent 2026.1. Der Prozess benötigt die Berechtigungen für die zu sammelnden Daten; Full Disk Access und System Extension werden separat geprüft.

SDU unter Linux per Kommandozeile

Auf einem durch Sophos Protection for Linux geschützten Gerät wird das installierte Diagnosewerkzeug so gestartet:

/opt/sophos-spl/bin/sophos_diagnose

Es erstellt ein tar.gz-Archiv im aktuellen Arbeitsverzeichnis und sammelt Logs des SPL Agent, aller Plugins sowie das Audit Log. Für einen kontrollierten Ausgabeordner wird ein privates Verzeichnis angelegt und als erstes Positionsargument übergeben:

mkdir -p "$HOME/sophos-sdu"
chmod 700 "$HOME/sophos-sdu"
/opt/sophos-spl/bin/sophos_diagnose "$HOME/sophos-sdu"

Das letzte Argument ist ein Verzeichnis, kein Archivname; das erzeugte tar.gz wird darin abgelegt. Damit bleibt die Herstellersyntax erhalten, ohne einen gemeinsam genutzten temporären Ordner zu verwenden.

Forensikmodus richtig einordnen

SDU kann spezielle Forensik-Logs erzeugen. Dieser Modus ist für Sophos Incident Response beziehungsweise eine gezielte forensische Untersuchung vorgesehen. Er ist kein Ersatz für einen vollständigen Enterprise-Forensikprozess und sollte nicht ohne definierten Auftrag dauerhaft aktiviert werden.

Bei einer möglichen Kompromittierung gelten zusätzliche Regeln:

• Gerät nicht vorschnell neu starten oder bereinigen,
• Zeitquelle und Zeitzone dokumentieren,
• Beweisdaten nur auf ein kontrolliertes Ziel schreiben,
• Hash, Übergabe und Zugriff auf das Archiv protokollieren,
• Incident-Response-Verantwortliche einbeziehen.

Konfiguration und Softwarestatus per CLI ausgeben

Die lokale Endpoint-CLI kann Policy- und Softwarezustände ausgeben. Output configuration zeigt, welche Einstellungen am Gerät angekommen sind. Software Monitor liefert Zustände installierter Komponenten und kann deren Status aktualisieren.

Diese Ausgaben helfen bei drei typischen Widersprüchen:

1. Central zeigt eine Policy als zugewiesen, lokal fehlt die Einstellung.
2. Agent Mode ist korrekt, aber eine Komponente ist nicht installiert oder nicht gesund.
3. Ein Update wurde angekündigt, Software Monitor bleibt jedoch in einem fehlerhaften Zustand.

Die lokal verfügbare Hilfe wird vor der Verwendung geprüft, weil Befehle und Parameter vom installierten Agentstand abhängen können.

Logs zielgerichtet auswerten

Nicht jedes Log wird vollständig gelesen. Man beginnt mit einem engen Zeitfenster und sucht nach dem ersten Fehler, nicht nur nach Folgefehlern. Besonders nützlich sind:

• Installer- und Update-Logs bei Rolloutproblemen,
• MCS- beziehungsweise Management-Kommunikation bei fehlendem Central-Kontakt,
• Health- und Komponentenlogs bei rotem Status,
• Web-, DLP-, Application- oder Peripheral-Ereignisse bei Policy-Problemen,
• Betriebssystem-Eventlogs rund um Dienststarts, Treiber und Zertifikate.

Ein einzelnes error ist noch keine Ursache. Zeitliche Korrelation, Komponente und reproduzierbares Verhalten entscheiden.

Supportpaket vorbereiten

Ein gutes Supportpaket enthält:

1. kurze Problembeschreibung und Auswirkung,
2. exakten Zeitpunkt mit Zeitzone,
3. betroffene und nicht betroffene Vergleichsgeräte,
4. Schritte zur Reproduktion,
5. relevante Central-Screenshots ohne Geheimnisse,
6. SDU-Archiv und gegebenenfalls Installer-Logs,
7. bereits getestete Massnahmen und deren Ergebnis.

Tamper-Protection-Kennwörter, API-Secrets, Proxy-Kennwörter und Installer-Tokens werden niemals in Klartext beigefügt.

Minimum Escalation Requirements erfüllen

Sophos hat die Windows-Endpoint-Anforderungen für Supporteskalationen nach Fehlerklasse aufgeteilt. Ein SDU ohne eigene Analyse erfüllt diese Minimum Escalation Requirements, kurz MER, nicht.

Für jeden Fall werden zuerst Plattform und Produktversion, betroffene Komponente, Umfang, Häufigkeit, Reproduzierbarkeit, Änderungen vor dem Auftreten sowie exakte Fehlermeldungen erfasst. Die Logs müssen vollständig sein, den Fehlerzeitpunkt enthalten und bei Client-Server-Problemen zeitlich zusammenpassen.

Danach kommen szenariospezifische Daten hinzu:

Bei einem Performancefall wird zuerst unterschieden, ob SophosFileScanner.exe, SEDService.exe, SSPService.exe, ein anderer Sophos-Prozess oder die allgemeine Systemlast auffällig ist. Ein global deaktivierter Schutz liefert ohne zeitgleiche Messung und genaue Komponentenzuordnung keine belastbare Ursache.

Zusätzlich wird unter Account Preferences > Evaluation Modes geprüft, ob Aggressive threat detection aktiviert ist. Diese Support- und SophosLabs-Diagnoseoption erhöht die Systemlast deutlich und ist keine produktive Sicherheitsbaseline. Ist sie aktiv, wird der Auftrag dazu dokumentiert und die Option nach der vorgesehenen Messung wieder deaktiviert. Bleibt das Problem danach bestehen, wird es als eigener Performancefall mit neuem Zeitfenster weiter untersucht.

Bei Exploit-, Ransomware- oder HitmanPro.Alert-Fällen wird zusätzlich geprüft, ob Sophos bereits eine Endpoint Maintenance Release mit einem passenden Bugfix anbietet. Ein Crashdump oder vollständiger Memory Dump wird nach der reproduzierten Störung und vor dem SDU erzeugt, damit die Artefakte aus demselben Zeitfenster stammen. Schutz-DLLs oder Treiber werden nicht ohne aktuelles Sophos-Runbook umbenannt.

Ein Supportfall enthält nicht nur die gesammelten Dateien, sondern auch das Ergebnis der eigenen Prüfung: Welches Log zeigt den ersten relevanten Fehler, zu welcher Uhrzeit und welche Hypothese wurde damit bestätigt oder verworfen?

Häufige Fragen