Hardware Management Introduction

Applies To: Windows Server 2003 R2

Hardware Management in Microsoft® Windows® Server 2003 R2 comprises a set of features designed to improve management of server hardware. These features enable system administrators to securely manage remote server hardware across a firewall, using a standard Web service-based protocol. Working with Baseboard Management Controller (BMC) hardware attached to a server that supports WS-Management, the Windows Hardware Management components can communicate with the remote system even if the Windows operating system has not yet booted or has failed.

A BMC is a microcontroller that is attached locally to a server. BMCs include an independent network connection that can communicate over the network even if the server is offline. Through the BMC, system administrators can remotely monitor hardware state and errors and control the hardware in response.

Hardware Management is not installed by default when you install Windows Server 2003 R2. You must enable it from the Management and Monitoring Tools section of the Add/Remove Windows Components wizard. (See Enabling Hardware Management.)

System administrators can manage the Hardware Management components through command-line tools and scripting interfaces described below. No Windows graphical user interface is available to manage Hardware Management features in Windows Server 2003 R2.

The three components of Hardware Management are Intelligent Platform Management Interface (IPMI), Windows Remote Management (WinRM), and the Event Collector.

Intelligent Platform Management Interface (IPMI)

Hardware Management includes a Windows Management Instrumentation (WMI) provider and a driver for IPMI, an industry standard for BMC hardware architecture. As with all WMI providers, the functionality of the IPMI provider works both locally and remotely using WMI remoting over Distributed Component Object Model (DCOM), or through firewalls using the WS-Management protocol. The IPMI provider and driver support managing hardware “in-band,” that is, when the operating system is running.

The IPMI WMI provider exposes several classes that allow scripts and applications to communicate with BMC hardware through the kernel-level IPMI driver. The classes the provider exposes are:

  • AdminDomain

  • ComputerSystem

  • SystemSpecificCollection

  • LogRecord

  • Sensor

  • RecordLog

For details on the IPMI WMI provider classes, properties and methods, see the WinRM Software Development Kit.

The provider is a Microsoft implementation of a subset of the standard IPMI Common Information Model (CIM) Mapping Specification.

Windows Remote Management (WinRM)

Windows Remote Management (WinRM) is the Windows implementation of WS-Management, an industry-standard Web services-based protocol. WinRM provides a secure, efficient way for management applications and scripts to communicate with local and remote computers. The Windows service that WinRM installs and uses is also named WinRM.

When a server is connected to a BMC that supports the WS-Management standard, applications and scripts can use WinRM to communicate directly with the BMC, even when the operating system is offline (pre-boot or post-failure).

When a server is not connected to a BMC, WinRM can still be used to connect to WMI remotely in situations where DCOM communication is impeded (for example, across a firewall). This is possible because the WS-Management standard is firewall-friendly and uses a single port configurable by the system administrator.

WinRM exposes its own application programming interface (API) for scripting, which can be used by scripts written in any Windows Script Host-compatible language. The scripting API communicates with WMI using syntax different from standard WMI scripts. WinRM syntax is documented in the WinRM Software Development Kit. Hardware Management uses a WMI plug-in to expose WMI classes to WinRM. To call these classes, the WMI namespace and class must be converted into a Uniform Resource Identifier (URI). (See Configuration and Security.)

WS-Management is based on the following standard specifications:


  • SOAP over HTTP (WS-I profile)

  • SOAP 1.2

  • WS-Addressing

  • WS-Transfer

  • WS-Enumeration

  • WS-Eventing

WinRM Command Line Tool (Winrm.cmd)

The command-line tool provided as the primary administrative interface for managing WinRM is a batch file (Winrm.cmd) that runs a Visual Basic Scripting Edition (VBScript) script named Winrm.vbs. Because it is a script, you can open it as a text file and view the code to learn how it works. You can also write your own VBScript scripts that take advantage of the WinRM scripting API. Winrm.vbs runs under Cscript.exe, the command-line scripting engine of Windows Script Host.

Winrm.vbs enables system administrators to configure and manage WinRM. Because WS-Management is a Web service that uses XML as its message format, Winrm.vbs output is natively XML as well. The tool provides switches to output more readable XML or plain text.

The command-line usage (/?) of the tool provides detailed syntax and examples for its use. Windows Remote Management Command-Line Tool (Winrm.cmd) covers background and conceptual information on the tool and also provides extensive examples.

Event Collector

The Event Collector service is the third component of Hardware Management in Windows Server 2003 R2. This service is a Windows Remote Management client that is used to create subscriptions to WS-Management event providers and store the events received in the Windows System Event Log (SEL). Two scenarios are supported in R2:

  • Logging of hardware events from the local SEL when the operating system is running ("in-band"), using the IPMI driver and WMI provider.

  • Logging of hardware events from a remote server’s BMC using WS-Management (when BMC hardware supports this).

In case of an operating system shutdown or failure, Windows logs IPMI events into the BMC’s SEL. The administrator can then access the BMC's SEL using "out-of-band" tools to determine why a machine is not running.

Event Collector is managed with a command-line tool, Windows Event Collector Utility (Wecutil.exe).

BMC hardware has its own SEL in which it logs significant events. Through an Event Log plug-in and Event Collector, installed as part of Hardware Management, Windows Server 2003 R2 can subscribe to events stored in the BMC’s SEL so that they appear in Windows Event Viewer.

With Wecutil.exe, system administrators can create and manage event subscriptions to BMC events. Subscriptions require an XML configuration file: a sample, %windir%\system32\WsmSelRg.xml, ships with Windows Server 2003 R2.

The tool provides extensive command-line usage (/?) with examples. Further information is provided in the topic Event Collector.

Other Windows Remote Management Topics

The following topics discuss how to configure and use Hardware Management features, and describe the architecture underlying them.

Enabling Hardware Management

Because the Hardware Management feature is not enabled by default in Windows Server 2003 R2, you must explicitly enable it with the Add/Remove Windows Components Wizard. This topic explains how. It also discusses Plug and Play support for the IPMI driver.

Configuration and Security

Installation of Hardware Management involves configuring WinRM to work with HTTP or HTTPS. To use HTTPS, a server certificate is required. This topic discusses working with certificates, configuring listeners, and other configuration issues.

Integration with WMI

This topic discusses how to use the WMI plug-in of WinRM to access WMI classes through the WS-Management protocol. It describes how to convert a WMI namespace to a WS-Management URI.

Command-Line Interfaces

Two new command-line interfaces are installed with the Hardware Management component of Windows Server 2003 R2: Winrm.cmd and Wecutil.exe. These tools are used for WinRM management and event collection respectively.

  • Windows Remote Management Command-Line Tool (Winrm.cmd)

  • Windows Event Collector Utility (Wecutil.exe)


This topic discusses the evolution of industry efforts to define a common architecture for managing platform hardware. It then describes Microsoft's implementation, Windows Remote Management, and compares it with previous efforts.

Additional Resources