Hardware Management Architecture

Applies To: Windows Server 2003 R2

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.

Platform Hardware Management Today

Management of platform hardware is a significant part of overall IT administration cost. To address the needs of hardware management, and in particular to enable command and control of hardware components during pre-boot and post-failure of the main operating system, the OEM industry has been converging on a common architecture that includes a specialized Baseboard Management Controller (BMC). The BMC monitors the state of the server hardware and provides remote access to control this hardware, retrieve its state, and receive notifications about critical errors and other hardware state changes.

Several standards have emerged to define the architecture of BMC. The one that is getting the most traction in the industry is Intelligent Platform Management Interface (IPMI). However, in spite of the emergence of this standard, at the system administrator level the management access to server hardware remains highly proprietary to the individual platform implementations and requires use of proprietary management tools supplied by OEMs. This makes the administration experience platform-specific even for very basic operations. The problem is exacerbated by the fact that remote access to BMC is provided via a specialized wire protocol, Remote Management Control Protocol (RMCP), with non-standard security mechanisms.

To achieve uniformity of administration experience across operating system states, various proxy models can be employed. One of the suggested solutions is based on the existing Web-Based Enterprise Management (WBEM) protocol.

The following diagram illustrates that architecture:

This architecture has significant problems however:

• The WBEM protocol uses the HTTP transport with special extensions. This protocol has not been broadly adopted, mainly because it is not aligned with the Web services technologies.

• The protocol stack is not supported by the major operating systems’ development platforms in the box.

• To use WBEM the customers have to deploy additional components on each server, which increases cost.

• The architecture requires a proxy node that translates the WBEM operations to the wire-level IPMI messages.

The Microsoft Implementation

The key element of the Microsoft solution is a standard management protocol: WS-Management. WS-Management is defined in such a way that it scales from a low footprint environment to the operating system-hosted implementations. This introduces uniformity of the operations and a single security model between all operating system states. Because the protocol is defined as a profile of the standard Web services protocols it is also interoperable with non-Microsoft operating systems and development platforms. This creates an opportunity to address the existing customer concerns with high total cost of ownership (TCO) associated with the lack of standardization in managing multi-vendor heterogeneous data centers.

Because the protocol is defined as a composable standard it can be implemented in a resource-constrained environment. This eliminates the need for the low-level wire protocol altogether and thus eliminates the proxy node as a protocol translator. (The specific server architectures may still require a middle-tier node for other purposes.)

The following diagram illustrates the proposed architecture:

For the operating system operations, the architecture requires a few critical components in addition to the protocol stack. Those include a driver and an IPMI provider to expose BMC data and operations to the operating system. Windows Server 2003 R2 provides the customers with the first "industrial strength" implementation of this architecture.

WS-Management can also be used for remote Windows Management Instrumentation (WMI) where Distributed Component Object Model (DCOM) communication is not possible (for example, across a firewall). This is possible since WS-Management uses a single, firewall-friendly port configurable by the system administrator.