Surveillance et réponse aux événements avec des consommateurs standard
Vous pouvez utiliser les classes de consommateur standard installées pour effectuer des actions basées sur les événements d’un système d’exploitation. Les consommateurs standard sont des classes simples qui sont déjà inscrites et qui définissent des classes de consommateur permanentes. Chaque consommateur standard prend une mesure spécifique après avoir reçu une notification d’événement. Par exemple, vous pouvez définir une instance de 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 « abonnement racine ».
Notes
Pour les espaces de noms et les systèmes d’exploitation par défaut spécifiques à chaque classe WMI, consultez les sections remarques et exigences de chaque 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 | Enregistre un message spécifique dans le journal des événements de l’application. Pour plus d’informations, consultez journalisation dans le journal des événements NT basé sur un événement. |
| SMTPEventConsumer | Envoie un message électronique à l’aide du protocole SMTP à chaque fois qu’un événement lui est remis. Pour plus d’informations, consultez envoi de courriers électroniques en fonction d’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 sécurisé avec une liste de contrôle d’accès (ACL) forte pour empêcher un utilisateur non autorisé de remplacer votre exécutable par un autre exécutable. Pour plus d’informations, consultez exécution d’un programme à partir de la ligne de commande en fonction d’un événement. |
La procédure suivante décrit comment surveiller les événements et y répondre à l’aide d’un consommateur standard. Notez que la procédure est la même pour un fichier, un script ou une application format MOF (MOF).
Pour surveiller les événements et y répondre à l’aide d’un consommateur standard
Spécifiez l’espace de noms dans un fichier MOF à l’aide de l' # espace de noms du pragmade commande du préprocesseur MOF. 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 de l' \ abonnement racine.
#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 CIMV2 racine. Toutefois, les événements de Registre tels que RegistryKeyChangeEvent sont déclenchés dans l' \ espace de noms racine par défaut 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 de 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éer et remplir 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 instruction SELECT pour les requêtes d’événement.
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 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 analyse 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’enregistrer 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 pour surveiller et créer une requête d’événement.
Vous pouvez vérifier s’il existe un événement intrinsèque ou extrinsèque qui utilise. Par exemple, utilisez la classe RegistryTreeChangeEvent du fournisseur Registry 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 fournit un moyen simple de décrire les chemins d’accès d’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 $CONSUMERCréez une instance de _ _ FilterToConsumerBinding pour associer le filtre et les classes de 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, _ _ EventConsumeret _ _ FilterToConsumerBinding doivent avoir le même identificateur de sécurité (SID) individuel 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 $CONSUMERL’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 correspondants se produisent, plusieurs actions doivent être effectuées ; vous pouvez ou lier un consommateur à plusieurs filtres, ce qui indique que l’action doit être effectuée lorsque des événements qui correspondent à 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.
- En cas de suppression d’un événement, 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 qui a échoué.
- En cas de défaillance d’un consommateur, 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 fichier MOF pour une instance de NTEventLogEventConsumer. une fois que vous avez compilé ce fichier MOF, toute tentative de création, de suppression ou de modification d’une valeur dans le chemin d’accès au registre HKEY _ LOCAL _ MACHINE \ Software \ Microsoft \ Windows \ CurrentVersion \ Run enregistre une entrée dans le journal des événements de l’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;
};