WMIC. Краткий обзор возможностей |

Wmi на службе системного администратора. — реальные заметки ubuntu & mikrotik

Алиасы

Хочу обратить внимание на то, что для удобства в консольной утилите WMIC, мы работаем не напрямую с классами WMI, а с их алиасами

# Все алиасы мы видим когда набираем 
wmic /?
# Или отдельно выводим их на экран
wmic alias list brief

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

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

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

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

1. Самым примитивным способом восстановления репозитория является удаление/переименование его рабочей директории. То есть, вы переименовываете директорию %SystemRoot%System32WbemRepository, к примеру, в Repository.old и ждете. После определенного таймаута сервис определит отсутствие директории репозитория и запустит процедуру восстановления. Но этот простой способ особенно никем не применяется, поскольку не учитывает перекомпиляцию не входящих в автовосстановление (список .mof в реестре) классов и не выполняет перерегистрацию провайдеров.
2. Вне зависимости от того, где и как оно применяется, удаление рабочего WMI-репозитория является достаточно разрушительной операцией, которая может повлечь за собой потерю данных, возникновение ошибок в WMI-приложениях, замедление отклика некоторых операций, и возникновении других, сложнодиагностируемых проблем.
3. Существуют приложения, которые в процессе установки в систему [самостоятельно] напрямую обновляют репозиторий, вообще не используя никаких .mof-файлов. Соответственно, при пересоздании (удалении и создании) репозитория подобные приложения не имеют возможности обновить базу данных и их данные, связанные с WMI, будут удалены (потеряны) вплоть до момента, пока вы не переустановите означенные приложения (в режиме восстановления).
4. Следует помнить, что не все приложения хранят свои WMI-провайдеры (.dll) и .mof-файлы в %SystemRoot%System32wbem. Соответственно, вам нужно будет выявить подобные приложения (поиск по маске *.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%SysWOW64wbem, а на 32-битных системах из %SystemRoot%System32wbem, но оказалось, что (в ОС, начиная с Windows 7) в директории для 64-битной ОС отсутствуют многие .mof файлы, что меня лично настораживает. Рекомендация могла устареть? К тому же, большинство на это забивает и радуется 🙂

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

Выполнение команды wmi на удаленных хостах

wmic /node:'Server' OS get Caption

Примеры WMI команд

Получить модель материнской платы

wmic baseboard get product,manufacturer,version,serialnumber

Узнать разрядность системы

wmic /Node:%ComputerName% Path Win32_Processor Get AddressWidth /format:list
# Аналог команды для PoSh 
( Get-WmiObject Win32_OperatingSystem ).OSArchitecture

Получить программы из автозагрузки

wmic startup list brief

Узнать имя активного пользователя

Запуск и завершение приложений

Запуск:

wmic process call create 'notepad.exe'

Завершение:

wmic process where name='notepad.exe' delete

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

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

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

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

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

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

Вне зависимости от версии WMI в системе имеется несколько предопределенных пространств – корневое пространство имён Root, и 4 пространства, располагающихся уровнем ниже: CIMv2, Default, Security и WMI.

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

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

Метод 1

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

winmgmt /verifyrepository

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

winmmgmt /salvagerepository

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

winmgmt /verifyrepository

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

net stop winmgmt /ywinmgmt /resetrepository

Метод 2

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

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

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

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

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

Ошибки wmi

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

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

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

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

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

1. Ошибки в log-файлах самих приложений: WBEM_E_NOT_FOUND – 0x80041002.
2. Ошибки отказа при подключении к пространствам имен RootDefault или Rootcimv2;
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, выполните следующие действия:

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

Провайдеры 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), реализующей весь функционал провайдера.

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

В то время как служба WMI обслуживает управляющие приложения через COM-интерфейс, WMI-провайдеры действуют в качестве COM-серверов, обрабатывающих запросы от службы 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%System32WbemRepository и состоит из следующих файлов (для Windows 7):

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

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

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

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

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

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

В системе за всё это отвечает компонент под названием Менеджер объектов CIM (Common Information Model Object Manager, CIMOM), занимающийся обслуживанием взаимодействия управляющих приложений с WMI-провайдерами и управлением хранилищем базы данных WMI (репозиторием).

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

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

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

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

Язык запросов wmi (wql)

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

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

Тем не менее не все провайдеры управляемого объекта поддерживают WQL, в подобных ситуациях менеджер объектов CIM должен преобразовать запрос к виду, обрабатываемому [конкретным] провайдером. WQL представляет собой специально сконструированные запросы, которые являются подмножеством (подвидом) SQL.

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

Форматирование вывода

Так как по умолчанию wmic возвращает не форматированный ответ, то если не определить форматирование вручную, мы увидим хаотически разбросанные по окну консоли слова:

Весьма информативно, не правда ли?

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

wmic BIOS list brief

Параметр brief выводит список основных параметров.Обычно не более 6 столбцов

Все типы форматов я смотрю такой командой:

wmic OS get /format /?

Можно использовать функцию /format, с любым доступным типом формата:

wmic BIOS get /format:list

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

wmic BIOS list full

Похожее:

Что это за зверь wmi service Получить данные о настройке операционной системы и установке программного обеспечения, используя функциональность базовой платы wmi win32 Инструментарий управления Windows — это и 1С, и Windows Script Host (WSH), и Инструментарий управления Windows (WMI). ОТ ТЕОРИИ К ПРАКТИКЕ. Часть II Утилита WMIC, часть 2 – методы и ключи |