Типы событий WMI и способы их обработки

Итак, приступим к изучению расширенных возможностей WMI. Для того чтобы рассказ об этой теме был более предметным, возьмем конкретную практическую задачу и рассмотрим ее решение поэтапно. Остановимся на задаче отслеживания событий подключения/отключения съемных дисковых устройств USB и реакции на них. Во многих организациях съемные устройства (в основном USB FlashDrive) являются головной болью для службы безопасности и администраторов. Обычно проблемы, связанные с несанкционированным применением пользователями съемных устройств памяти, довольно эффективно решают с помощью различного дополнительного ПО (например, DeviceLock). Мы же попробуем решить часть из них стандартными средствам WMI. Наша цель – зафиксировать факт события подключения таких устройств и выполнить некоторое ответное действие (например, сценарий VBScript).

Для начала давайте рассмотрим простой пример кода на VBScript, использующего WMI для синхронного отслеживания событий подключения съемных дисковых устройств. Он послужит нам отправной точкой в данной работе. Этот пример приведен на листинге 1. Попробуйте запустить этот сценарий командой cscript <имя сценария> и посмотреть на результат его работы при подключении устройств USB FlashDrive.

Листинг 1. Пример сценария синхронного отслеживания подключения устройств USB

strComputer = "."

Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\CIMV2")

Set objEvents = objWMIService.ExecNotificationQuery _

("SELECT * FROM __InstanceCreationEvent WITHIN 5 WHERE " & _

"TargetInstance ISA 'Win32_LogicalDisk'" & _

" AND TargetInstance.DriveType = 2")

Wscript.Echo "Ожидаем события ..."

Do While(True)

Set objReceivedEvent = objEvents.NextEvent

Wscript.Echo "Name: " & objReceivedEvent.TargetInstance.Name

Wscript.Echo "Caption: " & objReceivedEvent.TargetInstance.Caption

Wscript.Echo "FileSystem: " & objReceivedEvent.TargetInstance.FileSystem

Wscript.Echo "Description: " & objReceivedEvent.TargetInstance.Description

Loop

Теперь давайте чуть подробнее разберем этот пример. Первые две строки служат для подключения к репозиторию WMI и не вызывают особого интереса. Третий же оператор сценария представляет для нас существенный интерес. Здесь мы вызываем метод ExecNotificationQuery объекта objWMIService (он принадлежит к классу SWbemServices), который регистрирует временный подписчик на события WMI. Этот метод возвращает нам специальный объект-подписчик, который по заданным нами критериям следит за событиями WMI. Этот объект мы сохраняем в переменной objEvents. У класса SWbemServices также существует второй метод регистрации временного подписчика на события WMI, который называется ExecNotificationQueryAsync. Этот метод позволяет регистрировать временные подписчики для асинхронной обработки событий WMI, о нем мы поговорим чуть-чуть позже.

Рассмотрим внимательнее WQL-запрос, с помощью которого наш сценарий подписывается на события WMI. Для того чтобы получать уведомления об интересующих нас событиях, мы делаем выборку объектов специального класса __InstanceCreationEvent, который служит для отслеживания внутренних событий WMI, возникающих при создании экземпляров объектов любого класса, зарегистрированного в репозитории WMI. Заметим, что существуют и другие специальные классы отслеживания внутренних событий WMI, например: __InstanceDeletionEvent, __InstanceModificationEvent, __InstanceOperationEvent или __ClassCreationEvent, __ClassDeletionEvent и другие. Довольно очевидно из их названия, для отслеживания каких именно внутренних событий WMI эти специальные классы созданы.

Далее обратим внимание на ключевое слово WITHIN в запросе WQL – в отличие от обычного языка SQL ключевое слово WITHIN в языке WQL определяет интервал опроса приходящих событий в секундах или служит для группировки событий (в сочетании с ключевым словом GROUP) в течение указанного количества секунд.

В нашем конкретном случае временный подписчик событий WMI – это объект, который мы получаем в переменную objEvents в результате вызова метода ExecNotificationQuery. Он будет каждые 5 секунд осуществлять проверку всех событий WMI по созданию экземпляров объектов, соответствующих критериям, заданным после ключевого слова WHERE, а именно: отслеживать появление новых объектов класса Win32_LogicalDisk, у которых свойство DriveType равно 2.

Закончим разбор сценария анализом цикла ожидания событий. Вполне очевидно, что сам по себе цикл бесконечный и условия завершения не имеет. Внутри тела цикла вызывается метод NextEvent нашего экземпляра объекта objEvents – временного подписчика на события WMI. Этот метод возвращает управление VBS-сценарию в тот момент, когда в системе происходит событие WMI, соответствующее условиям, заданным при создании объекта-подписчика. Возвращаемый этим методом объект является объектом-описателем происшедшего события и имеет свойства TargetInstance и TIME_CREATED. Свойство TargetInstance содержит не что иное как ссылку на экземпляр объекта, вызвавшего это событие.

Теперь необходимо обратить наше пристальное внимание на тот факт, что существуют два типа событий WMI. Внутренние (системные) события WMI и внешние (чуждые). Эти типы событий принципиально отличаются по своему происхождению, обслуживаются разными группами классов WMI и, как следствие, отличаются по некоторым приемам работы с ними. Все внутренние (intrinsic) классы отслеживания событий WMI выведены непосредственно из абстрактного класса __Event, а вот все внешние (extrinsic) классы событий выведены из класса __ExtrinsicEvent, который уже в свою очередь выведен из класса __Event.

По сути дела за генерацию событий, доступ к которым обеспечивают классы внутренних событий, отвечает само ядро службы WMI, а за генерацию событий, доступ к которым обеспечивают классы внешних событий, отвечают уже WMI-провайдеры. Таким образом, если мы хотим отслеживать события WMI, используя внутренние механизмы службы WMI, то мы будем пользоваться универсальными внутренними (intrinsic) классами. Если же интересующий нас WMI-провайдер предоставляет свои собственные (внешние) классы отслеживания событий, то использовать следует именно их, так как они по определению будут работать эффективнее.

К сожалению, далеко не все провайдеры предоставляют достаточный набор собственных внешних классов для отслеживания событий. Обратим внимание на тот факт, что у всех внутренних классов отслеживания событий существует свойство TargetInstance, но его нет у внешних классов отслеживания событий WMI. Зато, как правило, внешние классы, отслеживающие внешние события WMI, обладают довольно широким дополнительным набором атрибутов, позволяющим легко устанавливать источник этого события.

Также надо заметить, что ключевое слово WITHIN языка WQL, позволяющее подписчику устанавливать интервал опроса экземпляров внутренних классов отслеживания событий, не требуется использовать с внешними классами отслеживания событий.