CIM osztályok lekérdezése WinRM-ben DMTF URI-val

(Ez is az IRF házi kapcsán jött elő, az egyik hallgató kérdezte, hogy már megint miért van az, hogy a Microsoftnak sikerült egy általános szabványt Windows specifikusan implementálnia. Utánanézve aztán kiderült, hogy a helyzet nem is olyan egyszerű…)

A probléma a következő. A WinRM segítségével információkat kérdezhetünk le távoli gépekről a WS-Management szabványban definiált protokollt használva. Például ha a távoli gép általános adataira vagyunk kíváncsiak:

C:\>winrm enum wmicimv2/CIM_ComputerSystem -r:winxp-vm -u:administrator -p:password
Win32_ComputerSystem
    BootupState = Normal boot
    Caption = WINXP-VM
    CreationClassName = Win32_ComputerSystem
    Domain = WORKGROUP
    ...

Az enum (enumerate) kilistázza az adott ResourceURI-hoz tartozó osztály összes példányát a -r kapcsolóval megadott gépen. A ResourceURI-ban szépen a platform független osztálynevet (CIM_ComputerSystem) használtuk a Windows specifikus helyett (Win32_ComputerSystem), azonban az URI eleje még nem jó, a wmicimv2 alias Windows specifikus:

C:\>winrm help alias
Windows Remote Management Command Line Tool

Aliasing allows shortcuts to be used in place of full Resource URIs.
Available aliases and the Resource URIs they substitute for are:

wmi      = http://schemas.microsoft.com/wbem/wsman/1/wmi
wmicimv2 = http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2
cimv2    = http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2
winrm    = http://schemas.microsoft.com/wbem/wsman/1
wsman    = http://schemas.microsoft.com/wbem/wsman/1
shell    = http://schemas.microsoft.com/wbem/wsman/1/windows/shell

Ott van a cimv2, az látszik a szabványosnak, használjuk azt! No, itt kezdődnek a gondok:

C:\>winrm enum cimv2/CIM_ComputerSystem -r:winxp-vm -u:administrator -p:password
WSManFault
    Message
        ProviderFault
            WSManFault
                Message = The WS-Management service cannot process the request.
The service cannot find the resource identified by the resource URI and selectors.

Error number:  -2144108544 0x80338000
The WS-Management service cannot process the request. The service cannot find th
e resource identified by the resource URI and selectors.

Az előbb még megvolt a CIM_ComputerSystem, most pedig nincs sehol. Ezzel az MS látszólag kilőtte annak a lehetőségét, hogy platform független scriptet írjak, hisz ha egy windowsos gépet akarok távolról lekérdezni, akkor a microsoftos prefixet kéne használni, és nem a dmtf-eset. Ez nem lenne szép dolog:) Elkezdtem utánanézni, hogy miért nem találja meg a CIM_ComputerSystem-et. A következő kapcsolódó leírások állnak rendelkezésre:

• DSP0226, Web Services for Management (WS Management): DMTF specifikáció a WS-Management protokollról. Csak a protokoll elemkészletét adja meg, a CIM osztályok lekérdezésével nem foglalkozik.
• DSP0227, WS-Management CIM Binding Specification: DMTF specifikáció, ez ad ajánlásokat, hogy hogyan kell kinéznie a ResourceURI-nak, ha egy CIM osztályt szeretnénk lekérdezni.
• MS-WSMV, Web Services Management Protocol Extensions for Windows Vista: a Microsoft specifikációja, hogy ők hogyan implementálták a WS-Management protokollt, mit változtattak esetleg rajta, mit implementáltak az opcionális részekből.

A MS-WSMV-t megfelelő részét nézegetve, vagy pl. ezt a blog bejegyzést olvasva (Accessing WMI data via WinRM) szemet szúrhat, hogy mi a gond:

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

Így már érthető, a root/hardware alatt a különböző HW menedzsment szabványok (pl. IPMI) által kiajánlott adatok találhatóak, ilyen névtér Windows XP-n nincs is (WMI Explorerben ellenőrizhető), úgyhogy jogos a ResourceURI nem található hiba. A WinRM a Windows Hardware Management részeként jelent meg a WS2003-ban ha jól emlékszem, és gondolom ezért lett a root/hardware az alapértelmezett névtér. A többi WS-Management implementáció (pl. az openwsman) viszont a root/cimv2-t használja alapértelmezésként. Sajnos mindkettő megfelel a DMTF szabványnak, ugyanis a DSP0227 “5.3 Accounting for Different CIM Namespaces” része ennyit mond:

“The absence of this Selector in a message indicates the intended resource(s) is in the default CIM
namespace for that service. This specification does not define what the default CIM namespace should be.”

Tehát bárki azt használ alapértelmezettnek, amit akar:( Ugyanez a rész felhívja a figyelmet arra, hogy lehet névteret váltani egy ResourceURI-ban a __cimnamespace választó (selector) segítségével, de előtte még ki akartam próbálni, hogy mi van akkor, ha létezik a root/hardware névtér.

Ehhez egy Windows Server 2008 virtuális gépet kérdeztem le, amire a legfrissebb WinRM 2.0 CTP 3 volt telepítve:

c:>winrm enum cimv2/CIM_ComputerSystem -r:sicily

The result is:

WSManFault
    Message
        ProviderFault
            WSManFault
                Message = HRESULT = 0x80041001

Error number: -2147023537 0x8007054F
An internal error occurred.

Itt már megtalálta a root/hardware névteret, csak mivel ez egy virtuális gép volt, amiben nincsen értelemszerűen IPMI, nem tudta lekérdezni az ott lévő osztályok példányait. Azért ez az internal error nem túl beszédes:) Ezek a CIM osztályok vannak egyébként a root/hardware névtérben:

PS C:\> Get-WmiObject -list -namespace root/hardware | ? { $_.name -like "CIM*" } | select name | sort -property name

Name
----
CIM_Account
CIM_AdminDomain
CIM_AuthorizedPrivilege
CIM_Collection
CIM_ComputerSystem
CIM_ConcreteCollection
CIM_EnabledLogicalElement
CIM_Group
CIM_Log
CIM_LogicalDevice
CIM_LogicalElement
CIM_LogRecord
CIM_ManagedElement
CIM_ManagedSystemElement
CIM_NumericSensor
CIM_Privilege
CIM_RecordLog
CIM_RegisteredProfile
CIM_Sensor
CIM_System
CIM_SystemSpecificCollection

Vissza akkor az eredeti témához, próbáljuk névtér váltással lekérdezni a root/cimv2-ben lévő CIM_ComputerSystem-et szabványos URI-n:

C:\>winrm e http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_ComputerSystem?__cimnamespace=root/cimv2  -r:192.168.255.128 -u:administrator -p:password

WSManFault
    Message
        ProviderFault
            WSManFault
                Message = The WS-Management service cannot process the request.
A DMTF resource URI was used to access a non-DMTF class. Try again using a non-D
MTF resource URI.

Error number:  -2144108231 0x80338139
The WS-Management service cannot process the request. A DMTF resource URI was us
ed to access a non-DMTF class. Try again using a non-DMTF resource URI.

Na, ez volt a kedvenc hibaüzenetem:) Mi az, hogy nem DMTF osztályt akarok elérni, mind a prefix, mind az osztálynév DMTF specifikus! A CIM_ComputerSystem az egyik legalapvetőbb CIM osztály, és benne van az összes CIM specifikációban. Hosszas keresgélés után ez az apró félmondat segített (MS-WSMV, 3.3.5.1 ResourceURI for CIM classes):

Web Services Management Protocol Extensions for Windows Vista service and clients MUST use the http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/ namespace prefix followed by the class name when accessing DMTF classes. The classes in WMI are considered DMTF classes if they have a version qualifier with major number equal to 2.

Aha, tehát attól lesz a WinRM szerint egy WMI osztály DMTF osztály, ha 2-es a major verziószáma.

Gyors ellenőrzés wbemtest.exe-vel. A root/hardware-ben lévőknek van Version minősítője (qualifier), a root/cimv2-ben lévőknek nincs. Ha hozzáadjuk kézzel a Version minősítőt, akkor már megy rendesen a cimv2/CIM_ComputerSystem ResourceURI segítségével is a lekérdezés.

Tehát a következő két dolgot kell tenni, ha a DMTF-es prefixet akarjuk használni WinRM-ben:

• __cimnamespace segítségével átváltani a root/cimv2 névtérbe,
• a lekérdezendő osztályhoz a célgépen hozzáadni a Version minősítőt.

A problémát jelentettem a Connecten, az eredmény annyi lett, hogy bug-ot lezárták Resolved (External) eredménnyel egy napon belül, de még mindig privát, és semmit se írtak rá 2 hónapja:(

Zárásként térjünk vissza a nyitó kérdésre, hogy vajon az MS megint nem követi-e a szabványokat. A szomorú az, hogy a WinRM implementáció jelen esetben teljesen szabványos (a DMTF specifikáció nem ír elő alapértelmezett névteret), és a dokumentációnak megfelelően működik (megmondták, hogy akinek van 2-es Version minősítője, azt tekintik DMTF osztálynak), azonban a szabvány lazasága miatt mégis úgy tűnik elsőre, hogy nem követi a specifikációkat.