Prise en main de la collecte d’événements de configuration et de démarrage

Vue d’ensemble

La collecte des événements de configuration et de démarrage est une nouvelle fonctionnalité dans Windows Server 2016 qui vous permet de désigner un ordinateur « collecteur » capable de rassembler divers événements importants qui se produisent sur d’autres ordinateurs lors de leur démarrage ou de leur processus de configuration. Vous pouvez ensuite analyser les événements collectés avec l’observateur d’événements, l’analyseur de messages, Wevtutil ou les applets de commande Windows PowerShell.

Auparavant, ces événements étaient impossibles à surveiller, car l’infrastructure nécessaire pour les collecter n’existe pas tant qu’un ordinateur n’est pas déjà configuré. Les types d’événements d’installation et de démarrage que vous pouvez surveiller sont les suivants :

• Chargement des modules et pilotes de noyau

• Énumération des appareils et initialisation de leurs pilotes (y compris les périphériques tels que le type de processeur)

• Vérification et montage de systèmes de fichiers

• Démarrage des fichiers exécutables

• Démarrage et saisie semi-automatique des mises à jour du système

• Les points lorsque le système devient disponible pour l’ouverture de session, établissent la connexion avec un contrôleur de domaine, l’achèvement du démarrage du service et la disponibilité des partages réseau

L’ordinateur collecteur doit exécuter Windows Server 2016 (il peut être en mode Server with Desktop Experience ou Server Core). L’ordinateur cible doit exécuter Windows 10 ou Windows Server 2016. Vous pouvez également exécuter ce service sur une machine virtuelle hébergée sur un ordinateur qui n’exécute pas Windows Server 2016. Les combinaisons suivantes d’ordinateurs collecteurs et cibles virtualisés sont connues pour fonctionner :

Installer le service de collecteur

À compter de Windows Server 2016, le service collecteur d’événements est disponible en tant que fonctionnalité facultative. Dans cette version, vous pouvez l’installer à l’aide de DISM.exe avec cette commande à une invite de Windows PowerShell avec élévation de privilèges :

dism /online /enable-feature /featurename:SetupAndBootEventCollection

Cette commande crée un service appelé BootEventCollector et le démarre avec un fichier de configuration vide.

Vérifiez que l’installation a réussi en vérifiant get-service -displayname *boot*. Le collecteur d’événements de démarrage doit être en cours d’exécution. Il s’exécute sous le compte de service réseau et crée un fichier de configuration vide (Active.xml) dans %SystemDrive%\ProgramData\Microsoft\BootEventCollector\Config.

Vous pouvez également installer le service de collecte d’événements d’installation et de démarrage avec l’Assistant Ajout de rôles et de fonctionnalités dans Gestionnaire de serveur.

Configuration

Vous devez configurer deux éléments pour collecter les événements d’installation et de démarrage.

• Sur les ordinateurs cibles qui envoient les événements (c’est-à-dire les ordinateurs dont vous souhaitez surveiller l’installation et le démarrage), activez le transport KDNET/EVENT-NET et activez le transfert des événements.

• Sur l’ordinateur collecteur, spécifiez les ordinateurs à partir desquels accepter les événements et où les enregistrer.

Configurer un ordinateur cible

Sur chaque ordinateur cible, vous activez d’abord le transport KDNET/EVENT-NET, puis vous activez l’envoi d’événements ETW via le transport, puis redémarrez l’ordinateur cible. EVENT-NET est un protocole de transport dans le noyau qui est similaire à KDNET (le protocole de débogueur du noyau). EVENT-NET transmet uniquement les événements et n’autorise pas l’accès au débogueur. Ces deux protocoles s’excluent mutuellement; vous ne pouvez activer qu’un seul d’entre eux à la fois.

Vous pouvez activer le transport d’événements à distance (avec Windows PowerShell) ou localement.

Pour activer le transport d’événements à distance

1. Si vous avez déjà configuré Communication à distance Windows PowerShell sur l’ordinateur cible, passez à l’étape 3. Si ce n’est pas le cas, sur l’ordinateur cible, ouvrez une invite de commandes et exécutez la commande suivante :

   winrm quickconfig

2. Répondez aux invites, puis redémarrez l’ordinateur cible. Si les ordinateurs cibles ne se trouvent pas dans le même domaine que l’ordinateur collecteur, vous devrez peut-être les définir en tant qu’hôtes approuvés. Pour ce faire :

3. Sur l’ordinateur collecteur, exécutez l’une des commandes suivantes :

   • Dans une invite Windows PowerShell : Set-Item -Force WSMan:\localhost\Client\TrustedHosts <target1>,<target2>,..., suivi de Set-Item -Force WSMan:\localhost\Client\AllowUnencrypted true où <target1>, etc. sont les noms ou adresses IP des ordinateurs cibles.

   • Ou dans une invite de commandes : winrm set winrm/config/client @{TrustedHosts=<target1,target2><>,...; AllowUnencrypted=true}

     Important

     Cela configure la communication non chiffrée. Ne le faites donc pas en dehors d’un environnement de laboratoire.

4. Testez la connexion à distance en accédant à l’ordinateur collecteur et en exécutant l’une de ces commandes Windows PowerShell :

   Si l’ordinateur cible se trouve dans le même domaine que l’ordinateur collecteur, exécutez New-PSSession -Computer <target> | Remove-PSSession

   Si l’ordinateur cible n’est pas dans le même domaine, exécutez New-PSSession -Computer <target> -Credential Administrator | Remove-PSSession, qui vous invite à entrer des informations d’identification.

   Si la commande ne retourne rien, la communication à distance a réussi.

5. Sur l’ordinateur cible, ouvrez une invite de Windows PowerShell avec élévation de privilèges et exécutez cette commande :

   Enable-SbecBcd -ComputerName <target_name> -CollectorIP <ip> -CollectorPort <port> -Key <a.b.c.d>

   Ici <, target_name> est le nom de l’ordinateur cible, <ip> est l’adresse IP de l’ordinateur collecteur. <port> est le numéro de port où le collecteur s’exécutera. La clé <a.b.c.d> est une clé de chiffrement requise pour la communication, comprenant quatre chaînes alphanumériques séparées par des points. Cette même clé est utilisée sur l’ordinateur collecteur. Si vous n’entrez pas de clé, le système génère une clé aléatoire ; vous en aurez besoin pour l’ordinateur collecteur, alors prenez-en note.

6. Si vous avez déjà configuré un ordinateur collecteur, mettez à jour le fichier de configuration sur l’ordinateur collecteur avec les informations du nouvel ordinateur cible. Pour plus d’informations, consultez la section Configuration de l’ordinateur collecteur.

Pour activer le transport d’événements localement sur l’ordinateur cible

1. Démarrez une invite de commandes avec élévation de privilèges, puis exécutez les commandes suivantes :

   bcdedit /event yes

   bcdedit /eventsettings net hostip:1.2.3.4 port:50000 key:a.b.c.d

   Ici 1.2.3.4 est un exemple ; remplacez ceci par l’adresse IP de l’ordinateur collecteur. Remplacez également 50000 par le numéro de port où le collecteur s’exécutera et a.b.c.d par la clé de chiffrement requise pour la communication. Cette même clé est utilisée sur l’ordinateur collecteur. Si vous n’entrez pas de clé, le système génère une clé aléatoire ; vous en aurez besoin pour l’ordinateur collecteur, alors prenez-en note.

2. Si vous avez déjà configuré un ordinateur collecteur, mettez à jour le fichier de configuration sur l’ordinateur collecteur avec les informations du nouvel ordinateur cible. Pour plus d’informations, consultez la section Configuration de l’ordinateur collecteur.

Maintenant que le transport d’événements lui-même est activé, vous devez autoriser le système à envoyer des événements ETW via ce transport.

Pour activer l’envoi d’événements ETW via le transport à distance

1. Sur l’ordinateur collecteur, ouvrez une invite de Windows PowerShell avec élévation de privilèges.

2. Exécutez Enable-SbecAutologger -ComputerName <target_name>, où <target_name> est le nom de l’ordinateur cible.

Si vous n’êtes pas en mesure de configurer Communication à distance Windows PowerShell, vous pouvez toujours activer l’envoi d’événements directement sur l’ordinateur cible.

Pour activer l’envoi d’événements ETW via le transport localement

1. Sur l’ordinateur cible, démarrez Regedit.exe et recherchez cette clé de Registre :

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WMI\AutoLogger. Différentes sessions de journal sont répertoriées en tant que sous-clés sous cette clé. La plateforme d’installation, l’enregistreur d’événements du noyau NT et Microsoft-Windows-Setup sont des choix possibles pour une utilisation avec la collecte d’événements d’installation et de démarrage, mais l’option recommandée est EventLog-System. Ces clés sont détaillées dans Configuration et démarrage d’une session de journal automatique.

2. Dans la clé EventLog-System, remplacez la valeur de LogFileMode de 0x10000180 par 0x10080180. Pour plus d’informations sur les détails de ces paramètres, consultez Constantes du mode de journalisation.

3. De manière facultative, vous pouvez également activer le transfert des données de vérification des bogues vers l’ordinateur collecteur. Pour ce faire, recherchez la clé de Registre HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager et créez la clé Filtre d’impression de débogage avec la valeur 0x1.

4. Redémarrer l’ordinateur cible.

Choix de la carte d’adaptateur

Si l’ordinateur cible a plusieurs adaptateurs réseau, le pilote KDNET choisit le premier adaptateur pris en charge répertorié. Vous pouvez spécifier un adaptateur réseau spécifique à utiliser pour le transfert des événements d’installation en procédant comme suit :

Pour spécifier un adaptateur réseau

1. Sur l’ordinateur cible, ouvrez Gestionnaire de périphériques, développez Adaptateurs réseau, recherchez l’adaptateur réseau que vous souhaitez utiliser, puis cliquez dessus avec le bouton droit.

2. Dans le menu qui s’ouvre, cliquez sur Propriétés, puis sur l’onglet Détails . Développez le menu dans le champ Propriété, faites défiler jusqu’à Informations d’emplacement (la liste n’est probablement pas par ordre alphabétique), puis cliquez dessus. La valeur est une chaîne de la forme pci bus X, appareil Y, fonction Z. Notez X.Y.Z ; il s’agit des paramètres de bus dont vous avez besoin pour la commande suivante.

3. Exécutez l’une de ces commandes :

   À partir d’une invite Windows PowerShell avec élévation de privilèges : Enable-SbecBcd -ComputerName <target_name> -CollectorIP <ip> -CollectorPort <port> -Key <a.b.c.d> -BusParams <X.Y.Z>

   À partir d’une invite de commandes avec élévation de privilèges : bcdedit /eventsettings net hostip:aaa port:50000 key:bbb busparams:X.Y.Z

Valider la configuration de l’ordinateur cible

Pour vérifier les paramètres sur l’ordinateur cible, ouvrez une invite de commandes avec élévation de privilèges et exécutez bcdedit /enum. Lorsque cette opération est terminée, exécutez bcdedit /eventsettings. Vous pouvez vérifier les valeurs suivantes :

• Clé :

• Debugtype = NET

• Hostip = <adresse IP du collecteur>

• Port = <numéro de port que vous avez spécifié pour le collecteur à utiliser>

• DHCP = oui

Vérifiez également que vous avez activé bcdedit /event, car /debug et /event s’excluent mutuellement. Vous ne pouvez exécuter que l’un ou l’autre. De même, vous ne pouvez pas combiner /eventsettings avec /debug ou /dbgsettings avec /event.

Notez également que la collecte d’événements ne fonctionne pas si vous la définissez sur un port série.

Configuration de l’ordinateur collecteur

Le service collecteur reçoit les événements et les enregistre dans des fichiers ETL. Ces fichiers ETL peuvent ensuite être lus par d’autres outils, tels que les applets de Event Viewer, Message Analyzer, Wevtutil et Windows PowerShell.

Étant donné que le format ETW ne vous permet pas de spécifier le nom de l’ordinateur cible, les événements de chaque ordinateur cible doivent être enregistrés dans un fichier distinct. Les outils d’affichage peuvent afficher un nom d’ordinateur, mais il s’agit du nom de l’ordinateur sur lequel l’outil s’exécute.

Plus précisément, un anneau de fichiers ETL est affecté à chaque ordinateur cible. Chaque nom de fichier inclut un index compris entre 000 et une valeur maximale que vous configurez (jusqu’à 999). Lorsque le fichier atteint la taille maximale configurée, il bascule les événements d’écriture vers le fichier suivant. Après le fichier le plus élevé possible, il revient à l’index de fichier 000. De cette façon, les fichiers sont automatiquement recyclés, ce qui limite l’utilisation de l’espace disque. Vous pouvez également définir des stratégies de rétention externe supplémentaires pour limiter davantage l’utilisation du disque ; par exemple, vous pouvez supprimer des fichiers antérieurs à un nombre défini de jours.

Les fichiers ETL collectés sont généralement conservés dans le répertoire c:\ProgramData\Microsoft\BootEventCollector\Etl (qui peut avoir des sous-répertoires supplémentaires). Vous pouvez trouver le fichier journal le plus récent en le triant par heure de la dernière modification. Il existe également un journal d’état (généralement dans c:\ProgramData\Microsoft\BootEventCollector\Logs), qui enregistre chaque fois que le collecteur bascule l’écriture dans un nouveau fichier.

Il existe également un journal du collecteur, qui enregistre des informations sur le collecteur lui-même. Vous pouvez conserver ce journal au format ETW (dans lequel les événements sont signalés au service de journal Windows ; il s’agit de la valeur par défaut) ou dans un fichier (normalement dans c:\ProgramData\Microsoft\BootEventCollector\Logs). L’utilisation d’un fichier peut être utile si vous souhaitez activer des modes détaillés qui produisent beaucoup de données. Vous pouvez également définir le journal pour écrire dans une sortie standard en exécutant le collecteur à partir de la ligne de commande.

Création du fichier de configuration du collecteur

Lorsque vous activez le service, trois fichiers de configuration XML sont créés et stockés dans c:\ProgramData\Microsoft\BootEventCollector\Config :

• Active.xml Ce fichier contient la configuration active actuelle du service collecteur. Juste après l’installation, ce fichier a le même contenu que Empty.xml. Lorsque vous définissez une nouvelle configuration de collecteur, vous l’enregistrez dans ce fichier.

• Empty.xml Ce fichier contient les éléments de configuration minimum nécessaires avec leurs valeurs par défaut définies. Ceci n’active aucune collection, mais permet uniquement au service collecteur de démarrer en mode inactif.

• Example.xml Ce fichier fournit des exemples et des explications sur les éléments de configuration possibles.

Choix d’une limite de taille de fichier

L’une des décisions que vous devez prendre consiste à définir une limite de taille de fichier. La limite de taille de fichier maximale dépend du volume attendu d’événements et de l’espace disque disponible. Les fichiers plus petits sont plus pratiques du point de vue du nettoyage des anciennes données. Toutefois, chaque fichier comporte la surcharge d’un en-tête de 64 Ko et la lecture de nombreux fichiers pour obtenir l’historique combiné peut être peu pratique. La limite de taille de fichier minimale absolue est de 256 Ko. Une limite de taille de fichier pratique raisonnable doit être supérieure à 1 Mo, et 10 Mo est probablement une bonne valeur typique. Une limite plus élevée peut être raisonnable si vous attendez de nombreux événements.

Il existe plusieurs détails à garder à l’esprit concernant le fichier de configuration :

• Adresse de l’ordinateur cible. Vous pouvez utiliser son adresse IPv4, une adresse MAC ou un GUID SMBIOS. Gardez ces facteurs à l’esprit lorsque vous choisissez l’adresse à utiliser :

  • L’adresse IPv4 fonctionne mieux avec l’affectation statique des adresses IP. Toutefois, même les adresses IP statiques doivent être disponibles via DHCP.

  • Une adresse MAC ou un GUID SMBIOS est pratique lorsqu’ils sont connus à l’avance, mais que les adresses IP sont attribuées dynamiquement.

  • Les adresses IPv6 ne sont pas prises en charge par le protocole EVENT-NET.

  • Il est possible de spécifier plusieurs façons d’identifier l’ordinateur. Par exemple, si le matériel physique est sur le point d’être remplacé, vous pouvez entrer à la fois l’ancienne et la nouvelle adresse MAC, et l’une ou l’autre sera acceptée.

• Clé de chiffrement utilisée pour la communication avec l’ordinateur collecteur

• Nom de l'ordinateur cible. Vous pouvez utiliser l’adresse IP, le nom d’hôte ou tout autre nom comme nom d’ordinateur.

• Le nom du fichier ETL à utiliser et la configuration de la taille d’anneau pour celui-ci

Pour créer un fichier de configuration

1. Ouvrez une invite de Windows PowerShell avec élévation de privilèges et remplacez les répertoires par %SystemDrive%\ProgramData\Microsoft\BootEventCollector\Config.

2. Tapez notepad .\newconfig.xml, puis appuyez sur ENTRÉE.

3. Copiez cet exemple de configuration dans la fenêtre Bloc-notes :

   <collector configVersionMajor=1 statuslog=c:\ProgramData\Microsoft\BootEventCollector\Logs\statuslog.xml>
     <common>
       <collectorport value=50000/>
       <forwarder type=etl>
         <set name=file value=c:\ProgramData\Microsoft\BootEventCollector\Etl\{computer}\{computer}_{#3}.etl/>
         <set name=size value=10mb/>
         <set name=nfiles value=10/>
         <set name=toxml value=none/>
       </forwarder>
       <target>
         <ipv4 value=192.168.1.1/>
         <key value=a.b.c.d/>
         <computer value=computer1/>
       </target>
       <target>
         <ipv4 value=192.168.1.2/>
         <key value=d1.e2.f3.g4/>
         <computer value=computer2/>
       </target>
     </common>
   </collector>
   

   Notes

   Le nœud racine est <collector>. Ses attributs spécifient la version de la syntaxe du fichier de configuration et le nom du fichier journal d’état.

   L’élément <commun> regroupe plusieurs cibles en spécifiant les éléments de configuration communs, tout comme un groupe d’utilisateurs peut être utilisé pour spécifier les autorisations communes pour plusieurs utilisateurs.

   L’élément <collectorport> définit le numéro de port UDP où le collecteur écoutera les données entrantes. Il s’agit du même port que celui spécifié dans l’étape de configuration cible pour Bcdedit. Le collecteur ne prend en charge qu’un seul port et toutes les cibles doivent se connecter au même port.

   L’élément <redirecteur> spécifie comment les événements ETW reçus des ordinateurs cibles seront transférés. Il n’existe qu’un seul type de redirecteur, qui les écrit dans les fichiers ETL. Les paramètres spécifient le modèle de nom de fichier, la limite de taille pour chaque fichier dans l’anneau et la taille de l’anneau pour chaque ordinateur. Le paramètre toxml spécifie que les événements ETW seront écrits au format binaire à mesure qu’ils ont été reçus, sans conversion au format XML. Consultez la section conversion d’événements XML pour plus d’informations sur la décision de conférer ou non les événements au format XML. Le modèle de nom de fichier contient les substitutions suivantes : {computer} pour le nom de l’ordinateur et {#3} pour l’index du fichier dans l’anneau.

   Dans cet exemple de fichier, deux ordinateurs cibles sont définis avec l’élément <cible>. Chaque définition spécifie l’adresse IP avec <ipv4>, mais vous pouvez également utiliser l’adresse MAC (par exemple, <mac value=11:22:33:44:55:66/> ou <mac value=11-22-33-44-55-66/>) ou le GUID SMBIOS (par exemple, <guid value={269076F9-4B77-46E1-B03B-CA5003775B88}/>) pour identifier l’ordinateur cible. Notez également la clé de chiffrement (identique à celle qui a été spécifiée ou générée avec Bcdedit sur l’ordinateur cible) et le nom de l’ordinateur.

4. Entrez les détails de chaque ordinateur cible en tant qu’élément <cible> distinct dans le fichier de configuration, puis enregistrez Newconfig.xml et fermez le Bloc-notes.

5. Appliquez la nouvelle configuration avec $result = (Get-Content .\newconfig.xml | Set-SbecActiveConfig); $result. La sortie doit retourner avec le champ Réussite « true ». Si vous obtenez un autre résultat, consultez la section Résolution des problèmes de cette rubrique.

Vous pouvez toujours vérifier la configuration active actuelle avec (Get-SbecActiveConfig).text.

Vous pouvez effectuer une vérification de validité sur le fichier de configuration avec $result = (Get-Content .\newconfig.xml | Check-SbecConfig); $result.

Bien que la commande Windows PowerShell pour appliquer une nouvelle configuration met automatiquement à jour le service sans vous obliger à le redémarrer, vous pouvez toujours redémarrer le service vous-même avec l’une des commandes suivantes :

• Avec Windows PowerShell : Restart-Service BootEventCollector

• Dans une invite de commandes ordinaire : sc stop BootEventCollector; sc start BootEventCollector

Configuration de Nano Server en tant qu’ordinateur cible

L’interface minimale offerte par Nano Server peut parfois rendre difficile le diagnostic des problèmes. Vous pouvez configurer votre image Nano Server pour participer automatiquement à la collecte d’événements d’installation et de démarrage, en envoyant des données de diagnostic à un ordinateur collecteur sans intervention supplémentaire de votre part. Pour ce faire, effectuez les étapes suivantes :

Pour configurer Nano Server en tant qu’ordinateur cible

1. Créer votre image Nano Server de base. Voir Prise en main de Nano Server pour plus d’informations.

2. Configurez un ordinateur collecteur comme dans la section Configuration de l’ordinateur collecteur de cette rubrique.

3. Ajoutez des clés de registre AutoLogger pour activer l’envoi de messages de diagnostic. Pour ce faire, vous montez le disque dur virtuel Nano Server créé à l’étape 1, chargez la ruche du registre, puis ajoutez certaines clés de registre. Dans cet exemple, l’image Nano Server est en C:\NanoServer ; votre chemin d’accès peut être différent, donc ajustez les étapes en conséquence.

   1. Sur l’ordinateur collecteur, copiez le dossier .. \Windows\System32\WindowsPowerShell\v1.0\Modules\BootEventCollector et collez-le dans le répertoire ..\Windows\System32\WindowsPowerShell\v1.0\Modules sur l’ordinateur que vous utilisez pour modifier le disque dur virtuel Nano Server.

   2. Démarrez une console Windows PowerShell avec des autorisations élevées et exécutez Import-Module BootEventCollector.

   3. Mettez à jour le registre du disque dur virtuel Nano Server pour activer autologgers. Pour cela, exécutez Enable-SbecAutoLogger -Path C:\NanoServer\Workloads\IncludingWorkloads.vhd. Cette opération ajoute une liste de base des événements d’installation et de démarrage les plus courants ; vous pouvez rechercher d’autres personnes dans le Contrôle des sessions de suivi d’événements.

4. Mettez à jour les paramètres BCD dans l’image Nano Server pour activer l’indicateur Événements et définissez l’ordinateur collecteur pour vous assurer que les événements de diagnostic sont envoyés au serveur approprié. Notez l’adresse IPv4, le port TCP et la clé de chiffrement de l’ordinateur collecteur que vous avez configurés dans le fichier Active.XML du collecteur (décrits ailleurs dans cette rubrique). Utilisez cette commande dans une console Windows PowerShell avec des autorisations élevées : Enable-SbecBcd -Path C:\NanoServer\Workloads\IncludingWorkloads.vhd -CollectorIp 192.168.100.1 -CollectorPort 50000 -Key a.b.c.d

5. Mettez à jour l’ordinateur collecteur pour recevoir l’événement envoyé par l’ordinateur Nano Server en ajoutant la plage d’adresses IPv4, l’adresse IPv4 spécifique ou l’adresse MAC de Nano Server au fichier Active.XML sur l’ordinateur collecteur (voir la section Configuration de l’ordinateur collecteur de cette rubrique).

Démarrage du service collecteur d’événements

Une fois qu’un fichier de configuration valide est enregistré sur l’ordinateur collecteur et qu’un ordinateur cible est configuré, dès que l’ordinateur cible est redémarré, la connexion au collecteur est établie et les événements sont collectés.

Le journal du service collecteur lui-même (qui est distinct des données d’installation et de démarrage collectées par le service) se trouve sous Microsoft-Windows-BootEvent-Collector/Administration. Pour une interface graphique pour les événements, utilisez l’observateur d'événements. Créez une vue ; développez Journaux des applications et des services, puis Microsoft, puis Windows. Recherchez BootEvent-Collector, développez-le et recherchez Admin.

• Avec Windows PowerShell : Get-WinEvent -LogName Microsoft-Windows-BootEvent-Collector/Admin

• Dans une invite de commandes ordinaire : wevtutil qe Microsoft-Windows-BootEvent-Collector/Administration

Dépannage

Résolution des problèmes d’installation de la fonctionnalité

Résolution des problèmes du collecteur

Enregistrement : le collecteur enregistre ses propres événements en tant que fournisseur ETW Microsoft-Windows-BootEvent-Collector. C’est le premier endroit où vous devez rechercher la résolution des problèmes avec le collecteur. Vous pouvez les trouver dans l’observateur d'événements sous Journaux des applications et des services > Microsoft > Windows > BootEvent-Collector > Administration, ou vous pouvez les lire dans une fenêtre de commande avec l’une des commandes suivantes :

Dans une invite de commandes ordinaire : wevtutil qe Microsoft-Windows-BootEvent-Collector/Administration

Dans une invite Windows PowerShell : Get-WinEvent -LogName Microsoft-Windows-BootEvent-Collector/Admin (vous pouvez ajouter -Oldest pour retourner la liste dans l’ordre chronologique avec d’abord les événements les plus anciens)

Vous pouvez ajuster le niveau de détail dans les journaux à partir de l’erreur, en passant par l’avertissement, les informations (valeur par défaut), les commentaires et le débogage. Les niveaux plus détaillés que les informations sont utiles pour diagnostiquer les problèmes liés aux ordinateurs cibles qui ne se connectent pas, mais ils peuvent générer une grande quantité de données. Utilisez-les donc avec précaution.

Vous définissez le niveau de journalisation minimal dans l’élément <collecteur> du fichier de configuration. Par exemple : <collector configVersionMajor=1 minlog=verbose>.

Le niveau détaillé consigne un enregistrement pour chaque paquet reçu au fur et à mesure de son traitement. Le niveau de débogage ajoute plus de détails de traitement et sauvegarde également le contenu de tous les paquets ETW reçus.

Au niveau du débogage, il peut être utile d’écrire le journal dans un fichier plutôt que d’essayer de l’afficher dans le système de journalisation habituel. Pour ce faire, ajoutez un élément supplémentaire dans l’élément <collecteur> du fichier de configuration :

<collector configVersionMajor=1 minlog=debug log=c:\ProgramData\Microsoft\BootEventCollector\Logs\log.txt>

Une approche suggérée pour résoudre les problèmes liés au collecteur :

1. Tout d’abord, vérifiez que le collecteur a reçu la connexion de la cible (il crée le fichier uniquement lorsque la cible commence à envoyer les messages) avec

   Get-SbecForwarding
   

   S’il retourne qu’il y a une connexion à partir de cette cible, le problème peut se trouver dans les paramètres de l’autologger. S’il ne retourne rien, le problème est lié à la connexion KDNET avec laquelle commencer. Pour diagnostiquer les problèmes de connexion KDNET, essayez de vérifier la connexion à partir des deux extrémités (c’est-à-dire à partir du collecteur et de la cible).

2. Pour afficher les diagnostics étendus à partir du collecteur, ajoutez ceci à l’élément <collecteur> du fichier de configuration : <collecteur ... minlog=verbose>. Cela permet d’activer les messages relatifs à chaque paquet reçu.

3. Vérifiez si des paquets sont reçus. Si vous le souhaitez, vous pouvez écrire le journal en mode détaillé directement dans un fichier plutôt que via ETW. Pour ce faire, ajoutez ceci à l’élément <collector> du fichier de configuration : <collector ... minlog=verbose log=c:\ProgramData\Microsoft\BootEventCollector\Logs\log.txt>

4. Vérifiez dans les journaux des événements les messages concernant les paquets reçus. Vérifiez si des paquets sont reçus. Si les paquets sont reçus mais incorrects, vérifiez les messages d’événement pour plus d’informations.

5. Du côté cible, KDNET écrit des informations de diagnostic dans le registre. Recherchez les messages dans HKLM\SYSTEM\CurrentControlSet\Services\kdnet . KdInitStatus (DWORD) = 0 en cas de réussite et affiche un code d’erreur sur l’erreur KdInitErrorString = explication de l’erreur (contient également des messages d’information si aucune erreur)

6. Exécutez Ipconfig.exe sur la cible et recherchez le nom de l’appareil qu’il signale. Si KDNET a été correctement chargé, le nom de l’appareil doit ressembler à kdnic au lieu du nom de la carte du fournisseur d’origine.

7. Vérifiez si DHCP est configuré pour la cible. KDNET nécessite absolument DHCP.

8. Vérifiez que le collecteur se trouve sur le même réseau que la cible. Si ce n’est pas le cas, vérifiez si le routage est correctement configuré, en particulier le paramètre de passerelle par défaut pour DHCP.

État de la connexion

Vous pouvez consulter la liste actuelle des connexions établies et des informations sur l’emplacement où les données sont transférées avec Get-SbecForwarding.

Vous pouvez également obtenir l’historique récent des modifications d’état dans les connexions avec Get-SbecHistory.

Résolution des problèmes liés à la définition d’une nouvelle configuration

Si vous avez appliqué la configuration avec la commande $result = (Get-Content .\newconfig.xml | Set-SbecActiveConfig); $resultWindows PowerShell$result, la variable contient des informations sur le déploiement. Vous pouvez interroger cette variable pour en obtenir différentes informations :

Obtient des informations sur des erreurs avec $result.ErrorString. Si des erreurs sont signalées ici, la nouvelle configuration n’a pas été appliquée et l’ancienne configuration reste inchangée.

Obtenez des avertissements avec $result.WarningString.

Obtenez des informations sur les détails de la configuration avec $result.InfoString.

Vous pouvez obtenir le résultat complet avec $result | fl *. Sinon, si vous ne souhaitez pas enregistrer le résultat dans une variable, vous pouvez utiliser Get-Content .\newconfig.xml | Set-SbecActiveConfig | fl *.

Résolution des problèmes liés aux ordinateurs cibles