Udostępnij za pośrednictwem

Monitorowanie zdarzeń i reagowanie na nie za pomocą użytkowników standardowych

  • Artykuł

Można użyć zainstalowanych standardowych klas konsumentów do wykonywania działań na podstawie zdarzeń w systemie operacyjnym. Odbiorcy standardowi to proste klasy, które są już zarejestrowane i definiują trwałe klasy odbiorców. Każdy użytkownik standardowy podejmuje określoną akcję po otrzymaniu powiadomienia o zdarzeniu. Można na przykład zdefiniować wystąpienie ActiveScriptEventConsumer, aby wykonać skrypt, gdy wolne miejsce na dysku na komputerze różni się od określonego rozmiaru.

WMI kompiluje standardowych odbiorców do domyślnych przestrzeni nazw, które są zależne od systemu operacyjnego, na przykład:

  • W systemie Windows Server 2003 wszyscy standardowi odbiorcy są domyślnie kompilowani do przestrzeni nazw "Root\Subscription".

Notatka

Aby zapoznać się z domyślnymi przestrzeniami nazw i systemami operacyjnymi specyficznymi dla każdej klasy WMI, zobacz sekcje Uwagi i wymagania każdego tematu klasy.

 

W poniższej tabeli wymieniono i opisano standardowych użytkowników usługi WMI.

Użytkownik standardowy Opis
ActiveScriptEventConsumer Wykonuje skrypt po odebraniu powiadomienia o zdarzeniu. Aby uzyskać więcej informacji, zobacz Uruchamianie skryptu na podstawie zdarzenia.
LogFileEventConsumer Zapisuje dostosowane ciągi do pliku dziennika tekstowego po otrzymaniu powiadomienia o zdarzeniu. Aby uzyskać więcej informacji, zobacz Zapisywanie w pliku dziennika na podstawie zdarzenia.
NTEventLogEventConsumer Rejestruje określony komunikat w dzienniku zdarzeń aplikacji. Aby uzyskać więcej informacji, zobacz Rejestrowanie w dzienniku zdarzeń NT na podstawie zdarzenia.
SMTPEventConsumer Wysyła wiadomość e-mail przy użyciu protokołu SMTP za każdym razem, gdy zdarzenie jest do niego dostarczane. Aby uzyskać więcej informacji, zobacz Wysyłanie wiadomości e-mail na podstawie zdarzenia.
CommandLineEventConsumer Uruchamia proces, gdy zdarzenie jest dostarczane do systemu lokalnego. Plik wykonywalny musi znajdować się w bezpiecznej lokalizacji lub zabezpieczony za pomocą silnej listy kontroli dostępu (ACL), aby uniemożliwić nieautoryzowanemu użytkownikowi zastąpienie pliku wykonywalnego innym plikiem wykonywalnym. Aby uzyskać więcej informacji, zobacz Uruchamianie programu z wiersza poleceń na podstawie zdarzenia.

 

Poniższa procedura opisuje sposób monitorowania zdarzeń i reagowania na nie przy użyciu standardowego konsumenta. Należy pamiętać, że procedura jest taka sama w przypadku pliku, skryptu lub aplikacji w formacie zarządzanego obiektu (MOF).

Aby monitorować zdarzenia i na nie reagować przy użyciu standardowego konsumenta

  1. Określ namespace w pliku MOF przy użyciu dyrektywy preprocesora MOF #pragma namespace. W skrycie lub aplikacji określ przestrzeń nazw w kodzie, który łączy się z usługą WMI.

    Poniższy przykład kodu MOF pokazuje, jak określić przestrzeń nazw root\subscription.

    #pragma namespace ("\\\\.\\root\\subscription")

    Większość zdarzeń wewnętrznych jest związana ze zmianami instancji klas w przestrzeni nazw root\cimv2. Jednak zdarzenia rejestru, takie jak RegistryKeyChangeEvent są wyzwalane w głównej\domyślnej przestrzeni nazw przez dostawcę rejestru systemu .

    Użytkownik może uwzględnić klasy zdarzeń znajdujące się w innych przestrzeniach nazw, określając przestrzeń nazw w właściwości EventNamespace w zapytaniu __EventFilter. Zdarzenia wewnętrzne klasy , takie jak __InstanceOperationEvent, są dostępne w każdej przestrzeni nazw.

  2. Utwórz i wypełnij instancję typowej klasy konsumenta.

    To wystąpienie może mieć unikatową wartość w właściwości Nazwa. Możesz zaktualizować istniejącego konsumenta, ponownie używając tej samej nazwy.

    InsertionStringTemplates zawiera tekst, który należy wstawić w zdarzenie określone przez użytkownika w EventType. Możesz użyć ciągów znaków lub odwołać się bezpośrednio do właściwości. Aby uzyskać więcej informacji, zobacz Wykorzystanie standardowych szablonów znaków i Instrukcję SELECT dla zapytań o zdarzenia.

    Użyj istniejącego źródła dla dziennika zdarzeń, które obsługuje ciąg wstawiania bez skojarzonego tekstu.

    Poniższy przykład kodu MOF pokazuje, jak używać istniejącego źródła WSH i wartości EventID równą 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"};
};

  3. Utwórz wystąpienie __EventFilter i zdefiniuj zapytanie dotyczące zdarzeń.

    W poniższym przykładzie filtr monitoruje klucz rejestru, w którym są rejestrowane programy uruchamiania. Monitorowanie tego klucza rejestru może być ważne, ponieważ nieautoryzowany program może zarejestrować się w kluczu, co powoduje jego uruchomienie podczas rozruchu komputera.

    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";                       
};

  4. Zidentyfikuj zdarzenie do monitorowania i tworzenia zapytania o zdarzenie.

    Możesz sprawdzić, czy istnieje wewnętrzne lub zewnętrzne zdarzenie, które używa. Na przykład użyj klasy RegistryTreeChangeEvent dostawcy rejestru , aby monitorować zmiany w rejestrze systemowym.

    Jeśli nie istnieje klasa, która opisuje zdarzenie, które należy monitorować, musisz utworzyć własne źródło zdarzeń i zdefiniować nowe klasy zdarzeń zewnętrznych. Aby uzyskać więcej informacji, zobacz Tworzenie dostawcy zdarzeń.

    W pliku MOF można zdefiniować alias dla filtru i odbiorcy, co zapewnia łatwy sposób opisywania ścieżek wystąpienia.

    W poniższym przykładzie pokazano, jak zdefiniować alias dla filtru i odbiorcy.

    instance of __EventFilter as $FILTER
instance of LogFileEventConsumer as $CONSUMER

  5. Utwórz wystąpienie __FilterToConsumerBinding, aby skojarzyć filtr i klasy odbiorców. To wystąpienie określa, że w przypadku wystąpienia zdarzenia zgodnego z określonym filtrem musi wystąpić akcja określona przez użytkownika. __EventFilter, __EventConsumeri __FilterToConsumerBinding muszą mieć ten sam indywidualny identyfikator zabezpieczeń (SID) we właściwości CreatorSID. Aby uzyskać więcej informacji, zobacz Wiązanie filtru zdarzeń z logicznym odbiorcą.

    W poniższym przykładzie pokazano, jak zidentyfikować wystąpienie według ścieżki obiektu lub użyć aliasu jako skrótu dla ścieżki obiektu.

    instance of __EventFilter as $FILTER
instance of NTEventLogEventConsumer as $CONSUMER

    W poniższym przykładzie filtr jest powiązany z odbiorcą przy użyciu aliasów.

    instance of __FilterToConsumerBinding
{
    Filter = $FILTER;
    Consumer = $CONSUMER;

};

    Można powiązać jeden filtr z kilkoma odbiorcami, co wskazuje, że podczas dopasowywania zdarzeń należy wykonać kilka akcji; lub można powiązać jednego konsumenta z kilkoma filtrami, co wskazuje, że akcja musi zostać podjęta, gdy wystąpią zdarzenia zgodne z jednym z filtrów.

    Następujące działania są podejmowane na podstawie stanu konsumentów i zdarzeń:

    • Jeśli jeden z stałych odbiorców ulegnie awarii, inni konsumenci proszący o zdarzenie otrzymują powiadomienie.
    • Jeśli zdarzenie zostanie usunięte, WMI generuje __EventDroppedEvent.
    • Jeśli zapiszesz się na to zdarzenie, zwraca ono zdarzenie, które zostało usunięte, oraz referencję do __EventConsumer, która reprezentuje nieudanego konsumenta.
    • Jeśli użytkownik ulegnie awarii, usługa WMI uruchomi __ConsumerFailureEvent, która może zawierać więcej informacji we właściwościach ErrorCode, ErrorDescription i ErrorObject.

    Aby uzyskać więcej informacji, zobacz Wiązanie filtru zdarzeń z odbiorcą logicznym.

Przykład

Poniższy przykład przedstawia MOF dla wystąpienia NTEventLogEventConsumer. Po skompilowaniu tego MOF każda próba utworzenia, usunięcia lub zmodyfikowania wartości w ścieżce rejestru HKEY_LOCAL_MACHINE\ Software\Microsoft\Windows\CurrentVersion\Run zapisuje wpis w dzienniku zdarzeń aplikacji pod źródłem "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;
};

bezpieczne odbieranie zdarzeń