Accessing WMI data via WinRM

Windows Remote Management, better known as WinRM, provides an easy to use firewall friendly way to access Windows Management Instrumentation (WMI) data across different systems, using SOAP over HTTP protocol.

In a nutshell, WMI represents management data in an enterprise network, and WinRM provides a mechanism to exchange this data across different systems and hardware using the HTTP protocol.

More technical information on how WinRM and WMI are related can be found here.

Here we will focus on the actual examples showing how to exactly perform WinRM operations.


1st step, forming a Resource URI for any operation:

A WMI resource in the WinRM world is represented by a URI. For every WinRM operation, you first need to form a Resource URI on which the operation is targeted.

Let’s see how to form this URI.

So the URI for representing any WMI resource has the following prefix:

https://schemas.microsoft.com/wbem/wsman/1/wmi

Now let’s take some examples of URI’s for WMI.

URI’s which don’t specify any particular WMI class.

These types of URI’s are called “All Classes URI” and they are used for Enumeration operations, which involve a WQL query, or obtaining Association data.

Such a URI only targets a WMI namespace, and no specific class.

For e.g. an all-class URI specifying the WMI namespace root/cimv2 is as follows:

https://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/\*

URI’s specifying a WMI class.

Such URI’s are used for Enumeration operations, targeted at a specific class.

These are called “Class-Specific URI’s”.

For e.g. the URI for WMI class Win32_Service located in root/cimv2 namespace is as follows:

https://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32\_Service

URI’s specifying a WMI instance.

Such URI’s, which target a specific WMI instance, are used in Get, Put, and Invoke operations.

For e.g. say we want to target the windows service “winrm” which is an instance of the WMI class Win32_Service.

So the URI for that would be:

https://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32\_Service?name=winrm

 

Let’s take a different example where the class has more than 1 keys.

Say there’s a class named “MultipleKeys”, with 3 keys, K1, K2 and K3, where K1 is an integer, and its value is 1. K2 is an integer with value 2. K3 is a string with value “Three”.

Here the different keys can be given by adding a ‘+’ sign after previous key.

So the URI for this instance will be as follows:

https://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/ MultipleKeys?K1=1+K2=2+K3=Three

 

Let’s now take an example with a complex key.

Say there’s a class named “Complex”, with key K1. Here K1 is a string, and its value is “Key 1”.

So the URI for this instance will be as follows:

“https://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Complex?K1=Key 1”

Note: The double quotes around the whole URI is necessary in such cases where a key contains a space character.

 

Using DMTF specific URI’s for accessing WMI resources

Sometimes for interop reasons, users might need to use DMTF specific URI’s to get access to CIM data.

WinRM supports the usage of DMTF specific URI’s for accessing WMI data.

 

Users can provide version specific or version independent DMTF URI’s.

The version independent URI prefix is:

https://schemas.dmtf.org/wbem/wscim/1

And the DMTF URI prefix specifying CIM version 2 is as follows:

https://schemas.dmtf.org/wbem/wscim/1/cim-schema/2

 

All operations using the DMTF URI’s are defaulted by WinRM to the WMI namespace: root/hardware.

The user can however point to a different namespace using the __cimnamespace selector in the URI.

For e.g. if one needs to specify an all-classes URI for namespace root/cimv2 using DMTF version 2.0 prefix, the URI will be as follows:

https://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/\*?\_\_cimnamespace=root/cimv2

Another example, where the user specifies a class-specific URI for say class cim_Testclass in root/cimv2

https://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/cim\_testclass?\_\_cimnamespace=root/cimv2

If user needs to point to an instance of the above class, the URI would look like:

https://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/cim\_testclass?\_\_cimnamespace=root/cimv2+Key=Value

Note: DMTF URI’s can only be used for DMTF classes, not any other classes.

For e.g. the below URI will not work, as Win32_Service class is a Microsoft specific class, not a DMTF class.

https://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/win32\_service?\_\_cimnamespace=root/cimv2+name=winrm

 

Using URI aliases

It’s not exactly fun putting the complete URI’s for every single operation.

Here WinRM aliases come handy.

Just type “winrm help aliases” on the command-prompt and you will see a list of aliases for different URI prefixes that are supported by WinRM.

These aliases can replace the actual URI’s.

For example, ‘wmi’ is the alias for WMI URI prefix ‘https://schemas.microsoft.com/wbem/wsman/1/wmi’

So writing ‘wmi/root/cimv2/*’ is same as ‘https://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/*’

Similarly all aliases can replace their corresponding URI prefixes.

 

WinRM Operations

Now let us look at the different operations that WinRM supports to access WMI data.

The list of currently supported operations is:

· GET

· PUT

· ENUMERATION

· INVOKE

 

Soon to come: More about these operations . . .

Prashant Yadav [MSFT]