Diagnostiquer Sophos Endpoint avec Self Help et SDU

Un problème Endpoint ne se résout pas par des réinstallations aléatoires. Il faut d’abord déterminer si les composants de protection, la communication Central, Update, Policy, le système d’exploitation ou le réseau sont concernés. Endpoint Self Help fournit les états locaux et les premières causes. Sophos Diagnostic Utility, ou SDU, collecte ensuite les journaux techniques.

Le parcours d’onboarding Endpoint décrit le déploiement complet, de la planification au transfert vers l’exploitation.

Parcours rapide pour un diagnostic fiable

1. Noter le symptôme, l’impact, l’heure de l’erreur avec le fuseau et un test reproductible.
2. Ouvrir Endpoint Self Help et contrôler la zone concernée ainsi que Network Test.
3. Activer uniquement le diagnostic complémentaire adapté et reproduire l’erreur dans la période convenue.
4. Rétablir ou arrêter ensuite Debug Logging et Packet Capture, puis collecter un SDU couvrant la même période.
5. Transmettre le paquet de façon sécurisée et l’associer au dossier avec l’analyse interne et le nom de fichier SDU affiché.

Le contrôle d’état, la reproduction et la collecte restent ainsi alignés dans le temps. Ne commencer aucune réparation ni exclusion large avant d’avoir conservé l’observation.

Avant la collecte des Logs

Avant tout diagnostic, les symptômes visibles sont documentés :

• ordinateur concerné, système d’exploitation et heure,
• message d’erreur local ou Screenshot,
• Central Health, Last Active, Agent Mode et Policies effectives,
• dernière installation, mise à jour ou modification de Policy,
• test reproductible et comportement attendu.

Ces informations sont souvent plus utiles qu’une archive de Logs très volumineuse sans repère temporel.

Ouvrir Endpoint Self Help

ESH prend en charge Windows Endpoint et Windows Server administrés dans Sophos Fusion (anciennement Sophos Central). Dans l’interface Sophos Endpoint locale, sélectionner About en bas à droite, puis Open Endpoint Self Help Tool, ou ouvrir directement l’outil depuis C:\Program Files\Sophos\Endpoint Self Help. L’outil affiche l’état des principaux composants, de la communication et des services de protection. Les pages visibles dépendent de la licence, des composants installés et de la génération de l’agent et de la plateforme ; les anciennes versions de Windows affichent moins d’états et de fonctions.

Avec Core Agent 2026.3.0.2090, Endpoint UI et Self Help sont réunis dans un composant Sophos Endpoint UI sur Windows 10 64-bit et versions ultérieures. Les notes de version situent cette version en octobre 2026 et indiquent un déploiement progressif. Avant de réparer un composant, vérifier donc les versions de l’agent et des composants réellement installées : à partir de cette génération, l’absence d’un package Self Help distinct ne prouve pas à elle seule un défaut d’installation. Cette fusion ne démontre pas un changement du chemin de lancement décrit ci-dessus ; vérifier le point d’entrée disponible dans le package installé plutôt que de supposer un nouveau chemin de menu. État de la vérification : 24 octobre 2026.

Sur les plateformes modernes, à partir de Core Agent 2024.2, ESH se ferme après deux heures sans interaction et avertit l’utilisateur cinq minutes auparavant. À partir de 2024.3, il vérifie automatiquement les problèmes connus au démarrage. Les agents actuels distinguent System, Services et Update ; les anciennes versions peuvent regrouper ou omettre certaines vues. La version de l’agent doit donc accompagner chaque capture d’écran.

Self Help répond notamment aux questions suivantes :

• Le composant attendu fonctionne-t-il ?
• Un service est-il arrêté ou défectueux ?
• L’Agent joint-il Central et l’infrastructure Update ?
• Existe-t-il une erreur locale connue de configuration ou d’autorisation ?

Pour chaque contrôle rouge, le nom, le statut, le texte détaillé et l’heure sont consignés. Avant une réparation, il faut vérifier si une Central Policy ou un blocage réseau recréerait la cause.

Si SophosDiag.exe plante dès son ouverture et que le journal Application de Windows signale un user.config propre à l’utilisateur comme endommagé, supprimez uniquement le fichier indiqué dans l’erreur sous le profil concerné. N’automatisez pas la suppression du dossier parent, dont le chemin dépend de la version. Rouvrez ensuite Self Help. Si l’erreur persiste, collectez un SDU ou réparez le composant installé.

Utiliser les pages Self Help de manière ciblée

Chaque page répond à une question différente. Elles ne doivent pas être lues comme un indicateur global :

Un Policy Update peut demander jusqu’à cinq minutes. Si Override Sophos Central Policy for up to 4 hours est activé localement, les nouvelles Central Policies sont mises en cache et ne sont appliquées qu’à la fin de l’Override. Une ancienne heure de Policy ne prouve alors pas une erreur de communication.

Sous Components, comparez les versions de modules installées, téléchargées et attendues. Vérifiez d’abord Not installed, les différences entre téléchargement et installation ou la présence de plusieurs versions par rapport à l’état Update, à un redémarrage en attente et à un produit de sécurité concurrent. Ne supprimez pas le Repository local par précaution. Sous System, un Pending Restart persistant peut venir de Windows Update. Après une modification matérielle ou logicielle de sécurité, relancez l’inventaire logiciel avec la CLI Endpoint avant de démarrer une réparation.

En fonctionnement normal, les actions Central arrivent en quelques secondes ou minutes. Last Active n’est en revanche actualisé qu’environ une fois par heure au maximum. Pour une User Policy, le changement peut prendre plus de temps, car l’utilisateur Central, le compte connecté localement et la session interactive reconnue par le MCS Client doivent d’abord correspondre.

Interpréter correctement Network Test

Network Test vérifie les canaux Updating, Management Communication et Sophos Extensible List (SXL). Pour chaque cible, l’outil tente d’abord HTTPS, puis selon le résultat ICMP et la résolution DNS. Une connexion HTTPS réussie est déterminante pour le fonctionnement. Un Ping ou nslookup seul ne prouve donc pas que la communication Central fonctionne.

Ce test est le premier contrôle en cas de mauvais état Update ou Communication, de Live Discover ou Live Response semblant hors ligne, ou de problèmes avec Real-Time Scanning, Web Control ou SXL. Il indique l’étape en échec, mais ne détermine pas lui-même la cause dans le pare-feu, le proxy ou le DNS. Sous Windows 7/8/8.1 et Server 2008 R2/2012, le test HTTPS vers sdds3.sophosupd.net peut échouer parce que le système d’exploitation ne dispose pas des suites cryptographiques nécessaires.

Avec un Update Cache ou un Message Relay, Self Help vérifie uniquement la résolution DNS du serveur attribué. Un test DNS vert ne confirme ni l’état du service, ni le port, ni la transmission. Le fonctionnement réel du Cache ou du Relay est contrôlé séparément.

Deux limites sont particulièrement importantes :

• après une modification de l’attribution Cache ou Relay, Endpoint Self Help doit être fermé puis rouvert, sinon Network Test peut encore utiliser l’ancienne cible,
• les Proxies authentifiés ne sont pas pris en charge par Network Test et peuvent produire des résultats trompeurs.

Les tests SXL nécessitent une élévation UAC administrative. Si l’appareil utilise un Message Relay, Self Help n’exécute pas directement le test SXL, car ce trafic passe par le Relay.

Si la communication reste défaillante, les Broker Addresses affichées par Self Help sont comparées à la configuration MCS locale. Le Routing, le fichier Hosts Windows, le Proxy et le Firewall Log sont également vérifiés. Après correction, le Sophos MCS Client peut être redémarré et Self Help actualisé. Un accès à Central depuis un navigateur ne remplace pas ce contrôle.

Erreurs d’Update sans suppression prématurée du Cache

L’échec d’un Update pendant la Grace Period de Sophos peut être temporaire. Il faut d’abord contrôler Update Now, le réseau, le Proxy, la source d’Update et l’heure de la dernière mise à jour réussie. Si ces contrôles ne révèlent aucune cause, conserver d’abord les éléments de diagnostic suivants pour Sophos Support.

Lors d’une erreur reproductible, SophosUpdate.log est corrélé à un Packet Capture simultané ainsi qu’aux Firewall ou Proxy Logs. La réponse DNS, l’Update Server réellement contacté, le chemin direct ou via Proxy et la première erreur HTTP ou TLS sont déterminants. Les principaux chemins de Logs Windows sont indiqués dans Analyser correctement les Logs et services Sophos Endpoint Windows.

Le diagnostic s’arrête ici ; ne pas modifier les dossiers de cache et de repository sur la base d’un soupçon. Une réinitialisation du cache nécessite des instructions complètes de Sophos Support adaptées à la version de l’agent et aux symptômes, avec les chemins exacts, l’ordre des opérations et la procédure de retour.

Cette intervention nécessite des droits administrateur et la désactivation temporaire de Tamper Protection ; elle génère une alerte Pending Restart. Sauvegarder ou renommer les dossiers concernés conformément à ces instructions, sans les supprimer sans contrôle. Après l’intervention, une mise à jour complète doit réussir et Self Help doit afficher de nouveau un état sain après Refresh.

Enfin, réactiver Tamper Protection et contrôler l’état de protection actif localement ainsi que dans Sophos Fusion. Tant que la procédure ou le retour ne sont pas définis, s’en tenir aux constatations du diagnostic.

Performance Analysis

Depuis Core Agent 2024.3, ESH peut charger les résumés Scanner sur Windows 10 x64 ou version ultérieure et Windows Server 2016 ou version ultérieure. Les données d’entrée sont les résultats d’un processus Product Analysis ou des fichiers créés avec SFS > Scan Summaries dans Product Logging ; ils peuvent provenir de cet appareil ou d’un autre appareil équipé d’ESH. Les fichiers CSV se trouvent par défaut sous :

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

Ils peuvent être analysés sur un autre appareil avec Endpoint Self Help. Le fichier indique quels Processes et Paths ont généré la charge de Scan pendant la période enregistrée. Cela ne justifie pas encore une Exception générale. L’application, le modèle d’accès et l’exclusion techniquement la plus limitée sont d’abord examinés.

Lors de l’analyse, comparez d’abord les dossiers présentant une longue durée de scan cumulée, puis les chemins contrôlés très souvent et enfin les gros volumes de données. Un chemin fréquent n’est pas nécessairement celui dont la durée totale est la plus élevée. Si Self Help avertit qu’une exclusion est trop large, ne l’utilisez que brièvement pour confirmer la cause. Limitez toute solution permanente au sous-dossier ou au processus réellement responsable de la charge.

Product Analysis va plus loin en désactivant puis en réactivant de façon guidée les fonctions de protection pour isoler le composant impliqué. Il exige des droits administrateur et, si Tamper Protection est actif, son mot de passe. Exécutez-le uniquement sur un appareil de test contrôlé ou pendant une fenêtre de maintenance. Consignez d’abord l’état de la protection et des Updates, enregistrez le résultat, puis restaurez toutes les fonctions et Updates. L’outil fournit une hypothèse, pas une autorisation automatique d’exclusion.

File Info plutôt qu’une supposition

Sous Tools > File Info, un fichier PE Windows est évalué localement. Self Help affiche SHA-256, taille, catégorie Application Control, produit et décision de Policy. Local Reputation inclut les données Sophos et les Allowed Applications ou Blocked Items du client ; elle peut donc différer de Global Reputation et la remplacer pour la décision locale.

Deep Learning exige une licence Intercept X adaptée. Un résultat vert ne prouve pas qu’un malware déjà détecté est inoffensif ; les fichiers Malware ou PUA détectés ne peuvent normalement pas être déposés sur cette page. Pour une erreur de classification, conservez Hash, Signature, Lookup Type local et global et décision concrète, puis utilisez Sample Submission.

File Info fournit les données les plus complètes pour les fichiers PE Windows ; les autres types de fichiers ne donnent que des informations limitées. Après Run as administrator, Windows peut bloquer le glisser-déposer depuis un processus aux droits inférieurs ; utiliser alors browse for a file. La réputation et le résultat de la Policy ne garantissent pas l’intégrité du fichier. Lorsque la confiance dans le fichier est déterminante, effectuer l’analyse d’échantillon approuvée.

Approfondir le statut Policy, Services et Operations

Si Policy affiche des timestamps anciens, distinguez réception et traitement local. Contrôlez McsClient.log pour Connection et Backoff et McsAgent.log pour les erreurs Policy, Namespace et Status. Dans MCS Cache, Active.policy et Latest.policy indiquent si une nouvelle Policy est arrivée sans devenir active. Ne redémarrez les services qu’après avoir conservé l’observation, puis confirmez la transition dans le log.

Tout symbole bleu ou vide dans Operations n’est pas une erreur. Distinguez Data Lake désactivé, appareil exclu ou limite quotidienne atteinte d’un service Live Query réellement défaillant. En cas de mauvais Data Lake Status, contrôlez d’abord SophosLiveQueryService.log, SophosOsquery.log et Service State.

Heartbeat affiche Readiness, Certificate State et connexion à Sophos Firewall. configured, no connection currently available ne prouve pas seul une défaillance Endpoint et Heartbeat n’entre pas dans Device Health général. Si une connexion est attendue, corrélez les logs par heure et Device ID. Les Registry ou Certificate Repairs d’Advanced Self Help exigent Backup, Tamper Protection désactivé et retour documenté.

Démarrer SDU depuis l’interface

Dans ESH, ouvrir Launch SDU, accepter l’EULA et sélectionner Start pour collecter les informations système et les Sophos Product Logs. View log affiche ensuite la collecte, Open folder ouvre sdu.log et les archives, et Submit propose un téléversement ou une transmission manuelle pour le dossier. Sous Windows, sans options de collecte, sducli.exe enregistre les données sous C:\WINDOWS\Temp\sdu-YYYYMMDD_xxxxxx_xxxxxx. Pour Upload to Sophos, sdu-feedback.sophos.com doit être accessible sur TCP 443. L’URL de téléversement, volontairement non consultable dans le navigateur, est copiée dans le dossier de support ; elle figure aussi à la fin de sdu.log.

L’archive peut contenir Hostnames, Usernames, chemins, adresses IP, listes de processus, configurations et événements. Elle ne doit donc jamais être placée dans un ticket public, un File Share non protégé ou une conversation Chat.

Un appareil Windows, macOS ou Linux peut également être diagnostiqué depuis Central : sous My Environment > Computers & Servers, sélectionner l’appareil, puis Summary > More actions > Diagnose > Run. Le champ SDU affiche Status, Last Run et File Name ; noter le nom de fichier dans le dossier Support. L’archive est envoyée directement à Sophos via HTTPS 443, en utilisant le chemin habituel des domaines Sophos autorisés. L’action et l’administrateur qui l’a déclenchée apparaissent sous Reports > General Logs > Audit Logs.

Si l’appareil est hors ligne, Central conserve la commande pendant 14 jours au maximum. Elle est ensuite abandonnée et doit être relancée. La commande démarre lors de la prochaine communication Central. Il faut donc clarifier à l’avance le moment, l’autorisation relative aux données et la connectivité attendue.

Product Logging et Packet Capture

Product Logging nécessite une élévation UAC et augmente le Log Level de composants précis. Activez-le uniquement pour le composant suspect et une période reproductible. Un réglage Parent s’applique à tous ses Children ; un astérisque sur le Parent signale uniquement des valeurs différentes définies au niveau des Children. Save applique les niveaux en attente ; Revert… les annule seulement avant leur enregistrement. Pour rétablir un niveau déjà appliqué, sélectionner Default sur le Parent ou le Child modifié, puis Save. À la fermeture, Revert to Default rétablit les valeurs par défaut, tandis que Just Close laisse le Debug Logging actif. Fermer ESH ne l’arrête donc pas à lui seul. Après la reproduction, conservez les journaux avec les heures et les étapes, puis rétablissez les niveaux appliqués selon ce mécanisme. Un Debug Logging permanent peut générer des contenus sensibles et beaucoup de données.

Packet Capture utilise Windows pktmon, nécessite une élévation UAC et n’est pas disponible avant Windows 10 1809 ni sur Windows Server 2016 ou version antérieure. La limite par défaut est de 512 MB et peut être réglée de 1 à 9999 MB ; les builds Windows 10 antérieurs à 2004 restent limités à 512 MB. Une limite adaptée évite de remplir le disque. Chaque exécution crée capture-<date><time>.etl et capture-<date><time>.pcapng sous C:\ProgramData\Sophos\Endpoint Self Help\PacketCapture ; les deux fichiers doivent être transmis. Fermer ESH arrête la capture. Les fichiers ne sont pas supprimés automatiquement et doivent être effacés manuellement après la durée de conservation approuvée.

Si Self Help ne peut élever Logging, Packet Capture ou SDU, vérifiez d’abord UAC. Un UAC entièrement désactivé ou des prompts supprimés peuvent bloquer la fonction. Restaurer les valeurs Microsoft est préférable à l’exécution permanente via le compte Administrator intégré.

SDU sous Windows en ligne de commande

La version Windows se trouve normalement sous :

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

Une session PowerShell avec des droits administrateur affiche l’aide intégrée avec :

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

Paramètres importants :

La sortie -help de la version installée fait foi. Les collectes automatisées disposent d’une limite de stockage, d’une cible sûre et d’un délai de suppression.

SDU sous macOS en ligne de commande

Sur Mac, SDU est lancé depuis l’Application Bundle :

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

--help affiche uniquement les commandes disponibles et ne collecte aucun diagnostic. La commande de collecte exécutable est :

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

--output_path="<path>" définit l’emplacement de sortie; sinon, le répertoire courant est utilisé. Ces options s’appliquent à l’agent macOS 2026.1 et versions ultérieures. Le processus nécessite les autorisations correspondant aux données collectées. Les Full Disk Access ou System Extension Permissions manquantes sont aussi vérifiées dans le diagnostic des autorisations macOS.

SDU sous Linux en ligne de commande

Sur un appareil protégé par Sophos Protection for Linux, l’utilitaire installé s’exécute ainsi :

/opt/sophos-spl/bin/sophos_diagnose

Il crée une archive tar.gz dans le répertoire de travail courant et collecte les logs de l’agent SPL, de tous les plugins ainsi que l’Audit Log. Pour choisir une cible contrôlée, créez un répertoire privé et transmettez-le comme premier argument positionnel :

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

Le dernier argument est un répertoire, pas le nom de l’archive; le fichier tar.gz obtenu y est créé. La syntaxe du fournisseur est ainsi conservée sans utiliser de dossier temporaire partagé.

Bien évaluer le mode forensique

SDU peut générer des Forensic Logs spécifiques. Ce mode est destiné à Sophos Incident Response ou à une investigation forensique ciblée. Il ne remplace pas un processus Enterprise Forensics complet et ne doit pas rester activé durablement sans mission définie.

En cas de compromission possible, des règles supplémentaires s’appliquent :

• ne pas redémarrer ni nettoyer l’appareil précipitamment,
• documenter la source horaire et le fuseau,
• écrire les preuves uniquement vers une cible contrôlée,
• consigner Hash, transfert et accès à l’archive,
• faire intervenir les responsables Incident Response.

Afficher configuration et statut logiciel en CLI

La CLI Endpoint locale peut afficher l’état des Policies et du logiciel. Output configuration montre quels paramètres sont arrivés sur l’appareil. Software Monitor fournit l’état des composants installés et peut actualiser leur statut.

Ces sorties aident pour trois contradictions fréquentes :

1. Central indique une Policy attribuée, mais le paramètre manque localement.
2. Agent Mode est correct, mais un composant n’est pas installé ou sain.
3. Un Update a été annoncé, mais Software Monitor reste en erreur.

L’aide disponible localement est contrôlée avant utilisation, car commandes et paramètres peuvent dépendre de la version Agent installée.

Analyser les Logs de manière ciblée

Tous les Logs ne sont pas lus intégralement. L’analyse commence par une période limitée et recherche la première erreur plutôt que ses seules conséquences. Les éléments particulièrement utiles sont :

• Installer et Update Logs pour les problèmes de Rollout,
• MCS ou Management Communication pour l’absence de contact Central,
• Health et Component Logs pour un statut rouge,
• événements Web, DLP, Application ou Peripheral pour les problèmes de Policy,
• Operating System Event Logs autour des démarrages de services, Drivers et certificats.

Un seul error ne constitue pas encore une cause. La corrélation temporelle, le composant et le comportement reproductible sont déterminants.

Préparer un paquet Support

Un bon paquet Support contient :

1. une courte description du problème et de son impact,
2. l’heure exacte avec fuseau,
3. les appareils concernés et non concernés servant de comparaison,
4. les étapes de reproduction,
5. des Central Screenshots pertinents sans secrets,
6. l’archive SDU et, le cas échéant, les Installer Logs,
7. les mesures déjà testées et leur résultat.

Tamper Protection Passwords, API Secrets, Proxy Passwords et Installer Tokens ne sont jamais joints en clair.

Respecter les Minimum Escalation Requirements

Sophos a réparti les exigences Windows Endpoint pour les escalades Support selon le type d’erreur. Un SDU sans analyse interne ne satisfait pas à ces Minimum Escalation Requirements, ou MER.

Pour chaque cas, il faut d’abord consigner la plateforme et la version du produit, le composant concerné, l’étendue, la fréquence, la reproductibilité, les changements précédant l’apparition et les messages d’erreur exacts. Les Logs doivent être complets, inclure l’heure de l’erreur et correspondre dans le temps pour les problèmes Client-Server.

Les données propres au scénario sont ensuite ajoutées :

Pour un problème de Performance, il faut d’abord distinguer si SophosFileScanner.exe, SEDService.exe, SSPService.exe, un autre Process Sophos ou la charge système générale est anormal. Une protection désactivée globalement sans mesure simultanée ni attribution précise du composant ne fournit pas de cause fiable.

Un dossier Support ne contient pas seulement les fichiers collectés, mais aussi le résultat de l’analyse interne : quel Log montre la première erreur pertinente, à quelle heure et quelle hypothèse a ainsi été confirmée ou rejetée ?

Vérifiez aussi sous Account Preferences > Evaluation Modes si Aggressive threat detection est activé. Cette option de diagnostic destinée à Sophos Support et SophosLabs augmente fortement la charge et ne constitue pas une base de sécurité en production. Si elle est active, documentez sa finalité et désactivez-la après la mesure prévue. Si le problème subsiste, poursuivez dans un nouveau dossier Performance avec une nouvelle plage horaire.

Pour les cas Exploit, Ransomware ou HitmanPro.Alert, vérifiez également si Sophos propose une Endpoint Maintenance Release contenant un correctif approprié. Créez le Crash Dump ou le Memory Dump complet après reproduction et avant le SDU afin que les artefacts couvrent la même période. Ne renommez aucune DLL ni aucun Driver de protection sans Runbook Sophos actuel.

Questions fréquentes