WMI

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

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

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

В системе за всё это отвечает компонент под названием Менеджер объектов 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

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

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

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

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

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

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

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

В то время как служба 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), которая сама по себе фактически и является хранилищем объектов и классов, моделирующих различные компоненты компьютерной системы. Таким образом, в общем случае:

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

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

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

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

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

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

MOF

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

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

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

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

Тем не менее не все провайдеры управляемого объекта поддерживают 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:

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 файлы, что меня лично настораживает. Рекомендация могла устареть? К тому же, большинство на это забивает и радуется :)

Метод 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), которые производят переименование текущего репозитория.