Skip to main content

28 septembre 2026

Analyse d’incident du système d’exploitation

Utilisez la fonctionnalité améliorée d’analyse des incidents du système d’exploitation dans la Gestion de l'expérience Omnissa pour Windows et l’environnement Horizon afin de capturer les événements de cause principale plutôt que de capturer des événements au niveau du noyau. Cette fonctionnalité est activée par défaut.

Données collectées de l'appareil

La Gestion de l’expérience pour Windows et Horizon Agent collecte les attributs répertoriés pour la fonctionnalité d’analyse d’incident du système d’exploitation à l’aide du processus ExternalDumpAnalyzer, qui est inclus dans l’agent.

ColonneAttributCatégorie de donnéesDescription des donnéesÉvénements associés
Suivi complet de la pilecomplete_stack_traceDiagnostics de l'appareil/données du diagnostic d’incidentSuivi de pile complet capturé à partir de l’analyse du vidage sur incident du système d’exploitation.

Il s’agit d’un champ de texte qui peut contenir plusieurs trames de pile utilisées pour diagnostiquer l’incident du système.
Incident du système à partir de DeviceEventTracker
Causé par un modulecaused_by_moduleDiagnostics de l'appareil/données de diagnostic d’incidentModule ou pilote identifié par l’analyse de vidage comme étant associé à la cause du blocage, par exemple un .dll, un .sys ou un nom de module.

Il s’agit d’un champ de chaîne.
Incident du système à partir de DeviceEventTracker
Processus associé àprocess_associated_withDiagnostics de l'appareil/données de diagnostic d’incidentNom du processus associé à l'incident du système tel que déterminé à partir de l’analyse de vidage mémoire.

Il s’agit d’un champ de chaîne.
Incident du système à partir de DeviceEventTracker

Configurations requises

Assurez-vous que vous avez respecté les exigences répertoriées avant de déployer la fonctionnalité améliorée d’analyse d’incident du système d’exploitation sur les appareils Windows.

  • Utilisez la Gestion de l'expérience pour Windows et l'agent Horizon 26.07 ou une version ultérieure.
  • Assurez-vous que le répertoire du cache des symboles de l'appareil est accessible en écriture par le compte de service de Workspace ONE Endpoint Telemetry.
  • Assurez-vous que l'appareil peut accéder au serveur de symboles publics Microsoft directement depuis http://msdl.microsoft.com/download/symbols ou via le proxy configuré.
  • Installez et utilisez WinDbg sur l'appareil.
  • Utilisez des variables d’environnement de niveau système pour les scénarios de service.
  • Redémarrez le service Workspace ONE Endpoint Telemetry ou redémarrez-le après avoir modifié les variables d’environnement au niveau du système.

Comment fonctionne cette fonctionnalité ?

Lorsque la Gestion de l'expérience détecte un vidage sur incident du système d’exploitation Windows, DeviceEventTracker lance le processus ExternalDumpAnalyzer (ws1dumpa.exe). Il existe deux modes d’analyse d'incident du système d’exploitation : le mode IPC (Inter-Process Communication) et le mode autonome.

Mode IPC

  • Lorsqu'un incident du système d'exploitation Windows survient et que le système détecte un vidage sur incident du système d'exploitation, DeviceEventTracker lance le processus ExternalDumpAnalyzer depuis C:\Program Files\WorkspaceONE\Endpoint Telemetry\Tools\ws1dumpa.exe.
  • Le chemin d’accès au vidage sur incident est transmis en tant qu’argument au processus.
  • Avant le début de l’analyse, ws1dumpa.exe effectue les validations suivantes.
    • La demande est exécutée avec les privilèges SYSTEM ou administrateur.
    • Le fichier de vidage existe.
    • Des outils de débogage sont disponibles.
    • La connexion réseau est disponible.
    • Si l’une des validations échoue, le système consigne un message d’avertissement ou d’erreur approprié.
  • Après validation, le processus ExternalDumpAnalyzer effectue les étapes répertoriées.
    • Utilise le débogueur installé pour analyser le vidage mémoire.
    • Génère des résultats d’analyse d’incident.
    • Renvoie les résultats au service de télémétrie.
  • Le résultat de l’analyse inclut les champs d’incident enrichis suivants.
    • process_associated_with
    • caused_by_module
    • complete_stack_trace

Débogueur de secours

Si les outils de débogage ne sont pas disponibles, l’analyse revient au débogueur de la boîte de réception. Elle utilise les aides au débogage de la boîte de réception Windows avec les options de symbole des informations du vidage sur incident, le processus minimal, les informations de module et complete_stack_trace. Les options de symbole complete_stack_trace sont utiles pour l’analyse.

Résolution de symbole

  • Si la connexion réseau est disponible, le système peut télécharger les symboles correspondants à partir du serveur de symboles. WinDbg utilise ces symboles pour une analyse précise.
  • Lorsque le réseau n’est pas disponible, mais que les symboles requis sont déjà présents dans le cache local, l’analyseur peut les utiliser.

Analyse de secours

Si l’analyse externe échoue pour une raison quelconque, DeviceEventTracker revient à une analyse de vidage intra-processus. Elle utilise les aides de débogage de la boîte de réception Windows avec les options de symbole des informations du vidage sur incident, le processus minimal, les informations de module et complete_stack_trace. Les options de symbole complete_stack_trace sont utiles pour l’analyse.

Enfin, le système génère l’événement system_crash et l’envoie avec ces attributs enrichis à la Gestion de l’expérience.

Mode autonome

Vous pouvez également exécuter le processus ExternalDumpAnalyzer indépendamment en fournissant un fichier de vidage mémoire comme argument.

  1. Ouvrez une invite de commande en tant qu'administrateur.
  2. Exécutez la commande suivante : C:\Program Files\WorkspaceONE\Endpoint Telemetry\Tools\ws1dumpa.exe "dumpfilepath".

Comportement

  • Toutes les validations et fonctionnalités d’analyse sont identiques au mode IPC.
  • Les résultats de l’analyse s’affichent directement dans l’invite de commande.
  • Les résultats ne sont pas envoyés aux services Intelligence ou Gestion de l'expérience.
  • Ce mode est principalement destiné à des fins de dépannage et de validation.

Installer et utiliser WinDbg sur l'appareil

Le processus ExternalDumpAnalyzer utilise le moteur de débogage Microsoft pour charger le vidage sur incident du système d’exploitation, résoudre les symboles et produire des champs d’analyse d’incident, tels que le suivi de pile et le module à l'origine de l'incident. Utilisez WinDbg comme débogueur, car il est intégré au moteur de débogage Microsoft et donne un accès complet à l’analyse des incidents du système d’exploitation.

Ordre des recherches

Le processus ExternalDumpAnalyzer recherche les composants du moteur de débogage Microsoft dans l’ordre indiqué.

  1. Chemins d’accès aux outils de débogage SDK de Windows, tels que C:\\Program Files (x86)\\Windows Kits\\10\\Debuggers\\x64
    • S’il ne trouve rien, il essaie l’emplacement de recherche suivant.
  2. Chemins d’accès aux modules WinDbg de Microsoft Store sous C:\\Program Files\\WindowsApps\\Microsoft.WinDbg_*
    • S’il ne trouve rien, il essaie l’emplacement de recherche suivant.
  3. Le système dbgeng.dll

Méthodes d'installation de WindDbg

Vous pouvez installer WinDbg en utilisant deux méthodes : le Microsoft Store ou le SDK de Windows.

Exécutez la commande d’installation dans le contexte de l'appareil utilisé par le système de déploiement et validez le chemin d’accès installé avant d’activer globalement l’analyse d’incident du système d’exploitation améliorée.

  • Installation de Microsoft Store
    • Vous pouvez installer WinDbg en tant qu’administrateur à l’aide de la ligne de commande, avec le gestionnaire de modules WinGet et la commande répertoriée.
    • winget install --id Microsoft.WinDbg --source msstore --accept-package-agreements --accept-source-agreements
    • Utilisez la fonctionnalité de distribution logicielle (SFD) dans Omnissa UEM pour envoyer la commande aux appareils.
  • Installation de Windows SDK
    • Utilisez Windows SDK et ses outils de débogage Windows SDK correspondants si votre organisation bloque l’utilisation des boutiques d’applications.
    • Assurez-vous que le fichier système dbgeng.dll se trouve dans l’un de ces chemins répertoriés.
      • C:\Program Files (x86)\Windows Kits\10\Debuggers\x64
      • C:\Program Files (x86)\Windows Kits\10\Debuggers\arm64
      • C:\Program Files (x86)\Windows Kits\10\Debuggers\x86

Où se trouve le processus ExternalDumpAnalyzer ?

Le processus ExternalDumpAnalyzer se trouve sur le périphérique au chemin répertorié.

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WorkspaceONE\Endpoint Telemetry\Service\Config\ExternalDumpAnalyzer\Enabled

Vous pouvez remplacer la paire clé-valeur dans le registre de l'appareil par false pour désactiver la fonctionnalité améliorée d’analyse d’incident du système d’exploitation.

Nom de la cléValeurDescription
ActivétrueExternalDumpAnalyzer est activé.
ActivéfauxExternalDumpAnalyzer est désactivé.

Script de désactivation

Si vous ne souhaitez pas désactiver manuellement la paire clé-valeur, vous pouvez créer votre propre script PowerShell, par exemple nommer le fichier Set-ExternalDumpAnalyzer.ps1, pour la désactivation à distance ou en masse au lieu de modifier manuellement la clé de registre.

  • .\Set-ExternalDumpAnalyzer.ps1 active la fonctionnalité (Enabled = "true")
  • .\Set-ExternalDumpAnalyzer.ps1 -Disable désactive la fonctionnalité (Enabled = "false")
  • .\Set-ExternalDumpAnalyzer.ps1 -Remove supprime entièrement la clé (rétablit la valeur par défaut)

Remarque : assurez-vous d’exécuter le script avec des privilèges d’administrateur/SYSTÈME, car il écrit sur HKLM.

#Requires -RunAsAdministrator
<#
.SYNOPSIS
    Enables, disables, or removes the DEEM / Endpoint Telemetry
    "ExternalDumpAnalyzer" registry setting, for remote/mass deployment.

.DESCRIPTION
    Target key:
        HKLM\SOFTWARE\WorkspaceONE\Endpoint Telemetry\Service\Config\ExternalDumpAnalyzer

    Actions:
      (default)   Set  "Enabled" = "true"    -> feature enabled
      -Disable    Set  "Enabled" = "false"   -> feature disabled
      -Remove     Delete the ExternalDumpAnalyzer key entirely
                  -> agent falls back to its default (disabled)

    Notes:
    - "Enabled" is a STRING (REG_SZ) "true"/"false", matching the admin guide and
      the agent config option ExternalDumpAnalyzer/Enabled (bool, default false).
    - Creates the key path if it does not exist (enable/disable).
    - Always targets the 64-bit registry view, so it works even if invoked by a
      32-bit deployment host (avoids WOW6432Node redirection).
    - Intended for Workspace ONE UEM scripts, Intune, GPO startup scripts, or
      PowerShell Remoting (Invoke-Command).

.PARAMETER Disable
    Disable the feature (sets Enabled = "false"). Omit to enable ("true").

.PARAMETER Remove
    Remove the ExternalDumpAnalyzer key from the registry (reverts to default).

.EXAMPLE
    .\Set-ExternalDumpAnalyzer.ps1
    Enables ExternalDumpAnalyzer (Enabled = "true").

.EXAMPLE
    .\Set-ExternalDumpAnalyzer.ps1 -Disable

.EXAMPLE
    .\Set-ExternalDumpAnalyzer.ps1 -Remove

.NOTES
    Exit codes: 0 success | 1 general failure | 2 verification failed |
                5 not elevated
#>
[CmdletBinding(DefaultParameterSetName = 'Set')]
param(
    [Parameter(ParameterSetName = 'Set')]
    [switch]$Disable,

    [Parameter(ParameterSetName = 'Remove')]
    [switch]$Remove
)

$ErrorActionPreference = 'Stop'

$subKeyPath = 'SOFTWARE\WorkspaceONE\Endpoint Telemetry\Service\Config\ExternalDumpAnalyzer'
$valueName  = 'Enabled'

function Test-IsAdministrator {
    $identity  = [Security.Principal.WindowsIdentity]::GetCurrent()
    $principal = New-Object Security.Principal.WindowsPrincipal($identity)
    return $principal.IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)
}

try {
    if (-not (Test-IsAdministrator)) {
        Write-Error 'Must be run as Administrator (writes to HKLM).'
        exit 5
    }

    # Open the 64-bit HKLM view explicitly (robust to 32-bit callers).
    $base = [Microsoft.Win32.RegistryKey]::OpenBaseKey(
        [Microsoft.Win32.RegistryHive]::LocalMachine,
        [Microsoft.Win32.RegistryView]::Registry64)

    if ($Remove) {
        # ---- Remove the ExternalDumpAnalyzer key entirely ----
        $existing = $base.OpenSubKey($subKeyPath)
        if ($null -eq $existing) {
            Write-Output "ExternalDumpAnalyzer key not present; nothing to remove."
            Write-Output "Key: HKLM\$subKeyPath"
            $base.Close()
            exit 0
        }
        $existing.Close()

        $base.DeleteSubKeyTree($subKeyPath)

        # Verify removal.
        $check = $base.OpenSubKey($subKeyPath)
        $base.Close()
        if ($null -ne $check) {
            $check.Close()
            Write-Error "Verification failed: key still present at HKLM\$subKeyPath"
            exit 2
        }

        Write-Output "ExternalDumpAnalyzer REMOVED from registry (agent reverts to default: disabled)."
        Write-Output "Key: HKLM\$subKeyPath"
        exit 0
    }

    # ---- Enable / Disable ----
    $desired   = if ($Disable) { 'false' } else { 'true' }
    $stateText = if ($Disable) { 'DISABLED' } else { 'ENABLED' }

    # CreateSubKey creates the full path if missing and opens it writable.
    $key = $base.CreateSubKey($subKeyPath)
    if ($null -eq $key) {
        Write-Error "Failed to open/create registry key: HKLM\$subKeyPath"
        exit 1
    }

    # Value is a REG_SZ string "true"/"false".
    $key.SetValue($valueName, $desired, [Microsoft.Win32.RegistryValueKind]::String)

    # Verify the written value.
    $actual = $key.GetValue($valueName)
    $key.Close()
    $base.Close()

    if ($actual -ne $desired) {
        Write-Error "Verification failed: $valueName = '$actual' (expected '$desired')."
        exit 2
    }

    Write-Output "ExternalDumpAnalyzer $stateText  ($valueName = `"$actual`")"
    Write-Output "Key: HKLM\$subKeyPath"
    exit 0
}
catch {
    Write-Error "Failed to update ExternalDumpAnalyzer: $($_.Exception.Message)"
    exit 1
}

Politiques pour les paramètres liés aux symboles

Vous pouvez configurer certaines politiques pour définir les paramètres liés aux symboles. Les politiques se trouvent sous Workspace ONE Endpoint Telemetry > DEEM > Symbol Store Settings.

La clé de registre que la politique utilise est la politique Symbol Store Settings située à l’emplacement HKLM\Software\Policies\WorkspaceONE\Endpoint Telemetry\DEEM\Symbol Store Settings, et elle comprend 5 fichiers de politique de registre de symboles à configurer.

  1. Symboles locaux
    • Configure les variables de symbole à utiliser.
    • Ces paramètres ont une incidence sur les fichiers de registre symboles Microsoft, symboles alternatifs et proxy de symbole.
    • True = variables de symbole locales
      • Dans la politique Symbol Store Settings, configurez UseLocalSymbolConfiguration comme true pour définir le processus ExternalDumpAnalyzer afin qu’il utilise les variables de symbole locales.
      • Au moins une de ces variables de symbole locales doit être configurée sur l'appareil.
        • _NT_SYMBOL_PATH
        • _NT_ALT_SYMBOL_PATH
        • _NT_SYMBOL_PROXY
      • Si aucune de ces variables de symbole locales n’est configurée sur l'appareil, le processus ExternalDumpAnalyzer peut utiliser le cache de symboles géré par défaut.
      • Si vous définissez cette politique sur True, le système ignore les fichiers de registre de symboles Microsoft, symboles alternatifs et proxy de symbole.
    • False = valeurs de politique ou variables de symbole gérées par défaut
      • Dans la politique Symbol Store Settings, configurez UseLocalSymbolConfiguration comme false pour définir le processus ExternalDumpAnalyzer afin qu’il utilise les valeurs de politique ou les variables de symbole gérées par défaut.
      • Le système préfère utiliser les valeurs de politique si elles sont présentes. Si les valeurs de politique ne sont pas définies sur l'appareil, le système utilise les valeurs gérées par défaut.
  2. Symboles Microsoft
    • Configure le chemin du symbole Microsoft et l’emplacement du cache local.
    • La valeur du registre est MicrosoftSymbols.
    • La valeur par défaut lorsque cette option n’est pas configurée est srv*C:\ProgramData\WorkspaceONE\ws1etlm\MSSymbols*http://msdl.microsoft.com/download/symbols.
    • Exemple de cache personnalisé : srv*C:\Symbols*http://msdl.microsoft.com/download/symbols.
    • Si vous configurez UseLocalSymbolConfiguration en tant que true, le système ignore ce fichier de registre.
  3. Autres symboles
    • Configure un chemin de symbole supplémentaire équivalent au chemin d’accès _NT_ALT_SYMBOL_PATH.
    • La valeur du registre est AlternativeSymbols.
    • Le système recherche ce chemin avant celui des symboles Microsoft.
    • Par exemple, C:\PrivateSymbols.
    • Si vous configurez UseLocalSymbolConfiguration en tant que true, le système ignore ce fichier de registre.
  4. Proxy de symbole
    • Configure le proxy de symbole équivalent à _NT_SYMBOL_PROXY.
    • La valeur du registre est SymbolProxy.
    • Par exemple http://proxy.example.com:8080.
    • Si vous configurez UseLocalSymbolConfiguration en tant que true, le système ignore ce fichier de registre.
  5. Supprimer les symboles
    • Configure la durée pendant laquelle le cache de symboles local géré est conservé avant la suppression.
    • La valeur du registre est DeleteSymbolsKeepHours.
    • Il est préférable d’associer le temporisateur de nettoyage à la planification de rétention configurée.
      • Si l'appareil a déjà téléchargé des symboles dans le passé et qu’un nettoyage est bientôt prévu ou en retard, retardez ce registre de 15 à 25 minutes après le redémarrage (qui se produit après un blocage).
      • Si un nettoyage est dû ultérieurement sur l'appareil, définissez le temporisateur pour cette période de rétention, plus 15 à 25 minutes. Ce temporisateur garantit que le nettoyage ne s’exécute pas directement au démarrage et n’interfère pas avec l’analyse du vidage sur incident.
    • Les valeurs autorisées incluent Minimum: 1 hour, Maximum: 720 hourset Default: 168 hours. Il y a 168 heures en sept jours.

Configurer des politiques de symbole

Choisissez parmi deux méthodes pour activer et déployer la fonctionnalité améliorée d’analyse d’incident du système d’exploitation. Utilisez des commandes PowerShell ou des objets de politique de groupe (GPO).

  • PowerShell
    • À l’aide de politiques de registre, écrivez directement dans la clé de registre de politique.
    • Cette méthode est utile si vous utilisez la fonctionnalité de distribution logicielle (SFD) pour envoyer des commandes aux appareils et que vous n’utilisez pas de GPO.
    • Cette méthode nécessite WinDbg sur les appareils.
  • objets de stratégie de groupe
    • Configurez les fichiers de politique de registre de symboles dans l’éditeur de gestion de politique de groupe.
    • Utilisez les modèles d’administration ADMX et ADML pour déployer les politiques de symbole à partir de la console de gestion de politique de groupe au niveau du GPO du domaine.
    • Le GPO écrit les mêmes valeurs de politique reposant sur le registre sur les appareils cibles.
    • Cette méthode est utile si vous utilisez des GPO pour gérer des appareils et que vous n’utilisez pas la SFD.

Méthode PowerShell

Si vous utilisez la fonctionnalité SFD pour transférer des commandes vers des appareils, ajoutez les fichiers de politique de registre de symboles nécessaires et ajustez les valeurs des politiques respectives en fonction de vos besoins.

Important : redémarrez le service Workspace ONE Endpoint Telemetry ou l'appareil après avoir modifié les variables d’environnement de la machine, car les services Windows lisent les variables d’environnement lorsque le processus de service démarre.

Exemples

Vous trouverez des exemples de fichiers de politique de registre de symboles.

Cache de symboles géré par défaut

Définit le cache de symboles géré par défaut.

$policyPath = "HKLM:\Software\Policies\WorkspaceONE\Endpoint Telemetry\DEEM\Symbol Store Settings"
New-Item -Path $policyPath -Force | Out-Null

New-ItemProperty -Path $policyPath -Name "UseLocalSymbolConfiguration" -PropertyType String -Value "false" -Force | Out-Null
New-ItemProperty -Path $policyPath -Name "MicrosoftSymbols" -PropertyType String -Value "srv*C:\ProgramData\WorkspaceONE\ws1etlm\MSSymbols*http://msdl.microsoft.com/download/symbols" -Force | Out-Null
New-ItemProperty -Path $policyPath -Name "DeleteSymbolsKeepHours" -PropertyType DWord -Value 168 -Force | Out-Null

Cache de symboles personnalisés

Définit le cache de symboles personnalisés.

$policyPath = "HKLM:\Software\Policies\WorkspaceONE\Endpoint Telemetry\DEEM\Symbol Store Settings"
New-Item -Path $policyPath -Force | Out-Null

New-ItemProperty -Path $policyPath -Name "UseLocalSymbolConfiguration" -PropertyType String -Value "false" -Force | Out-Null
New-ItemProperty -Path $policyPath -Name "MicrosoftSymbols" -PropertyType String -Value "srv*C:\Symbols*http://msdl.microsoft.com/download/symbols" -Force | Out-Null
New-ItemProperty -Path $policyPath -Name "AlternativeSymbols" -PropertyType String -Value "C:\PrivateSymbols" -Force | Out-Null
New-ItemProperty -Path $policyPath -Name "SymbolProxy" -PropertyType String -Value "http://proxy.example.com:8080" -Force | Out-Null
New-ItemProperty -Path $policyPath -Name "DeleteSymbolsKeepHours" -PropertyType DWord -Value 168 -Force | Out-Null

Variables d'environnement de symbole locales

Définit les variables d'environnement de symbole locales. Utilisez cette configuration lorsque vous souhaitez que le processus ExternalDumpAnalyzer utilise des variables d’environnement de symbole locales plutôt que des valeurs de symbole de politique.

$policyPath = "HKLM:\Software\Policies\WorkspaceONE\Endpoint Telemetry\DEEM\Symbol Store Settings"
New-Item -Path $policyPath -Force | Out-Null
New-ItemProperty -Path $policyPath -Name "UseLocalSymbolConfiguration" -PropertyType String -Value "true" -Force | Out-Null

[Environment]::SetEnvironmentVariable("_NT_SYMBOL_PATH", "srv*C:\Symbols-check*http://msdl.microsoft.com/download/symbols", "Machine")
[Environment]::SetEnvironmentVariable("_NT_ALT_SYMBOL_PATH", "C:\PrivateSymbols", "Machine")
[Environment]::SetEnvironmentVariable("_NT_SYMBOL_PROXY", "http://proxy.example.com:8080", "Machine")

Méthode des GPO

Configurez les politiques dans l’éditeur de gestion de politique de groupe et utilisez les fichiers de modèle d’administration ADMX et ADML afin que les politiques soient disponibles dans la console de gestion de politique de groupe au niveau du GPO du domaine pour le déploiement.

Configurer les modèles d’administration ADMX et ADML

Configurez les modèles ADMX et ADML dans la politique de GPO du domaine pour déployer les paramètres améliorés d’analyse d’incident du système d’exploitation sur votre flotte d'appareils Windows.

Conditions prérequises

Si vous n’avez pas récupéré etlm_extra_bundle à partir de Connexion client, récupérez-le maintenant, car il inclut les modèles ADMX et ADML, qui sont regroupés dans le fichier ZIP de l’agent de télémétrie du point de terminaison Omnissa.

Procédure

  1. Copiez wsone_etlm.admx dans le magasin central du domaine. \\<domain>\SYSVOL\<domain>\Policies\PolicyDefinitions\wsone_etlm.admx
  2. Copiez wsone_etlm.adml dans le dossier de langue correspondant. \\<domain>\SYSVOL\<domain>\Policies\PolicyDefinitions\en-US\wsone_etlm.adml
  3. Ouvrez la console de gestion de politique de groupe sur l'appareil Windows.
  4. Modifiez la politique de l'appareil ciblé.
  5. Accédez à Configuration de l'ordinateur > Modèles d'administration > Télémétrie des points de terminaison Omnissa > DEEM > Paramètres du magasin de symboles.
  6. Configurez les politiques de symboles appropriées parmi les cinq options disponibles (symboles locaux, symboles Microsoft, symboles alternatifs, proxy de symbole et supprimer les symboles) en fonction de vos besoins spécifiques.
  7. Appliquez la politique aux appareils cibles.
  8. Exécutez gpupdate /force ou attendez l’actualisation de la politique normale.

Ajouter des diagnostics d’incident aux rapports et tableaux de bord

Une fois que la fonctionnalité d’analyse d’incident du système d’exploitation améliorée signale des champs de diagnostic d’incident enrichis, vous pouvez ajouter ces champs sous forme de colonnes à n’importe quel rapport et aux widgets de tableau de bord pour analyser les causes principales des incidents dans votre flotte, sans quitter le workflow de rapports Intelligence que vous utilisez déjà.

Rapports

  1. Dans Intelligence, accédez à Workspace > Rapports.
  2. Ouvrez le rapport qui répertorie les événements d’Incident système.
  3. Sélectionnez Gérer les colonnes pour ajouter Suivi de pile, Suivi complet de la pile, Causé par module et Processus associé à dans la liste de colonnes.
  4. Enregistrez le rapport.

Le tableau de rapport affiche désormais les colonnes de diagnostic sélectionnées pour chaque incident.
Votre rapport peut désormais afficher les diagnostics d’incident, tels que le suivi complet de la pile, causé par le module et le processus associé aux informations.

Widgets du tableau de bord

  1. Dans Intelligence, accédez à Workspace > Tableaux de bord.
  2. Créez un tableau de bord personnalisé ou ajoutez le widget à un tableau de bord existant.
  3. Sélectionnez la source de données Expérience employés > Appareils.
  4. Vous pouvez conserver toutes les entrées requises par défaut.
  5. Dans la zone Filtre, choisissez l’attribut Blocage du système.
  6. Enregistrez le widget.
  7. Utilisez l’option de menu Gérer les colonnes du widget pour ajouter les colonnes Suivi de pile, Causé par module et Processus associé à.

Ajoutez les informations sous forme de champs ou ajoutez-les en tant que dimensions de regroupement si cela répond à votre cas d’utilisation.

Cette page vous a-t-elle été utile ?

Envoyer un commentaire sur cette rubrique

Cette rubrique vous a-t-elle été utile ?

N'indiquez aucune information personnelle ou confidentielle.

Génération du lien…