Мониторинг и реагирование на события с помощью стандартных потребителей

Установленные стандартные классы потребителей можно использовать для выполнения действий на основе событий в операционной системе. Стандартные потребители — это простые классы, которые уже зарегистрированы и определяют постоянные классы потребителей. Каждый стандартный потребитель выполняет определенное действие после получения уведомления о событии. Например, можно определить экземпляр ActiveScriptEventConsumer для выполнения скрипта, если свободное место на диске на компьютере отличается от указанного размера.

WMI компилирует стандартные потребители в пространства имен по умолчанию, которые зависят от операционной системы, например:

  • В Windows Server 2003 все стандартные потребители компилируются по умолчанию в пространство имен Root\Subscription.

Примечание

Пространства имен по умолчанию и операционные системы, относящиеся к каждому классу WMI, см. в разделах Примечания и требования каждого класса.

 

В следующей таблице перечислены и описаны стандартные потребители WMI.

Стандартный потребитель Описание
ActiveScriptEventConsumer Выполняет скрипт при получении уведомления о событии. Дополнительные сведения см. в разделе Выполнение скрипта на основе события.
LogFileEventConsumer Записывает настраиваемые строки в текстовый файл журнала при получении уведомления о событии. Дополнительные сведения см. в разделе Запись в файл журнала на основе события.
NTEventLogEventConsumer Записывает определенное сообщение в журнал событий приложения. Дополнительные сведения см. в разделе Ведение журнала событий NT на основе события.
SMTPEventConsumer Отправляет сообщение электронной почты с помощью SMTP при каждой доставке события. Дополнительные сведения см. в разделе Отправка Email на основе события.
CommandLineEventConsumer Запускает процесс при доставке события в локальную систему. Исполняемый файл должен находиться в безопасном расположении или быть защищен строгим списком управления доступом (ACL), чтобы предотвратить несанкционированный пользователь от замены исполняемого файла другим исполняемым файлом. Дополнительные сведения см. в разделе Запуск программы из командной строки на основе события.

 

В следующей процедуре описывается мониторинг событий и реагирование на них с помощью стандартного потребителя. Обратите внимание, что процедура одинакова для MOF-файла, скрипта или приложения.

Мониторинг событий со стандартным потребителем и реагирование на них

  1. Укажите пространство имен в MOF-файле с помощью команды препроцессора MOF #pragma пространства имен. В скрипте или приложении укажите пространство имен в коде, который подключается к инструментарию WMI.

    В следующем примере кода MOF показано, как указать пространство имен root\subscription.

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

    Большинство встроенных событий связаны с изменениями экземпляров класса в пространстве имен root\cimv2. Однако события реестра, такие как RegistryKeyChangeEvent , активируются в корневом пространстве имен по умолчанию поставщиком системного реестра.

    Потребитель может включать классы событий, расположенные в других пространствах имен, указав пространство имен в свойстве EventNamespace в запросе __EventFilter событий. Классы встроенных событий , такие как __InstanceOperationEvent , доступны в каждом пространстве имен.

  2. Создание и заполнение экземпляра класса стандартного потребителя.

    Этот экземпляр может иметь уникальное значение в свойстве Name . Вы можете обновить существующий потребитель, повторно указав то же имя.

    InsertionStringTemplates содержит текст для вставки в событие, указанное в eventType. Можно использовать литеральные строки или ссылаться непосредственно на свойство. Дополнительные сведения см. в разделе Использование стандартных строковых шаблонов и инструкции SELECT для запросов событий.

    Используйте существующий источник для журнала событий, который поддерживает строку вставки без связанного текста.

    В следующем примере кода MOF показано, как использовать существующий источник WSH и значение 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"};
    };
    
  3. Создайте экземпляр __EventFilter и определите запрос для событий.

    В следующем примере фильтр отслеживает раздел реестра, в котором регистрируются программы запуска. Мониторинг этого раздела реестра может быть важен, так как неавторизованная программа может зарегистрировать себя в разделе , что приводит к ее запуску при загрузке компьютера.

    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. Определите отслеживаемое событие и создайте запрос на событие.

    Вы можете проверка, чтобы узнать, есть ли встроенное или внешние события, которые используют. Например, используйте класс RegistryTreeChangeEvent поставщика registry для отслеживания изменений системного реестра.

    Если не существует класса, описывающего событие, которое необходимо отслеживать, необходимо создать собственный поставщик событий и определить новые классы событий extrinsic. Дополнительные сведения см. в разделе Запись поставщика событий.

    В MOF-файле можно определить псевдоним для фильтра и потребителя, что позволяет легко описать пути к экземплярам.

    В следующем примере показано, как определить псевдоним для фильтра и потребителя.

    instance of __EventFilter as $FILTER
    instance of LogFileEventConsumer as $CONSUMER
    
  5. Создайте экземпляр __FilterToConsumerBinding , чтобы связать классы фильтра и потребителя. Этот экземпляр определяет, что при возникновении события, соответствующего указанному фильтру, должно произойти действие, указанное потребителем. __EventFilter, __EventConsumer и __FilterToConsumerBinding должны иметь один и тот же идентификатор безопасности (SID) в свойстве CreatorSID . Дополнительные сведения см. в разделе Привязка фильтра событий к логическому потребителю.

    В следующем примере показано, как идентифицировать экземпляр по пути объекта или использовать псевдоним в качестве сокращенного выражения для пути объекта.

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

    В следующем примере фильтр привязывается к потребителю с помощью псевдонимов.

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

    Можно привязать один фильтр к нескольким потребителям, что указывает на то, что при возникновении соответствующих событий необходимо выполнить несколько действий; или можно привязать одного потребителя к нескольким фильтрам, что указывает, что действие должно выполняться при возникновении событий, соответствующих одному из фильтров.

    Следующие действия выполняются в зависимости от условий потребителей и событий:

    • Если один из постоянных потребителей завершается сбоем, другие потребители, запрашивающие событие, получают уведомление.
    • Если событие удаляется, инструментарий WMI запускает __EventDroppedEvent.
    • Если вы подписываетесь на это событие, оно возвращает отброшенное событие, а ссылка на __EventConsumer представляет потребителя, завершившемся сбоем.
    • Если происходит сбой потребителя, инструментарий WMI запускает __ConsumerFailureEvent, который может содержать дополнительные сведения в свойствах ErrorCode, ErrorDescription и ErrorObject .

    Дополнительные сведения см. в разделе Привязка фильтра событий к логическому потребителю.

Пример

В следующем примере показан MOF-файл для экземпляра NTEventLogEventConsumer. После компиляции этого MOF-файла любая попытка создать, удалить или изменить значение в пути к реестру HKEY_LOCAL_MACHINE\ Software\Microsoft\Windows\CurrentVersion\Run записывает запись в журнал событий приложения в исходном коде 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;
};

Безопасный прием событий