Wmi explorer что это
По умолчанию PowerShell поставляется с командлетами для использования вместе с другими технологиями, такими как инструментарий управления Windows (WMI). Существует несколько собственных командлетов WMI, которые используются в PowerShell без необходимости установки дополнительного программного обеспечения или модулей.
PowerShell поставляется с командлетами для работы с инструментарием WMI с момента выпуска. Get-Command можно использовать для определения командлетов WMI, существующих в PowerShell. Приведенные ниже результаты получены на моем компьютере с Windows 10 в лабораторной среде под управлением PowerShell версии 5.1. Ваши результаты могут отличаться в зависимости от используемой версии PowerShell.
Командлеты модели CIM появились в PowerShell версии 3.0. Командлеты CIM разработаны так, чтобы их можно было использовать на компьютерах под управлением Windows и других ОС. Командлеты WMI являются устаревшими, поэтому вместо них рекомендуется использовать командлеты CIM.
Все командлеты CIM содержатся в модуле. Чтобы получить список командлетов CIM, используйте Get-Command вместе с параметром Module, как показано в следующем примере.
Как и раньше, командлеты CIM позволяют вам работать с WMI, поэтому не путайтесь, если кто-то пытается выполнить запрос WMI с помощью командлетов CIM PowerShell.
Как я уже говорил, WMI — это отдельная технология в PowerShell, поэтому вы просто используете командлеты CIM для доступа к WMI. Вы можете найти прежний сценарий VBScript, в котором используется язык запросов WMI (WQL), позволяющий выполнить запрос WMI, как показано в следующем примере.
Вы можете взять WQL-запрос из сценария VBScript и использовать его с командлетом Get-CimInstance без изменений.
Это не тот способ, который я стандартно использую для запроса WMI с помощью PowerShell. Но он действительно работает, позволяя легко перенести существующие сценарии VBScript в PowerShell. При внесении скрипта из одной строки для запроса WMI я использую следующий синтаксис.
Если нужно указать только серийный номер, я могу передать выходные данные в Select-Object и указать только свойство SerialNumber.
По умолчанию существуют несколько свойств, извлекающихся в фоновом режиме, который никогда не используется. Это действие не важно, если запрос инструментария WMI выполняется на локальном компьютере. Но когда вы приступаете к выполнению запросов с удаленных компьютеров, оно позволяет не только увеличить время обработки для возврата информации, но и получить по сети дополнительные ненужные данные. Get-CimInstance содержит параметр Property, который ограничивает извлекаемые данные. Это действие позволяет выполнять запрос к инструментарию WMI более эффективно.
Предыдущие результаты вернули объект. Для возврата простой строки используйте параметр ExpandProperty.
Также для этого вы можете использовать пунктирный стиль синтаксиса. Это избавляет от необходимости передавать простую строку в Select-Object .
Сводка
В этой главе вы узнали об использовании PowerShell для работы с инструментарием WMI на локальном и на удаленном компьютерах. Кроме того, вы узнали о том, как использовать командлеты CIM для работы с удаленными компьютерами с помощью протокола WSMan или DCOM.
WMI Explorer is an auxiliary application for HostMonitor, however it can be used independently as well. WMI Explorer is included into Advanced Host Monitor package (since version 5.82) and can also be downloaded separately at the download page.
WMI is an acronym for Windows Management Instrumentation. WMI is the Microsoft's implementation of Web-Based Enterprise Management (WBEM) - a new management technology that allows software to monitor and control managed resources throughout the network. Such managed resources include hard drives, file systems, settings of operating system, processes, services, shares, registry settings, networking components, event logs, users, groups, etc.
WMI allows monitoring of performance counters as well. Microsoft applications such as Exchange and SQL Server have WMI built-in. Many non-Microsoft applications utilize WMI and thus they could be monitored using Advanced Host Monitor as well.
WMI is already built into Windows 2000 or above, and can be installed on any other 32-bit Windows system. See also:
WMI Explorer
- Explore the full set of WMI management classes, objects and their properties
- Browse through objects and settings on remote machines
- Execute any WQL query and view the result set
WMI Explorer can be started as an independent application or it can be launched by HostMonitor to tune up a WMI test.
Once you have started WMI Explorer, you will be presented with two ways to explore a machine's objects:
The Classes (browser) view*
This view displays full set of classes within the specified namespace** (on local or remote machine), child objects and their properties.
Top portion of the main window shows all classes available on the system. In order to quickly find a class you may use "Search" menu. Menu item "Find" searches (using the name) for the specified class. Menu item "Search again" looks for the next suitable entry. If the search option "Match whole word only" is disabled, the search string might be found within longer words. E.g. consecutive searches for the string "_Process" will find CIM_Process, CIM_ProcessExecutable, CIM_Processor, CIM_ProcessThread, Win32_Process and Win32_Processor items.
Instances
The Instances panel is located in the bottom-left portion of the main window. Every time you click on a class in Classes panel, WMI Explorer queries Windows and retrieves all instances (objects) of the selected class.
Please note: some classes have many instances, retrieving of information about them may require a lot of time and system resources. That is why WMI Explorer requests the target system in the background using dedicated thread. This allows the user to check properties or switch to another class while the request is still in progress. When request is completed, explorer shows the number of instances in the status line (if you see "Requesting instances. " in the status line, it means explorer have not yet finished retrieving the information).
Properties
The Properties panel is located in the bottom-right portion of the main window. Every time you click on a class in Classes panel, WMI Explorer queries Windows to retrieve the list of properties of the selected class. Even if there are no instances of the class, you will be able to see the list of its properties.
To view the property value for specific object, simply click the mouse on the object's instance in Instances panel.
Note: If object property represents one-dimensional array with 4 or less elements, WMI Explorer will display array elements. If object property represents one-dimensional array with 5 or more elements, explorer will offer "Copy array values" popup menu item, it copies up to 512 elements of array into clipboard.
Methods
Here WMI Explorer can display methods of the selected class, also it shows parameters of each method. Popup menu allows you to copy method description into clipboard; sort methods alphabetically.
The Query view*
-
E.g. if you want to monitor the number of handles used by all running instances of the Internet Explorer, use the query like this: SELECT HandleCount FROM Win32_Process WHERE name='iexplore.exe'
Query window is an invaluable resource for those who know where to look for something but need to see what exactly is returned by Windows API to HostMonitor.
If you are running HostMonitor and you already have configured some "WMI" test items, you may click the right mouse button on the test item and choose "Explore WMI" item from the popup menu. When you do so, HostMonitor will start WMI Explorer in the Query mode, passing the query and information about the target host (such as the hostname, name space, login, etc) to the explorer. This allows you to check quickly hardware and software parameters on the target system and instantly see what is going on (e.g. why the test item has been failed).
*To switch between views, click on their respective tabs at the top of the main window. You can do it at anytime since views are absolutely independent.
Connecting to remote host
WMI Explorer allows you to request both local (the system where explorer is running) and remote systems. To connect to the remote system you may use GUI or command line parameters.
- Default
Tells DCOM to choose the authentication level by using its normal security blanket negotiation (note: it will never choose an authentication level of None). - None
No authentication is performed during the communication between client and server. All security settings are ignored. - Connect
The normal authentication handshake occurs between the client and server, and a session key is established but that key is never used for communication between the client and server. All communication after the handshake is insecure. - Call
Only the headers of the beginning of each call are signed. The rest of the data exchanged between the client and server is neither signed nor encrypted. Most SSPs do not support this authentication level and silently promote it to Packet. - Packet
The header of each packet is signed but not encrypted. The packets themselves are not signed or encrypted. - Packet Integrity
Each packet of data is signed in its entirety but is not encrypted. Because all of the data is signed by the sender, the recipient can be certain that none of the data has been tampered with during transit. - Packet Privacy
Each data packet is signed and encrypted. This helps protect the entire communication between the client and server.
** Note: WMI namespace is a container grouping child objects related to one another in some way. A namespace contains a hierarchy of classes and associations which define either a machine's object or the relationship between two or more objects. The most commonly used namespace is CIMV2 (Common Information Model Version 2.)
The WMI Core software package for Windows 95, 98, and Windows NT 4.0 available at Microsoft's web site.
Please note: WMI CORE for Windows 95/98/NT requires Microsoft Internet Explorer version 5 or later.
OS: Windows XP SP2
Problem: built-in firewall may block WMI requests from remote systems
In order to remotely administer a Windows XP SP2 machine using WMI, you will need to configure the built-in firewall. If the Windows firewall is enabled and if it hasn't been configured to accept a WMI connection, WMI Explorer (and HostMonitor) will not be able to connect to the system. In such case, HostMonitor shows "The RPC Server is unavailable" error.
To configure Windows XP firewall to accept WMI connections, you need to enable the "Allow remote administration exception" group policy entry. This setting can either be configured on the local group policy of a machine or globally by configuring the global Group Policy settings of an Active Directory domain.
OS: Windows 95/98/NT
Problem: winmgmt.exe does not start automatically on such systems
- enable DICOM (set HKLM\SOFTWARE\Microsoft\OLE\EnableDCOM to "Y")
- enable remote connections (set HKLM\SOFTWARE\Microsoft\OLE\EnableRemoteConnect to "Y")
- set HKLM\SOFTWARE\Microsoft\WBEM\CIMOM\AutoStartWin9x to 2
- add link to the Winmgmt.exe file into the Startup directory
OS: Windows 2000,XP,2003
Problem: WMI Explorer (and HostMonitor's WMI test) returns "Class ISWbemLocator is not registered" error
Windows 2000, XP, 2003 do have the WMI pre-installed. If application returns such error, most likely there is system registry problem. The following article shows how to fix a corrupted WMI repository and how to register the WMI components: Rebuilding the WMI Repository
Для начала что такое WMI (Windows Management Instrumentation)? Это технология, которая с помощью единого интерфейса позволяет управлять компонентами как локальной, так и удаленной операционной системы.
Данный материал рассчитан на тех, кто что-то слышал о WMI, но не знает с чего начать его «ковырять». А так же на тех, кто и не подозревал о существовании такого удобного инструмента.
Я не буду рассказывать о том, как работает, как устроена данная технология, если возникнет интерес — информацию всегда можно найти в MSDN. Моя цель — помочь обеспечить быстрый старт, для тех, кто хочет начать использовать данную технологию.
Что дает применение WMI на практике? Возможность изменять различные параметры операционной системы, управлять общими ресурсами, запрашивать информацию об установленных устройствах, запущенных процессах и т.д.
Чтобы долго не занудствовать я приведу пример получения информации об установленном процессоре. В списке Namespaces (пространство имен) выбираем root\CIMV2, в списке Classes (классы) выбираем Win32_Processor. В списке Results (в нем перечислены свойства класса) выбираем Name и нажимаем Execute Code. В появившемся окне видим название (или названия) установленного процессора.
Другой пример — выведем список расшаренных ресурсов. В этот раз выберем класс Win32_Share, в списке свойств выберем Name затем Execute Code. Получили список ресурсов.
Давайте теперь закроем доступ к какому-нибудь ресурсу, в моем случае это Temp. Переходим на закладку Execute a Method в списке классов выбираем все тот же Win32_Share, в списке Methods (методы класса) выбираем Delete, выбираем папку Temp, Execute Code, если все прошло успешно, то папка Temp более не числится в списке общих ресурсов.
Если Вам не хватает возможностей WMI — Вы всегда можете создать собственный класс. Пример создания такого класса уже публиковался на Хабре.
Думаю каждый хотя бы раз сталкивался с ситуацией, когда на современной ОС не удавалось запустить старую программу, и помогал в этом случае режим совместимости Windows.
В основе работы данного механизма лежит перехват различных функций и эмуляция их поведения, свойственного указанной версии Windows, например, эмулируются ключи реестра, каталоги с документами и прочее. Все это нужно для того, чтобы программа думала, что запущена в выбранной среде.
Если приложение запущено в режиме совместимости, то вызов GetVersionEx вернет фиктивную версию Windows, что, вероятно, не подойдет для системных программ типа твикеров ОС. Как быть в этом случае?
Анализ экспортируемых функций
На просторах сети наткнулся на способ детектирования по наличию/отсутствию экспортируемых функций у системных библиотек. Пример кода:
Решение интересное, но не считаю его приемлемым, так как с выходом каждой версии Windows требуется нетривиальная поддержка.
Используя WMI
Windows Management Instrumentation (WMI) в дословном переводе — это инструментарий управления Windows. Если говорить более развернутo, то WMI — это одна из базовых технологий для централизованного управления и слежения за работой различных частей компьютерной инфраструктуры под управлением платформы Windows.
Из WMI можно получить и версию Windows. Из документации следует что это можно сделать таким запросом:
SELECT Version FROM Win32_OperatingSystem
Запустив WMI Explorer в режиме совместимости с Windows XP, можно увидеть, что это значение не эмулируется:
Метод работает, более того, он полностью документирован, но медленный, и требует тянуть в проект кучу кода по работе с WMI.
Ищем в реестре
Пожалуй самый элегантный и правильный способ найденный в сети — это подсмотреть значение в реестре:
HLKM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\CurrentVersion
Ну что же, попробуем:
К сожалению, проверив его на Windows 7 оказалось, что этот ключ реестра эмулируется. Похоже в предыдущих версиях Windows этот способ работал, но, увы — сейчас этот трюк не сработает.
Анализ версии kernel32.dll
Сам не проверял, но говорят, что версия файла у kernel32.dll совпадает с версией Windows. На моем компьютере с Windows 7 это так:
Вполне пригодный способ, но лично мне по непонятным причинам он не нравится, благо есть еще альтернатива.
Анализируем PEB процесса
У каждого Windows-процесса есть структура описывающая его, называется она PEB. Она заполняется при старте процесса и содержит в себе адрес загрузки, список загруженных модулей, параметры командной строки, и, в том числе, версию Windows. Ниже пример модуля, используя который можно получить реальную версию Windows (тестировался на Delphi 2010 Win32):
Скорость работы моментальная, ничего лишнего, единственное НО — недокументированная структура PEB, но как известно Microsoft очень заботится об обратной совместимости, так что с большой долей оптимизма можно считать, что раз описание структуры давно бродит по интернету, то в Microsoft она уже считается документированной.
Выводы
А выводы простые, если очень нужно получить реальную версию то WMI отличный вариант, если же требуется легковесное решение — смотри в PEB.
Инструментарий управления Windows (WMI) разработан корпорацией Майкрософт в рамках отраслевой инициативы управления предприятием через Интернет (WBEM), целью которой является создание стандартной технологии получения доступа к информации по управлению в среде предприятия. В инструментарии WMI используется модель CIM — отраслевой стандарт, служащий для представления систем, приложений, сетей, устройств и других управляемых компонентов. Модель CIM разрабатывается и обслуживается с помощью распределенной задачи управления Force (DMTF).
в настоящее время доступна версия WMI следующего поколения, известная как инфраструктура управления Windows (MI). MI полностью совместима с предыдущими версиями инструментария WMI и предоставляет ряд функций и преимуществ, упрощающих разработку и разработку поставщиков и клиентов проще, чем когда-либо. Например, многие новые поставщики пишутся с помощью платформы MI, но доступ к ним можно получить с помощью скриптов и приложений WMI. Дополнительные сведения о различиях между двумя технологиями см. в разделе Зачем использовать MI?
Программирование с помощью WMI
Приложения или скрипты управления могут получать данные или выполнять операции через инструментарий WMI на различных языках. дополнительные сведения см. в разделе "аудитория разработчика" на инструментарий управления Windows (WMI).
многие функции Windows имеют связанные с ними поставщики WMI, например поставщик данные конфигурации загрузки (BCD) или поставщик томов служба хранилища. поставщики wmi реализуют функциональные возможности, описанные в разделе методы и свойства классов WMI для управления связанными Windowsными функциями. Дополнительные сведения см. в разделе поставщики WMI и классы WMI.
Дополнительные сведения о создании поставщика для передачи данных из нового оборудования или приложений см. в разделе Предоставление данных инструментарию WMI.
Дополнительные сведения о реализации этой технологии см. в разделе Использование инструментария WMI.
Управление удаленными системами компьютеров с помощью инструментария WMI
Ценность WMI заключается в возможности получать данные об управлении с удаленных компьютеров. Удаленные подключения WMI осуществляются посредством DCOM. альтернативой является использование служба удаленного управления Windows (WinRM), которое получает данные удаленного управления WMI с помощью протокола на основе WS-Management SOAP.
Запрос с удаленных компьютеров с помощью командлетов CIM
Когда речь идет о PowerShell, многие люди сталкиваются с проблемами безопасности, но дело в том, что вы имеете точно такие же разрешения в PowerShell, как и в графическом интерфейсе пользователя. Ни больше ни меньше. Из предыдущего примера видно, что пользователь, запускающий PowerShell, не имеет прав на выполнение запроса WMI с сервера DC01. Я могу повторно запустить PowerShell от имени администратора домена, так как Get-CimInstance не содержит параметр Credential. Но это не совсем удобно, так как потом любая открытая в PowerShell программа будет запускаться с правами администратора домена. С точки зрения безопасности это действие может быть рискованным в зависимости от ситуации.
Используя принцип предоставления наименьших прав, я буду повышать уровень прав учетной записи администратора домена для каждой команды с помощью параметра Credential, если команда будет содержать такой же параметр. Get-CimInstance не содержит параметр Credential, поэтому решение для этого сценария заключается в том, чтобы сначала создать параметр CimSession. Затем я использую параметр CimSession для запроса WMI на удаленном компьютере вместо имени компьютера.
Сеанс CIM сохранился в переменной с именем $CimSession . Заметьте, что командлет Get-Credential я указываю также в круглых скобках, которые позволяют выполнить его первым, предлагая мне ввести альтернативные учетные данные перед созданием нового сеанса. Позже при рассмотрении этой главы я покажу вам более эффективный способ указывать альтернативные учетные данные, а пока важно усвоить основной принцип, чтобы потом уметь разбираться с более сложными понятиями.
Сеанс CIM, созданный в предыдущем примере, теперь можно использовать с командлетом Get-CimInstance для запроса информации BIOS из инструментария WMI на удаленном компьютере.
Использование сеансов CIM вместо ввода имени компьютера дает несколько дополнительных преимуществ. При выполнении нескольких запросов к одному и тому же компьютеру использовать сеанс CIM более эффективно, чем вводить имя компьютера для каждого запроса. При создании сеанса CIM соединение настраивается только один раз. Затем несколько запросов используют этот же сеанс для получения информации. При использовании имени компьютера необходимы командлеты для установки и разрыва соединения с каждым отдельным запросом.
Командлет Get-CimInstance по умолчанию использует протокол WSMan, то есть для подключения к удаленному компьютеру необходимо иметь PowerShell версии 3.0 или выше. По сути, важна не версия PowerShell, а версия стека. Версию стека можно определить с помощью командлета Test-WSMan . Стек должен быть версии 3.0. Эту версию можно найти с помощью PowerShell версии 3.0 и выше.
Прежние командлеты WMI используют протокол DCOM, совместимый с более старыми версиями Windows. Но в новых версиях Windows протокол DCOM обычно блокируется брандмауэром. Командлет New-CimSessionOption позволяет создать подключение протокола DCOM для использования вместе с New-CimSession . Это позволяет использовать командлет Get-CimInstance для взаимодействия с такими же старыми версиями Windows, как и у Windows Server 2000. Кроме того, это значит, что установка PowerShell не требуется на удаленном компьютере при использовании командлета Get-CimInstance с параметром CimSession, который настроен для использования протокола DCOM.
Создайте параметр протокола DCOM с помощью командлета New-CimSessionOption и сохраните его в переменной.
Для удобства вы можете сохранить в переменной свои учетные данные администратора домена или учетные данные с повышенными правами, чтобы постоянно не вводить их для каждой команды.
Я использую сервер SQL03 по управлением Windows Server 2008 (без R2). Это новейшая операционная система Windows Server, на которой средство PowerShell по умолчанию не установлено.
Создайте параметр CimSession на сервере SQL03, используя протокол DCOM.
Заметьте, что в предыдущем примере я указал в этот раз переменную с именем $Cred в качестве значения параметра Credential, а не вводил ее вручную.
Выходные данные запроса одинаковые, независимо от используемого базового протокола.
Командлет Get-CimSession используется для просмотра подключенных в данный момент параметров CimSession, а также используемых ими протоколов.
Получите и сохраните оба ранее созданных параметра CimSession в переменной с именем $CimSession .
Отправьте запрос с обоих компьютеров с помощью одной команды, при этом на первом должен использоваться протокол WSMan, а на втором — DCOM.
Я написал несколько статей в блогах о командлетах WMI и CIM. В одной из самых полезных статей описывается созданная мной функция, которая позволяет автоматически определить нужный протокол WSMan или DCOM, а также настроить сеанс CIM, не указывая протокол вручную. Эта статья называется PowerShell Function to Create CimSessions to Remote Computers with Fallback to Dcom (Использование функции PowerShell для создания параметров CimSession на удаленных компьютерах с помощью отката и DCOM).
Завершив работу с сеансами CIM, удалите их с помощью командлета Remove-CimSession . Чтобы удалить все сеансы CIM, передайте Get-CimSession в Remove-CimSession .
Читайте также: