Windows PowerShellПодключение WMI

Дон Джонс (Don Jones)

Одной из технологий, на которую я основательно опирался при работе со сценариями VBScript, является инструментарий управления Windows или WMI. Интересно, что оболочка Windows PowerShell в большой степени связана с WMI — и не только с технической точки зрения. Джефри Сноувер, создававший архитектуру оболочки Windows PowerShell, был также основным участником создания

Wmic.exe, интерфейса командной строки времен Windows Server® 2003, использовавшегося для работы с WMI. Во многих отношениях Wmic.exe предвосхищал Windows PowerShell™, функционируя в некотором смысле аналогичным образом. (Для получения дополнительных сведений о WMIC см. статью Джона Келбли, опубликованную в сентябрьском выпуске журнала TechNet Magazine за 2006 г. и доступную на веб-узле по адресу microsoft.com/technet/technetmag/issues/2006/09/WMIData.)

В Windows PowerShell имеется поддержка WMI, предоставляемая в точно таком же согласованном объектном виде, как и другие возможности данной оболочки. Благодаря этому WMI несравненно легче изучать и использовать (особенно в специфических ситуациях), чем более ранние технологии, такие как VBScript.

WMI для начинающих

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

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

В инструментарии WMI классы представляют все объекты, которыми управляет WMI. Если в WMI нет класса для какого-либо объекта, он не может управлять этим компонентом. Документация Майкрософт по основным классам Windows WMI представлена на веб-узле по адресу msdn2.microsoft.com/aa394554.aspx; другие программные продукты (например, Internet Information Services, SQL Server™) представляют документацию по своим классам WMI независимо.

Вследствие большого числа классов WMI организует их в виде иерархической структуры пространств имен. Например, пространство имен, содержащее основные классы операционной системы Windows, называется root\cimv2, в то время как Microsoft IIS 6.0 хранит свои классы в root\MicrosoftIISv2. Удобно то, что пространство имен root\cimv2, будучи пространством имен WMI по умолчанию, является общим параметром также для Windows PowerShell, что облегчает работу с этими основными классами.

Экземпляр — это действующая реализация класса. Если, например, на компьютере имеется два логических диска, у вас будут два экземпляра класса Win32_LogicalDisk. Если на компьютере выполняются 50 служб, инструментарий WMI различит 50 экземпляров класса Win32_Service. Работа с WMI состоит в основном из отправки иннструментарию WMI запроса на предоставление одного или нескольких экземпляров и последующего изучения их свойств с целью получения необходимой информации или выполнения методов этих экземпляров для изменения управления, например, запуск или остановка службы.

В WMI применяется архитектура клиент-сервер. Начиная с Windows 2000, во всех версиях Windows содержится встроенный инструментарий WMI (в последних версиях число классов увеличено), таким образом можно без труда получить доступ и к клиенту, и к серверу WMI. Используя WMI, вы фактически отправляете запрос службе WMI, выполняющейся на каком-либо интересующем вас компьютере. Эта служба WMI извлекает указанные экземпляры WMI и возвращает их вам для последующей обработки. Именно здесь вступает в игру оболочка Windows PowerShell — с ее помощью упрощается процедура запроса экземпляров, их получения и работы с ними.

Получение объекта WMI

Экземпляры класса WMI неточно называют объектами, что объясняет, почему средство извлечения этих экземпляров называется командлетом Get-WMIObject. У этого командлета имеется удобный псевдоним, gwmi, который будет использоваться в большинстве моих примеров. В его простейшей форме достаточно указать имя класса WMI, который требуется извлечь, а затем просто смотреть на результаты его работы (см. рис. 1). После того, как запущен командлет gwmi win32_service, Windows PowerShell подключается к службе WMI на моем локальном компьютере (поскольку не был указан другой компьютер) и подключается к пространству имен root\cimv2 (поскольку не было указано другое пространство имен). Windows PowerShell извлекает все экземпляры указанного класса и, поскольку не была указана никакая другая обработка этих экземпляров, преобразует их в текстовое представление. Другими словами, Windows PowerShell берет эти объекты и создает некоторый текст, доступный человеку для чтения.

Рис. 1 При выполнении командлета gwmi win32_service Windows PowerShell возвращает все экземпляры указанного класса в доступном для чтения текстовом формате.

Рис. 1** При выполнении командлета gwmi win32_service Windows PowerShell возвращает все экземпляры указанного класса в доступном для чтения текстовом формате. **

Более точно, Windows PowerShell преобразует объекты WMI в текст, считывая и отображая имена и значения выбранных свойств класса. Для класса Win32_Service выбирается набор из шести свойств.

Фактически Windows PowerShell любой объект преобразует в текст этим способом. Свойства, выбираемые для отображения, чаще всего определяются в наборе файлов .format.ps1xml, находящихся в папке установки оболочки Windows PowerShell. Эти файлы определения форматов снабжаются цифровой подписью Майкрософт. Данные файлы не рекомендуется изменять, хотя предусмотрена возможность создания собственных файлов форматирования. (Эта тема будет подробно обсуждаться в будущей заметке.)

Командлет gwmi упрощает обследование компьютера с целью выявления доступных классов. Например, результатом работы командлета gwmi –namespace "root\cimv2" –list является список классов указанного пространства имен. Однако следует помнить о том, что классы вашего компьютера необходимы только в том случае, если вы управляете данным компьютером; если вы управляете удаленным компьютером, потребуется выяснить, какие классы существуют в этой системе. Для этого, чтобы подключиться к удаленному компьютеру, потребуется использовать параметр командлета gwmi «–computer». Например, результатом работы командлета gwmi –namespace "root\cimv2" –list –computer ServerA является список всех классов пространства имен root\cimv2 на удаленном компьютере ServerA.

Удаленный WMI

В версии 1.0 оболочки Windows PowerShell командлет gwmi является практически единственным командлетом, непосредственно поддерживающим удаленное управление. Это объясняется в основном тем, что удаленное управление встроено в являющуюся базовой архитектуру WMI. И, поскольку оболочка Windows PowerShell просто использует эту существующую архитектуру, она является подчиненной по отношению к компонентам безопасности этой архитектуры. Приведем пример:

C:\> gwmi -namespace “root\cimv2” -computer
mediaserver -list
Get-WmiObject : Access is denied. (Exception
from HRESULT: 0x80070005 (E_ACCESSDENIED))
At line:1 char:5
+ gwmi <<<< -namespace “root\cimv2” -computer
mediaserver -list
PS C:\>

В этом примере выполняется попытка подключения к удаленному компьютеру  (с именем MediaServer), на доступ к которому у меня нет разрешения. В качестве администратора я должен был бы иметь разрешение на работу со службой WMI этого компьютера, но очень вероятно, что учетных данных моей рабочей станции недостаточно. Я мог, например, быть зарегистрированным на другом, не являющимся доверенным, домене, или войти в систему с использованием менее привилегированной учетной записи. К счастью, командлет поддерживает параметр gwmi «–credential», позволяющий указывать альтернативный набор пользовательских учетных данных для подключения моего WMI. Ниже приведен очень простой пример:

gwmi win32_service –credential mydomain\administrator –computer mediaserver

Мои учетные данные (более точно — мое пользовательское имя) предоставлено в формате DOMAIN\Username.

Отметим, что в этом формате не предусмотрен ввод пароля — запрос на ввод пароля выдает Windows PowerShell. В Windows PowerShell сознательно не предоставляется возможность ввода пароля в командной строке, поскольку такой способ позволил бы жестко указывать пароли в файлах сценариев, что является недопустимым с точки зрения безопасности. Однако существует еще один способ работы с параметром «–credential», состоящий в заблаговременном создании некоторого рода объекта учетных данных с именем PSCredential. Ключом является командлет Get-Credential:

$cred = get-credential mydomain\administrator

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

PS C:\> $cred

UserName
--------
mydomain\adminstrator

Этот объект учетных данных допускает неограниченное повторное использование:

gwmi win32_service –credential $cred –computer mediaserver

Это упрощает установку повторных подключений WMI к удаленному компьютеру посредством предварительного определения повторно используемого объекта учетных данных. Следует, однако, отметить, что командлет Get-WMIObject в настоящее время не поддерживает указание уровней проверки подлинности (или олицетворение) в том виде, как это делает VBScript. Для получения дополнительных сведений см. статью по адресу msdn2.microsoft.com/aa389290.aspx.

Самораскрытие

Больше всего мне нравится, что оболочка Windows PowerShell не замалчивает известную ей информацию. Уже было показано, как Windows PowerShell выбирает только часть свойств запрошенного класса Win32_Service. Однако у оболочки по-прежнему есть доступ ко всем свойствам и даже есть возможность сообщить о них. Для этого достаточно направить по каналу объект (или объекты) командлету Get-Member (можно использовать его псевдоним, gm), как показано на рис. 2.

Рис. 2 Отправка объекта по каналу в командлет Get-Member позволяет выяснить, к каким методам и свойствам можно получить доступ

Рис. 2**  Отправка объекта по каналу в командлет Get-Member позволяет выяснить, к каким методам и свойствам можно получить доступ **(Щелкните изображение, чтобы увеличить его)

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

Чтобы применить эти методы или отобразить другие свойства, зачастую проще всего поместить экземпляры в переменную:

$server = gwmi win32_operatingsystem
$server.reboot()

В этом образце кода выполняется извлечение единственного существующего экземпляра класса Win32_OperatingSystem (у этого класса имеется только по одному экземпляру на компьютер) и сохранение его в переменной $server. Затем переменная $server будет использована для получения доступа к методу Reboot данного экземпляра, выполняющего перезагрузку компьютера. Будьте осторожны с этим методом!

Мощный язык запросов

Если вы пользовались инструментарием WMI в рамках VBScript или другой технологии, возможно, вы привыкли извлекать экземпляры классов WMI с помощью запроса, написанного на WQL, языке запросов WMI. Благодаря его синтаксису, аналогичному синтаксису SQL, специальные экземпляры (например, специальная служба) извлекать легче, чем все экземпляры данного класса. К счастью, командлет также позволяет формировать запросы следующим образом:

gwmi –query “select * from win32_service where name=’alerter’”

Этот синтаксис gwmi (добавленный непосредственно перед официальным выпуском Windows PowerShell) невероятно удобен и существенно облегчает перенос сложных запросов WMI, которые, возможно, были разработаны для других целей. И, как всегда, Windows PowerShell возвращает развитые объекты с их свойствами и методами, обеспечивая полный доступ к возможностям управления, предоставляемым инструментарием WMI.

Дальнейшее развитие вместе с WMI

Продолжается разработка WMI для будущих версий Windows — в инструментарий добавляются новые классы и возможности. Одновременно продолжается его внедрение в новые продукты Майкрософт. Хотя для большей части программных продуктов Майкрософт еще не выпущены версии, собранные на платформе Windows PowerShell, ее возможность подключаться к WMI является одним из важнейших преимуществ, благодаря которому Windows PowerShell полезна уже сегодня.

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

Дон Джонс (Don Jones) занимает должность руководителя по проектам и услугам компании SAPIEN Technologies и является соавтором книги Windows PowerShell: TFM (издательство SAPIEN Press). Связаться с Доном можно через его веб-узел www.ScriptingAnswers.com.

© 2008 Корпорация Майкрософт и компания CMP Media, LLC. Все права защищены; полное или частичное воспроизведение без разрешения запрещено.