Überwachen von Ereignissen und Reagieren auf Ereignisse mit Standardconsumern
Sie können die installierten Standardconsumerklassen verwenden, um Aktionen basierend auf Ereignissen in einem Betriebssystem auszuführen. Standardconsumer sind einfache Klassen, die bereits registriert sind, und sie definieren permanente Consumerklassen. Jeder Standardconsumer führt eine bestimmte Aktion aus, nachdem er eine Ereignisbenachrichtigung empfangen hat. Sie können beispielsweise eine Instanz von ActiveScriptEventConsumer definieren, um ein Skript auszuführen, wenn sich der freie Speicherplatz auf einem Computer von einer angegebenen Größe unterscheidet.
WMI kompiliert die Standardconsumer in Standardnamespaces, die vom Betriebssystem abhängen, z. B.:
- In Windows Server 2003 werden alle Standardconsumer standardmäßig in den Namespace „Root\Subscription“ kompiliert.
Hinweis
Informationen zu den Standardnamespaces und Betriebssystemen, die für die jeweilige WMI-Klasse spezifisch sind, finden Sie in den Themen der einzelnen Klassen in den Abschnitten „Hinweise“ und „Anforderungen“.
In der folgenden Tabelle werden die WMI-Standardconsumer aufgeführt und beschrieben.
Standardconsumer | BESCHREIBUNG |
---|---|
ActiveScriptEventConsumer | Führt ein Skript aus, wenn er eine Ereignisbenachrichtigung empfängt. Weitere Informationen finden Sie unter Ausführen eines Skripts basierend auf einem Ereignis. |
LogFileEventConsumer | Schreibt benutzerdefinierte Zeichenfolgen in eine Textprotokolldatei, wenn er eine Ereignisbenachrichtigung empfängt. Weitere Informationen finden Sie unter Schreiben in eine Protokolldatei basierend auf einem Ereignis. |
NTEventLogEventConsumer | Protokolliert eine bestimmte Nachricht im Anwendungsereignisprotokoll. Weitere Informationen finden Sie unter Protokollierung im NT-Ereignisprotokoll basierend auf einem Ereignis. |
SMTPEventConsumer | Sendet bei jeder Übermittlung eines Ereignisses eine E-Mail-Nachricht mithilfe von SMTP. Weitere Informationen finden Sie unter Senden von E-Mail basierend auf einem Ereignis. |
CommandLineEventConsumer | Startet einen Prozess, wenn ein Ereignis an ein lokales System übermittelt wird. Die ausführbare Datei muss sich an einem sicheren Ort befinden oder mit einer strengen Zugriffssteuerungsliste (ACL) gesichert sein, um zu verhindern, dass ein unbefugter Benutzer Ihre ausführbare Datei durch eine andere Datei ersetzt. Weitere Informationen finden Sie unter Ausführen eines Programms über die Befehlszeile basierend auf einem Ereignis. |
Im folgenden Verfahren wird beschrieben, wie Sie mithilfe eines StandardConsumers Ereignisse überwachen und darauf reagieren können. Beachten Sie, dass das Verfahren für eine MOF-Datei (Managed Object Format), ein Skript oder eine Anwendung dasselbe ist.
So überwachen Sie Ereignisse mit einem Standardconsumer und reagieren darauf
Geben Sie den Namespace in einer MOF-Datei mithilfe des MOF-Präprozessorbefehls #pragma namespace an. Geben Sie in einem Skript oder einer Anwendung den Namespace im Code an, der eine Verbindung mit WMI herstellt.
Im folgenden MOF-Codebeispiel wird gezeigt, wie der Namespace root\subscription angegeben wird.
#pragma namespace ("\\\\.\\root\\subscription")
Die meisten systeminternen Ereignisse sind Änderungen an Klasseninstanzen im Namespace root\cimv2 zugeordnet. Registrierungsereignisse wie RegistryKeyChangeEvent werden jedoch im Namespace root\default durch den Systemregistrierungsanbieter ausgelöst.
Ein Consumer kann Ereignisklassen einschließen, die sich in anderen Namespaces befinden, indem er den Namespace in der EventNamespace-Eigenschaft in der __EventFilter-Abfrage für Ereignisse angibt. Die systeminternen Ereignisklassen (z. B. __InstanceOperationEvent) sind in jedem Namespace verfügbar.
Erstellen Sie eine Instanz einer Standardconsumerklasse, und füllen Sie sie mit Daten auf.
Diese Instanz kann einen eindeutigen Wert in der Name-Eigenschaft aufweisen. Sie können einen vorhandenen Consumer aktualisieren, indem Sie denselben Namen wiederverwenden.
InsertStringTemplates enthält den Text, der in ein Ereignis eingefügt werden soll, das Sie in EventType angeben. Sie können Literalzeichenfolgen verwenden oder direkt auf eine Eigenschaft verweisen. Weitere Informationen finden Sie unter Verwenden von Standardzeichenfolgenvorlagen und SELECT-Anweisung für Ereignisabfragen.
Verwenden Sie eine vorhandene Quelle für das Ereignisprotokoll, die eine Einfügezeichenfolge ohne zugeordneten Text unterstützt.
Das folgende MOF-Codebeispiel zeigt, wie Sie eine vorhandene Quelle von WSH und einen EventID-Wert von 8 verwenden.
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"}; };
Erstellen Sie eine Instanz von __EventFilter, und definieren Sie eine Abfrage für Ereignisse.
Im folgenden Beispiel überwacht der Filter den Registrierungsschlüssel, in dem Startprogramme registriert werden. Die Überwachung dieses Registrierungsschlüssels kann wichtig sein, weil sich ein nicht autorisiertes Programm selbst unter dem Schlüssel registrieren kann, was dazu führt, dass es gestartet wird, wenn der Computer gestartet wird.
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"; };
Identifizieren Sie ein zu überwachende Ereignis, und erstellen Sie eine Ereignisabfrage.
Sie können überprüfen, ob ein systeminternes oder extrinsisches Ereignis verwendet wird. Verwenden Sie beispielsweise die RegistryTreeChangeEvent-Klasse des Registrierungsanbieters, um Änderungen an der Systemregistrierung zu überwachen.
Wenn keine Klasse vorhanden ist, die ein Ereignis beschreibt, das Sie überwachen müssen, müssen Sie einen eigenen Ereignisanbieter erstellen und neue extrinsische Ereignisklassen definieren. Weitere Informationen finden Sie unter Schreiben eines Ereignisanbieters.
In einer MOF-Datei können Sie einen Alias für den Filter und Consumer definieren, wodurch die Instanzpfade auf einfache Weise beschrieben werden können.
Das folgende Beispiel zeigt, wie Sie einen Alias für den Filter und Consumer definieren.
instance of __EventFilter as $FILTER instance of LogFileEventConsumer as $CONSUMER
Erstellen Sie eine Instanz von __FilterToConsumerBinding, um den Filter und die Consumerklassen zuzuordnen. Diese Instanz bestimmt, dass die vom Consumer angegebene Aktion auftreten muss, wenn ein Ereignis auftritt, das dem angegebenen Filter entspricht. __EventFilter, __EventConsumer und __FilterToConsumerBinding müssen dieselbe individuelle Sicherheits-ID (SID) in der CreatorSID-Eigenschaft aufweisen. Weitere Informationen finden Sie unter Binden eines Ereignisfilters mit einem logischen Consumer.
Im folgenden Beispiel wird gezeigt, wie Sie eine instance anhand des Objektpfads identifizieren oder einen Alias als Kurzausdruck für den Objektpfad verwenden.
instance of __EventFilter as $FILTER instance of NTEventLogEventConsumer as $CONSUMER
Im folgenden Beispiel wird der Filter mithilfe von Aliasen an den Consumer gebunden.
instance of __FilterToConsumerBinding { Filter = $FILTER; Consumer = $CONSUMER; };
Sie können einen Filter an mehrere Consumer binden, was bedeutet, dass beim Auftreten übereinstimmender Ereignisse mehrere Aktionen ausgeführt werden müssen. Oder Sie können einen Consumer an mehrere Filter binden, was bedeutet, dass die Aktion ausgeführt werden muss, wenn Ereignisse auftreten, die einem der Filter entsprechen.
Die folgenden Aktionen werden basierend auf der Bedingung von Consumern und Ereignissen ausgeführt:
- Wenn einer der permanenten Consumer fehlschlägt, erhalten andere Consumer, die das Ereignis anfordern, eine Benachrichtigung.
- Wenn ein Ereignis verworfen wird, löst WMI __EventDroppedEvent aus.
- Wenn Sie dieses Ereignis abonnieren, wird das verworfene Ereignis zurückgegeben, und ein Verweis auf den __EventConsumer stellt den fehlerhaften Consumer dar.
- Wenn ein Consumer fehlschlägt, löst WMI __ConsumerFailureEvent aus, das weitere Informationen in den Eigenschaften ErrorCode, ErrorDescription und ErrorObject enthalten kann.
Weitere Informationen finden Sie unter Binden eines Ereignisfilters mit einem logischen Consumer.
Beispiel
Das folgende Beispiel zeigt die MOF-Datei für eine Instanz von NTEventLogEventConsumer. Nachdem Sie diese MOF-Datei kompiliert haben, protokolliert jeder Versuch, einen Wert im Registrierungspfad HKEY_LOCAL_MACHINE\ Software\Microsoft\Windows\CurrentVersion\Run zu erstellen, zu löschen oder zu ändern, einen Eintrag im Anwendungsereignisprotokoll unter der Quelle „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;
};
Zugehörige Themen