В отличие от внутренних и внешних событий WMI, события таймера, кото­рые могут происходить либо один раз в определенное время, либо несколь­ко раз через заданные интервалы времени, настраиваются самим потребите­лем событий. Извещения о событиях таймера могут быть получены в любом пространстве имен.

6.8.4 Временные и постоянные потребители событий

В WMI могут быть зарегистрированы потребители событий двух видов: вре­менные и постоянные.

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

Нас в качестве временных потребителей событий будут интересовать сцена­рии WSH. Подписка на события здесь осуществляется, как было описано ранее, с помощью специальных WQL-запросов, которые выполняются путем вызова методов ExecNotificationQuery (для внутреннего события) или ExecNotificationQueryAsync (для внешнего события) класса SWbemServices. После такой регистрации в WMI внутреннего события сценарий с помощью метода NextEvent () объекта SwbemEventsource переводится в режим ожидания наступления события. Если же сценарий зареги­стрировал в WMI внешнее событие, то для его обработки используется вспомогательный объект SWbemSink.

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

Перезагрузка компьютера оставляет постоянно зарегистрированные события в репозитории CIM.

Очевидно, что использование постоянных потребителей делает сам процесс мониторинга событий более надежным, т. к. в этом случае нет необходимо­сти запускать вручную временные потребители событий и следить за их ра­ботой.

В отличие от временных потребителей, процесс постоянной подписки на события состоит из нескольких независимых этапов.

Во-первых, в репозитории CIM необходимо зарегистрировать нужное собы­тие. Для этого создается фильтр событий — новый экземпляр класса EventFiiter, в свойстве Query которого записывается определяющий это событие запрос на языке WQL, а в свойстве Name — имя фильтра. Фильтр событий сохраняется в репозитории CIM с помощью метода Put ().

Во-вторых, нужно определить действия потребителя при наступлении собы­тия и зарегистрировать этого потребителя в репозитории CIM. При этом постоянный потребитель событий должен быть представлен экземпляром потомка класса EventConsumer. В WMI имеются несколько встроенных классов для создания постоянных потребителей, которые позволяют по-разному реагировать на наступление событий (таблица 6.7).

Таблица 6.7 -Стандартные классы для создания постоянных потребителей

Например, для того чтобы при возникновении события выполнился определенный сценарий, нужно создать экземпляр объекта ActiveScriptEventConsumer, в свойство ScriptFileName записать путь к нужному сценарию, в поле ScriptingEngine — тип сценария (VBScript или JScript), в поле Name — имя, под которым будет сохранен данный по­стоянный потребитель событий. После этого созданный постоянный потре­битель (экземпляр ActiveScriptEventConsumer) сохраняется в репозитории CIM с помощью метода Put().

Наконец, последнее, что остается проделать, — это установить связь между созданными фильтром событий и постоянным потребителем (рисунок 6.9). Другими словами, нужно указать, какой именно потребитель событий будет принимать извещения о наступлении событий, задаваемых данным фильт­ром событий. Для этого нужно создать и зарегистрировать в репозитории CIM экземпляр ассоциативного класса FilterToConsumerBinding. У этого класса имеются свойства Filter, где нужно указать имя нужного фильтра событий (экземпляра объекта EventFiiter), и consumer, где указывается имя постоянного потребителя событий (экземпляра объекта ActiveScriptEventConsumer или другого потомка класса EventConsumer).

6.9 Безопасность при работе с WMI

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

Рисунок6.5 - Схема связи фильтра событий с постоянным потребителем событий

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

Дополнительная политика безопасности в WMI реализована на уровне про­странств имен и на уровне протокола DCOM (Distributed COM). Перед тем как более подробно рассмотреть эти типы безопасности WMI, напомним основные общие понятия, связанные с безопасностью в Windows.