7/21/2014

HPSIM, Hyper-V guest WBEM enabling

HP SIM does not use WS-MAN for anything other than ILO or Onboard admin management processor.

HP SIM does use WBEM and SNMP as a way of remotely accessing WMI for Windows Server 2003, 2008, 2008r2, 2012 if the WMI Mapper is installed on Windows server.

[note: remember! for WS2012 if you install the SNMP Feature/Role, to access it through the "Server Manager" as opposed to using the legacy MMC services.msc plugin, otherwise a reboot will be necessary to see the SNMP configuration tabs, "Server Manager -> Tool -> Services" will display them immediately without a reboot]

There are several flavors and versions of the WMI Mapper, the one that comes with HP SIM, the one that is separately downloadable as a Windows MSI package from HP. And the ones that seem to be released as updated versions for all of the above.

I have found the latest doesn't seem to work as well as the older versions, and the change_logs seem to bare this out as a dependency problem that isn't well explained.

Therefore since we use 2008r2 and 2012, I chose to use the [ WMIMapper2_6_0.msi ] package on both the 2008r2 and 2012 versions of Windows servers.

In HP SIM

Options -> Protocol Settings -> WMI Mapper Proxy...

is used to configure a host that has a WBEM (WMI Mapper Proxy) service. In general I believe this is intended not to only map a single Host behind a firewall, but to perform the WMI mapping function for a whole subnet.. but it works just as well for an individual Host. So add the Public or Private IP address through which the "Host to be managed" will be accessed over port 5989.

So first the WMIMapper2_6_0.msi packager is copied to the target Hyper-V guest system that is to be managed and installed.

Then the Hyper-V guest system Firewall is configured to allow communications on the 5989 default port for WBEM traffic.

Finally an HP SIM -> Options -> Discovery task is configured, with [Credentials]-> [Advanced Protocols] ->[WBEM] and the domain\user and password are provided which was "granted" access to the DCOM service and the WMI datastore.

[NOTE: Do not FORGET to create a Special Rule in the Windows Guest Firewall to permit access to port 5589, or the WBEM service will not be accessible !!! ]

Upon running the Task, WBEM service will be discovered, and the credentials will be indicated as "valid" and working and the virtual machine guest hosts will be added to the default [Servers] container as a managable node. Pretty seamlessly.. the frustating part is that this is WBEM over a proxy agent called something like "WMI Mapper proxy..." which is entirely unintuitive from a Microsoft (who would have intuited WMI is a WBEM protocol service source?) and HP (who would have intuited that setting up a WMI Mapper proxy... source would grant access to a WBEM protocol service source?) and RPC/DCOM protocols default on the operating system to local administrative accounts accessing only locally (not remotely) would be enabled.. meaning you have to "grant" DCOM and WMI access rights? (again.. not intuitive)

The reason all of this is necessary and why it works, I believe is because port 5989 is the default port for WBEM traffic as part of a specification, Microsoft already had their version of WBEM called WMI built upon the RPC/DCOM methods supported by the WMI protocol, which unfortunately were not WAN friendly like WBEM.. that is available over a single fixed TCP port. Microsoft RPC/DCOM is based on a moving target range of ports assigned and indexed by an RPC locator service which doesn't exist as part of the WBEM protocol.. and in fact fixing it tends to break certain features.

So a true WBEM protocol Mapper called rather unintuitively a "WMI Mapper" translates true WBEM protocol port calls into local WMI Mapper calls to the WMI service on the Host and back again. In theory the WMI Mapper can also act as a gateway to other machines on the same subnet.. but this seem to run aground when dealing with local LAN complexities of remote invocation of RPC calls and default security.. which is what the last three steps are all about.. enabling a "Domain" wide user account permission to use the Remote Procedure calls through DCOM to access the WMI data store.. and finally granting access to that data store.

WS-MAN was to be a replacement for all of this and more closely align Microsoft WMI with WBEM, however HP SIM is a project that developes over time and ceases development periodically then resumes (except it is now scheduled to be retired in a couple of years).. and only used WS-MAN (the official RFC version) for managing some of their equipment, but not all operating systems.. so while WS-MAN is supported for HP equipment it is not for Microsoft operating systems.

Thus the best, only way to remotely manage a Microsoft operating system without Insight SNMP agents, or WBEM agents written by HP, for example on a Hyper-V virtual machine with no native HP SIM agents or "supported" WBEM capability.. is to install the HP SIM WMI Mapper package and add that as a WBEM proxy to get to the native WMI source on a virtual machine guest Host.

When its all done, HP SIM detects all that it needs to manage a Hyper-V virtual machine guest running Windows 2008r2 or Windows 2012 and properly recognizes it is of type "virtual machine" and is indeed a "virtual machine guest".

Another plus is that while you can "try" to install Insight SNMP agents on a virtual machine it will halt and not complete complaining "install not supported on virtual machine guests".

The WMI Mapper package however does install on a virtual machine, probably because installing the WMI Mapper on a SIM Host is supported on a virtual platform.

More Information includes additional details sourced from the WMI CIMOM datastore, status and configuration tabs appear to perform live inquiries directed at the virtual machine on command.