Surveillance et réponse aux événements avec les consommateurs standard
Vous pouvez utiliser les classes de consommateurs standard installées pour effectuer des actions basées sur des événements dans un système d’exploitation. Les consommateurs standard sont des classes simples qui sont déjà inscrites et qui définissent des classes de consommateurs permanentes. Chaque consommateur standard prend une action spécifique après avoir reçu une notification d’événement. Par exemple, vous pouvez définir une instance d’ActiveScriptEventConsumer pour exécuter un script lorsque l’espace disque libre sur un ordinateur est différent d’une taille spécifiée.
WMI compile les consommateurs standard dans des espaces de noms par défaut qui dépendent du système d’exploitation, par exemple :
- Dans Windows Server 2003, tous les consommateurs standard sont compilés par défaut dans l’espace de noms « Root\Subscription ».
Notes
Pour connaître les espaces de noms et systèmes d’exploitation par défaut spécifiques à chaque classe WMI, consultez les sections Remarques et Exigences de chaque rubrique de classe.
Le tableau suivant répertorie et décrit les consommateurs standard WMI.
Consommateur standard | Description |
---|---|
ActiveScriptEventConsumer | Exécute un script lorsqu’il reçoit une notification d’événement. Pour plus d’informations, consultez Exécution d’un script basé sur un événement. |
LogFileEventConsumer | Écrit des chaînes personnalisées dans un fichier journal texte lorsqu’il reçoit une notification d’événement. Pour plus d’informations, consultez Écriture dans un fichier journal basé sur un événement. |
NTEventLogEventConsumer | Consigne un message spécifique dans le journal des événements d’application. Pour plus d’informations, consultez Journalisation dans le journal des événements NT basé sur un événement. |
SMTPEventConsumer | Envoie un e-mail à l’aide de SMTP chaque fois qu’un événement lui est remis. Pour plus d’informations, consultez Envoi d’e-mails basés sur un événement. |
CommandLineEventConsumer | Lance un processus lorsqu’un événement est remis à un système local. Le fichier exécutable doit se trouver dans un emplacement sécurisé ou être sécurisé avec une liste de contrôle d’accès forte (ACL) pour empêcher un utilisateur non autorisé de remplacer votre exécutable par un exécutable différent. Pour plus d’informations, consultez Exécution d’un programme à partir de la ligne de commande basée sur un événement. |
La procédure suivante décrit comment surveiller et répondre aux événements à l’aide d’un consommateur standard. Notez que la procédure est la même pour un fichier, un script ou une application MOF (Managed Object Format).
Pour surveiller et répondre aux événements avec un consommateur standard
Spécifiez l’espace de noms dans un fichier MOF à l’aide de la commande de préprocesseur MOF espace de noms #pragma. Dans un script ou une application, spécifiez l’espace de noms dans le code qui se connecte à WMI.
L’exemple de code MOF suivant montre comment spécifier l’espace de noms root\subscription.
#pragma namespace ("\\\\.\\root\\subscription")
La plupart des événements intrinsèques sont associés aux modifications apportées aux instances de classe dans l’espace de noms root\cimv2. Toutefois, les événements de registre tels que RegistryKeyChangeEvent sont déclenchés dans l’espace de noms racine\default par le fournisseur de registre système.
Un consommateur peut inclure des classes d’événements situées dans d’autres espaces de noms en spécifiant l’espace de noms dans la propriété EventNamespace dans la requête __EventFilter pour les événements. Les classes d’événements intrinsèques, telles que __InstanceOperationEvent sont disponibles dans chaque espace de noms.
Créez et remplissez une instance d’une classe de consommateur standard.
Cette instance peut avoir une valeur unique dans la propriété Name. Vous pouvez mettre à jour un consommateur existant en réutilisant le même nom.
InsertionStringTemplates contient le texte à insérer dans un événement que vous spécifiez dans EventType. Vous pouvez utiliser des chaînes littérales ou faire directement référence à une propriété. Pour plus d’informations, consultez Utilisation de modèles de chaîne standard et SÉLECTIONNEZ déclaration pour les requêtes d’événements.
Utilisez une source existante pour le journal des événements qui prend en charge une chaîne d’insertion sans texte associé.
L’exemple de code MOF suivant montre comment utiliser une source existante de WSH et une valeur EventID de 8.
instance of NTEventLogEventConsumer as $Consumer { Name = "RunKeyEventlogConsumer"; SourceName = "WSH"; EventID = 8; // Warning EventType = 2; // One string supplies the entire message NumberOfInsertionStrings = 1; // the %Hive% and %KeyPath% are properties of // the RegistryKeyChangeEvent instance InsertionStringTemplates = {"The key %Hive%\\%RootPath% has been modified." "Check if the change is intentional"}; };
Créez une instance de __EventFilter et définissez une requête pour les événements.
Dans l’exemple suivant, le filtre surveille la clé de Registre dans laquelle les programmes de démarrage sont inscrits. La surveillance de cette clé de registre peut être importante, car un programme non autorisé peut s’inscrire sous la clé, ce qui entraîne son lancement au démarrage de l’ordinateur.
instance of __EventFilter as $Filter { Name = "RunKeyFilter"; QueryLanguage = "WQL"; Query = "Select * from RegistryTreeChangeEvent" " where (Hive = \"HKEY_LOCAL_MACHINE\" and " "RootPath = \"Software\\\\Microsoft\\\\Windows" "\\\\CurrentVersion\\\\Run\")"; // RegistryTreeChangeEvents only fire in root\default namespace EventNamespace = "root\\default"; };
Identifiez un événement à surveiller et créez une requête d’événement.
Vous pouvez vérifier pour voir s’il existe un événement intrinsèque ou extrinsèque qui l’utilise. Par exemple, utilisez la classe RegistryTreeChangeEvent du fournisseur de registre pour surveiller les modifications apportées au registre système.
S’il n’existe pas de classe qui décrit un événement que vous devez surveiller, vous devez créer votre propre fournisseur d’événements et définir de nouvelles classes d’événements extrinsèques. Pour plus d’informations, consultez Écriture d’un fournisseur d’événements.
Dans un fichier MOF, vous pouvez définir un alias pour le filtre et le consommateur, ce qui permet de décrire facilement les chemins d’accès à l’instance.
L’exemple suivant montre comment définir un alias pour le filtre et le consommateur.
instance of __EventFilter as $FILTER instance of LogFileEventConsumer as $CONSUMER
Créez une instance de __FilterToConsumerBinding pour associer le filtre et les classes consommateur. Cette instance détermine que lorsqu’un événement qui correspond au filtre spécifié se produit, l’action spécifiée par le consommateur doit se produire. __EventFilter, __EventConsumer et __FilterToConsumerBinding doivent avoir le même identificateur de sécurité individuel (SID) dans la propriété CreatorSID . Pour plus d’informations, consultez Liaison d’un filtre d’événements à un consommateur logique.
L’exemple suivant montre comment identifier une instance par le chemin d’accès de l’objet ou utiliser un alias comme expression abrégée pour le chemin d’accès de l’objet.
instance of __EventFilter as $FILTER instance of NTEventLogEventConsumer as $CONSUMER
L’exemple suivant lie le filtre au consommateur à l’aide d’alias.
instance of __FilterToConsumerBinding { Filter = $FILTER; Consumer = $CONSUMER; };
Vous pouvez lier un filtre à plusieurs consommateurs, ce qui indique que lorsque des événements de correspondance se produisent, plusieurs actions doivent être effectuées, ou vous pouvez lier un consommateur à plusieurs filtres, ce qui indique que l’action doit être effectuée lorsque des événements correspondant à l’un des filtres se produisent.
Les actions suivantes sont effectuées en fonction de la condition des consommateurs et des événements :
- Si l’un des consommateurs permanents échoue, les autres consommateurs qui demandent l’événement reçoivent une notification.
- Si un événement est supprimé, WMI déclenche __EventDroppedEvent.
- Si vous vous abonnez à cet événement, il retourne l’événement qui est supprimé et une référence à __EventConsumer représente le consommateur ayant échoué.
- Si un consommateur échoue, WMI déclenche __ConsumerFailureEvent, qui peut contenir plus d’informations dans les propriétés ErrorCode, ErrorDescription et ErrorObject.
Pour plus d’informations, consultez Liaison d’un filtre d’événements à un consommateur logique.
Exemple
L’exemple suivant montre le MOF d’une instance de NTEventLogEventConsumer. Après avoir compilé ce MOF, toute tentative de création, de suppression ou de modification d’une valeur dans le chemin du registre HKEY_LOCAL_MACHINE\ Software\Microsoft\Windows\CurrentVersion\Run enregistre une entrée dans le journal des événements application, sous la source « WSH ».
#pragma namespace ("\\\\.\\root\\subscription")
instance of __EventFilter as $Filter
{
Name = "RunKeyFilter";
QueryLanguage = "WQL";
Query = "Select * from RegistryTreeChangeEvent"
" where (Hive = \"HKEY_LOCAL_MACHINE\" and "
"KeyPath = \"Software\\\\Microsoft\\\\Windows"
"\\\\CurrentVersion\\\\Run\")";
// RegistryTreeChangeEvents only fire
// in root\default namespace
EventNamespace = "root\\default";
};
instance of NTEventLogEventConsumer as $Consumer
{
Name = "RunKeyEventlogConsumer";
SourceName = "WSH";
EventID = 8;
EventType = 2; // Warning
Category = 0;
NumberOfInsertionStrings = 1;
// the %Hive% and %KeyPath% are properties
// of the RegistryKeyChangeEvent instance
InsertionStringTemplates = {"The key %Hive%\\%RootPath% "
"has been modified. Check if the change is intentional"};
};
// Bind the filter to the consumer
instance of __FilterToConsumerBinding
{
Filter = $Filter;
Consumer = $Consumer;
};
Rubriques connexes