День в центре технической поддержки фирмы ABC Company выдался просто сумасшедший. Сначала курирующий вопросы производства вице-президент компании устроил сотрудникам разнос по телефону. Подключившись к сети, вице-президент обнаружил, что накопитель V не виден, а значит, он не успевает вовремя рассмотреть важнейший запрос на коммерческое предложение. Потом оказалось, что в сети свирепствует новый вирус: практически на каждом четвертом компьютере компании не была проведена процедура обновления антивирусной программы, запускаемая сценарием регистрации. А тут еще бригаде специалистов, ответственных за развертывание Windows XP, потребовался полный список аппаратных вычислительных средств, а, как выяснилось, инвентаризационная база данных не отражает текущего состояния.

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

Однако, к сожалению, в среде Windows сценарии регистрации работают небезупречно. Они запускаются в штатном режиме только в тех случаях, когда осуществляющий аутентификацию учетной записи пользователя компьютер подключен к сети с помощью проводного соединения. При регистрации по соединениям VPN и RAS полноценное выполнение сценариев регистрации, как правило, невозможно. Отчасти это связано с тем, что права доступа пользователя уже проверены по локально кэшированным учетным данным, и сетевая регистрация представляет собой уже вторичную аутентификацию. На машинах XP и Windows 2000 сценарии регистрации тоже должным образом не выполняются - в связи с тем, что после того как компьютер запущен и полностью приведен в рабочее состояние, обе операционные системы предусматривают возможность динамического подключения системы к сети с помощью сетевых интерфейсных плат. В конечном счете, не так уж и важно, по какой именно причине сценарий регистрации не запускается при инициализации системы. Важно, что при подобных сбоях пользователи часто оказываются не в состоянии выполнять свои задачи, а администраторы не могут эффективно управлять мобильными системами.

Согласно предлагаемому мною сценарию, решать эту проблему позволяют средства мониторинга событий инструментария управления Windows WMI (Windows Management Instrumentation). Этот сценарий проверяет соединения с корпоративной сетью, после чего запускает на выполнение сценарий регистрации. Для выполнения моего сценария необходимо, чтобы в системе были установлены как WMI, так и Windows Script Host (WSH), но эти службы можно развертывать даже в среде Windows 95. Я решил проверить сценарий на обратную совместимость и испытал его на машине Windows 95 OEM Service Release 2 (OSR2) с установленными программами WMI и WSH - он функционировал нормально. В версии Windows, выпускавшиеся до появления Windows 2000, программа WMI не входила, поэтому тем, кто пользуется данными версиями, придется устанавливать исполняемые модули. Эти модули можно получить по адресу http://msdn.microsoft.com/downloads/default.asp?url=/downloads/sample.asp?url=/msdn-files/027/001/576/msdncompositedoc.xml>. Кстати, упомянутые модули установлены на всех машинах, которые являются клиентами Microsoft Systems Management Server - SMS, так что обновлять их не нужно. Что ж, пойдем дальше - рассмотрим, какие задачи позволяет решить мой сценарий, как он выполняется и как его реализовать.

Средства мониторинга событий службы WMI

Не буду останавливаться на основах функционирования WMI; эта тема уже достаточно обсуждалась как на страницах печатных изданий, так и в Web. Однако для того, чтобы дать читателю представление о том, как служба WMI обеспечивает выполнение задачи, поставленной перед сценарием, я кратко опишу некоторые реализованные в WMI функции мониторинга событий. Встроенная система мониторинга событий службы WMI отслеживает события во всех классах WMI. Любой сценарий можно "привязать" к этим событиям и выполнять действия в зависимости от них. Системы на основе событий, как правило, позволяют сокращать число используемых рабочих циклов процессора и задержки, связанные с опросом элемента системы об изменениях его состояния. Если сценарий, в котором задействованы средства мониторинга событий WMI, составлен корректно, он может отслеживать события, не будучи встроенным в цикл, а значит, непроизводительные затраты ресурсов процессора снижаются почти до нуля. В рамках мониторинга событий внутренние механизмы WMI выполняют некоторые операции по опросу элементов системы. Но эти операции проводятся внутри пространства имен WMI. Сценарию не приходится запускать дополнительные процессы, реактивировать бездействующие процессы, подключаться к внешним источникам данных или пережидать задержки на обращение к диску.

Средства мониторинга событий службы WMI могут инициализировать мониторинг событий даже в тех случаях, когда данная функция не предусмотрена соответствующим интерфейсом API. Когда в API встраивается провайдер WMI, этот провайдер автоматически извещает WMI обо всех случаях создания, обновления и удаления экземпляров своего класса. Даже если вы привлечете к работе системного программиста Windows, вполне возможно, что он так и не сможет найти комбинацию базовых API, обеспечивающую надежное подключение и мониторинг событий соединений VPN, RAS и динамических соединений для всех версий Windows (от XP до Windows 95). Такая сложная задача явно противоречит идее написания короткого VBScript-сценария, предназначенного для мониторинга этих событий и выполнения соответствующих действий.

Цели составления сценария

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

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

Сценарий мониторинга выполнения регистрации (Logon Monitor Script)

В первых двух строках сценария, представленного в Листинге 1, определяются две переменные, речь о которых впереди. В метке A Листинга 1 функция GetObject устанавливает соединение с WMI и создает запрос об извещении о событии. В строке SELECT указывается, что сценарий должен получать имя (TargetInstance.Name) любого нового или измененного экземпляра (FROM_InstancdOperationEvent) класса WMI, представляющего сетевые соединения (TargetInstance ISA 'Win32_NetworkAdapterConfiguration'). Стоит отметить, что объект Win_32_NetworkAdapterConfiguration включает в себя все сетевые соединения вне зависимости от того, используются ли для их осуществления физические сетевые адаптеры. При установлении соединений RAS, VPN или других типов соединений API RAS или VPN создает "виртуальный адаптер", который затем появляется в данном классе WMI. При обнаружении новых соединений RAS или VPN, а также при подключении к сети новой сетевой интерфейсной платы после регистрации пользователя объект _InstanceOperationEvent извещает сценарий об этих событиях. (Вообще-то объект _InstanceOperationEvent извещает сценарий и об удалении соединения, однако в данном сценарии такие это не предусматривается.)

Служба WMI извещает сценарий обо всех событиях, соответствующих критериям запроса. Раздел запроса WITHIN 4 означает время в секундах, выделяемое внутреннему механизму WMI для проведения опроса класса о наличии событий. Как я уже говорил, механизм этого внутреннего опроса весьма эффективен. Желающие проверить, не оборачивается ли данный запрос о событиях дополнительной нагрузкой на процессор, могут установить наблюдение за службой WMI с помощью средства Performance Monitor. Это средство покажет, что выполнение сценария не приводит к непроизводительной затрате ресурсов процессора. Большинство версий Windows (включая Windows 2000) вызывают службу WMI [через файл] winmgmt.exe. В среде Windows XP служба WMI является экземпляром svchost.exe. Для того чтобы точно определить непроизводительные расходы процессора, необходимо сравнить значения счетчиков производительности процессора - в расчете на процесс - до запуска сценария и во время его выполнения.

Цикл Do. Цикл Do рассматриваемого сценария не является бесконечным циклом опроса; он обеспечивает постоянный мониторинг событий соединения. Без этого цикла сценарий выполнялся бы только один раз. Сценарий должен находиться в этом цикле для того, чтобы обрабатывать ситуации, в которых пользователи, подключенные к сети с помощью соединений VPN, RAS или через Dynamic NIC, воздерживаются от выключения своих портативных компьютеров (переводя их в режим ожидания или "спячки").

Строка в метке B позволяет обходиться без опроса по событиям конфигурации (который проводится традиционными сценариями мониторинга). Рассматриваемый сценарий в данной точке исполнения ждет от WMI извещения о наступлении события, соответствующего указанным критериям. Когда служба WMI извещает сценарий о наступлении такого события, выполнение продолжается со следующей строки.

В следующей строке указывается, что объект соединения должен обязательно возвращать строку, содержащую свойство Ipaddress. При таком подходе автоматически отфильтровывается несколько типов нежелательных событий - прежде всего, события удаления соединения, которые не возвращают массива строк для переменной IP-адреса.

Кроме того, некоторые типы соединений (например, соединения VPN) до получения действительного IP-адреса предусматривают многочисленные модификации экземпляра Win32_NetworkAdapterConfiguration. Проверка VarType гарантирует, что сценарий мониторинга будет игнорировать подобные промежуточные события.

Функция SubnetMatch. Базовый метод, используемый сценарием Logon Monitor для идентификации целевой сети, важен в двух отношениях. Он позволяет, во-первых, сокращать число "ложных срабатываний" при взаимодействии с другими сетями, а во-вторых - блокировать попытки главного сценария запускать сценарий регистрации в случаях, когда класс Win32_NetworkAdapterConfiguration выявляет изменения в других типах соединений. Некоторые типы протоколов-упаковщиков, как, впрочем, и инфракрасные порты, тоже создают и модифицируют этот список экземпляров данного класса. Процедура согласования подсетей позволяет отфильтровывать указанные ситуации и предотвращать запуск сценариев регистрации в неподходящих случаях.

Функция SubnetMatch обеспечивает успешный поиск подсети, отвечающей заданным критериям. Построчное разъяснение механизма действия этой функции выходит за рамки данной статьи, но все же читателю нужно знать, какие услуги данная функция предоставляет. Итак, функция SubnetMatch использует IP-адрес соответствующего компьютера и ищет подобные адреса в предоставленном списке подсетей. Функция возвращает булево значение ("истина" или "ложь") и помещает список совпадений в массив.

Программу SubnetMatch можно применять в сетях, разделенных на подсети без использования классов, поэтому она дает точные результаты в сетях при использовании самых разных способов разделения сетей на подсети. Функции передается список подсетей, так что можно включать в него отдельные подсети, выделенные по логическим критериям, например, Building A (строение А), London Campus (лондонский кампус) или Finance Division (финансовый отдел).

Для получения точных совпадений по сегменту смежных подсетей можно использовать адреса надсетей (supernet addresses). Чаще всего надсети применяются для обозначения любого соединения со всей сетью компании. Если в компании используется единый адрес класса B, можно задействовать этот адрес вместо длинного списка подсетей. Применение надсетей позволяет упростить сценарий и повысить быстродействие функции поиска совпадений в сложных сетях. Когда вы будете использовать надсети, вероятность того, что сценарий найдет совпадения в сетях за пределами целевой сети, будет выше.

Для того чтобы идентифицировать сети с исключительно высокой степенью точности, сценарий можно модифицировать так, чтобы он извлекал из анализируемого события объект TargetInstance и сопоставлял значения других атрибутов TCP/IP и соединений. Суффикс DNS, WINS Servers и DNS Servers могут служить примерами уникальных идентифицирующих данных, которые позволяют удостовериться в том, что соединение установлено со всей сетью. Позднее мы рассмотрим вопрос о мягких аварийных переключениях (graceful failover), а в этом разделе будет показано, как сценарий обрабатывает ситуации с ложными совпадениями.

Код в метке C вызывает функцию SubnetMatch. Функция принимает четыре параметра. Первый из них - это предоставляемый список подсетей (aSubnetList). Данный массив представляет собой список IP-адресов и пар масок подсетей, разделенных косой чертой (/). Поскольку список обрабатывается последовательно, на первых позициях следует размещать подсети, соответствующие адресам наибольшего числа компьютеров (возможен такой порядок: надсети, затем подсети с наибольшим числом мобильных клиентов, затем другие подсети).

Второй параметр - это IP-адрес соединения, возвращенный сценарию службой WMI. Сценарий рассматривает данный адрес как часть объекта ConnectEvent с именем Connect-Event.TargetInstance.Ipaddress(0). Для извлечения многих других атрибутов соединения можно использовать другие имена свойств класса Win32_NetworkAdapterConfiguration.

Третий параметр - bAllMatches. Если он получает значение "истина", функция SubnetMatch находит все совпадения. Если же параметру задано значение "ложь", SubnetMatch ограничивается обнаружением первого совпадения. Если сценарий должен проверить множество подсетей, более высокое быстродействие достигается при использовании значения "ложь".

Четвертый параметр представляет собой имя массива, в который функция SubnetMatch поместит список совпадений. Этот массив будет содержать более одного значения лишь в том случае, если параметру bAllMatches будет присвоено значение "истина". Получение всех совпадений может оказаться полезным при отладке обширных списков подсетей. Передавать сценарию информацию о том, какие подсети соответствуют заданным критериям, нет необходимости (данная видовая программа поиска подсетей предназначена для обработки большого количества объектов), так что списки сценарию не возвращаются.

Функция SubnetMask выполняет некоторые расчеты, определяет, какие подсети из списка aSubnetList соответствуют IP-адресу того или иного компьютера, и возвращает логическое значение ("истина" или "ложь"), которое показывает, найдено ли совпадение. Соответствующая строка в метке D предназначена для того, чтобы проверить, найдена ли функцией SubnetMatch соответствующая заданным критериям подсеть. Выполнение сценария продолжается лишь после завершения такой проверки.

Выполнение сценария регистрации

Строки кода, размещенные в метке E, используются для создания объекта-оболочки, для отображения сетевого накопителя и выполнения сценария регистрации (в последнем случае используется метод run объекта-оболочки). Для выполнения сценариев регистрации .bat и .cmd нужно выделять применяемый по умолчанию каталог, однако сценарий выполняется в соответствии с соглашением по универсальным именам UNC (Universal Naming Convention), которое этого не предусматривает. Таким образом, для работы с названными сценариями накопителю необходимо присвоить буквенное обозначение. Если же сценарий регистрации написан в формате .vbs, .exe или в другом формате, не требующем присвоения накопителю буквенного обозначения, можно удалить все команды, управляющие отображением накопителя (метка F) и сохранить лишь ту часть программы, которая обеспечивает создание объекта-оболочки и выполнение сценария непосредственно с UNC. Сегмент сценария с соответствующими модификациями представлен в Листинге 2.

Мягкое аварийное переключение (Graceful failover)

Для обработки ситуаций, когда адрес подсети как будто соответствует заданным критериям корпоративной сети, но там, где в соответствии со сценарием должен находиться сценарий регистрации, последний отсутствует, используется мягкое аварийное переключение. Этот термин означает, что если сценарий мониторинга для выполнения регистрации не может запустить сценарий регистрации, все сообщения об ошибках подавляются, и выполнение сценария продолжается. Мягкое аварийное переключение, позволяющее продолжать выполнение сценария в тех случаях, когда обнаружить сценарий регистрации невозможно, обеспечивается операторами On Error Resume Next и Err.clear в метке E.

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

Еще одна аварийная ситуация возникает в том случае, когда компьютер, выполняющий сценарий мониторинга для осуществления регистрации, подключен к сети, IP-адрес которой соответствует адресу целевой сети, но, тем не менее, данная сеть целевой сетью не является (это может быть сеть Internet-провайдера или сеть другой корпорации). В такой ситуации сценарий попытается запустить сценарий регистрации, но не сможет его отыскать.

Наконец, бывают ситуации, когда совпадения связаны с устройствами, не подключенными к корпоративной сети. К примеру, нередко типы соединений через инфракрасные порты имеют IP-адреса, которые могут совпадать с адресами заданных корпоративных подсетей.

Вам придется изменить те строки Листинга 1 и Листинга 2, где содержатся ссылки на совместно используемое имя и на имя сценария мониторинга для выполнения регистрации так, чтобы они соответствовали используемым в сети именам. Возможно, вы сочтете необходимым на время тестирования снабдить строку On Error Resume Next комментарием, чтобы иметь возможность перехватывать ошибки в значениях параметров.

Реализация сценария регистрации

Сценарий мониторинга для выполнения регистрации необходимо установить на локальном жестком диске каждого компьютера по одному из многих путей, где Windows ищет программы, которые следует инициализировать при регистрации пользователя. Сценарий нужно настроить так, чтобы он выполнялся в контексте соответствующего пользователя; в этом случае соединения и другие функции сценария регистрации будут выполняться с применением учетных данных пользователя. Не будем забывать, что пользователи порой склонны экспериментировать с объектами своих папок Startup, поэтому инициализировать сценарий следует с использованием раздела реестра HKEY_CURRENT_USER\Software\Microsoft\Windows\ CurrentVersion\Run.

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

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

Дарвин Саной  - старший консультант в DesktopEngineer.com. Регулярно выступает на конференции Microsoft Management Summit, читает курс по Windows Installer. С ним можно связаться по адресу: darwin@desktopengineer.com.