Windows 2003 Server EMS core Hardware
Introduction
The Microsoft Windows operating system provides many mechanisms for managing a system when Windows is loaded, fully initialized and the system is functioning. This type of system management is called “in-band” and typically occurs over the network. However, a different solution is required for managing a system when the system has failed or when Windows is not loaded, is in the process of loading, or is in distress, because Windows network software is not available. This type of system management is called “out-of-band” management.
The goal for out-of-band management is always to return the system to a fully functioning state where in-band management is available. Making both in-band and out-of-band management available remotely are key components of headless functionality. With the exception of hardware replacement, all administrative functions that can be accomplished locally should be available remotely. For example, it should be able to accomplish the following remotely:
•Power on a system that is currently off
•Change BIOS settings or view POST results
•Choose the operating system, set operating system options
•Interact with specific diagnostic and recovery tools
•View system blue-screens
•Reset a system
To accommodate the many possible system operation states, careful thought must be given to hardware, firmware, and operating system functionality to ensure a comprehensive and complementary implementation of out-of-band management capabilities. Each system component must contribute to the coherent, complementary solution in order to avoid expensive, confusing administration.
This paper summarizes the design issues and requirements for hardware and firmware that will ensure coherent, complementary functionality for out-of-band management of a headless system running Microsoft Windows.
Headless Implementation in the Windows Server 2003 Family
A headless solution requires removal of local console I/O dependencies in the operating system. Windows Server 2003 supports operating without a keyboard, mouse, or monitor attached to the system. On an ACPI-enabled system, Windows Server 2003 supports operating without a legacy 8042 keyboard controller. Windows Server 2003 also includes support for systems without VGA/video hardware.
Based on built-in Windows support, a USB-capable system running Windows Server 2003 can support hot plugging the mouse and keyboard while Windows is running, and a system with a VGA card can support hot plugging a monitor.
In Windows Server 2003, out-of-band console I/O support is provided for all Windows kernel components, the loader, setup, recovery console, Windows kernel, blue-screens and a text mode management console available after Windows Server 2003 has initialized called the Special Administration Console. This functionality is called the Emergency Management Services (EMS). This I/O conforms to the following by default:
•9600 baud
•1 stop bit
•No parity
•8 data bits
•No flow control
•Output conventions are defined in “Standardizing Management Console Output on the Serial Port Interface (VT100+)” later in this paper.
Note that these settings were chosen because they are the current “standard” configuration in UNIX administration world and allow interoperability. However, additional settings are supported if they are passed via the Serial Port Console Redirection Table. It is suggested that higher baud rates be used whenever possible and legacy VT100 support is not a concern. The specification for the Serial Port Console Redirection Table can be found at http://www.microsoft.com/hwdev/platform/server/headless/default.asp
Designing Hardware and Firmware for Windows Server 2003 Headless Systems
There are three key areas that must be addressed to provide a high quality headless platform that is cleanly integrated with Windows Server 2003 EMS. The section of this paper covers these three areas.
The first area is management port hardware: The Windows Server 2003 family will support a standard legacy serial port. Provided hardware support is available for testing, the Windows Server 2003 family will also support systems with more advanced management hardware, that provides a UART interface in system I/O space or Memory Mapped I/O.
The second area is a standardized firmware and management console user interface. It is important the system firmware and out-of-band management service processor user interface be available via the same out-of-band communication channel as the EMS. The firmware must cleanly hand the communication channel off to the EMS during the boot process. The firmware must use the same terminal definition as Windows Server 2003 EMS and use the same keystrokes to represent not standardized keystrokes such as F12 as specified later in this paper.
The third area is the passing of the out-of-band communication channel configuration information from the firmware to Windows Server 2003. This is achieved via the Serial Port Console Redirection Table.
Providing Legacy Out-of-Band Management Port Hardware for Use with EMS
The headless functionality in the Windows Server 2003 family supports a standard (16550) serial port at the legacy address of COM1, COM2, COM3 or COM4 (3F8, 2F8, 3E8 and 2E8 respectively) or a UART at well known non-legacy address as described in “Providing Non-Legacy Out-of-Band Management Port Hardware for Use with EMS” A server must provide at least one UART interface capable of use by Windows Server 2003 EMS. Windows EMS does not make use of legacy PC interrupts even when using a legacy com port.
When using a serial port connection to access Windows EMS support, all serial cables must be null modem cables that support the Carrier Detect (CD) signal. Windows will not provide console I/O if Carrier Detect is not active. Note: Cables with Carrier Detect shorted to RTS (Ready to Send) will work.
Providing Non-Legacy Out-of-Band Management Port Hardware for Use with EMS
This describes requirements for either a serial port or service processor.
The guidelines in this section apply for service processors configured to use an I/O location other than the legacy COM port address.
The legacy COM port on a Super I/O chip is an ideal out-of-band management port. It provides a serial port at a well-known address, and the hardware is reliable and fully defined. Therefore, Windows Server 2003 support for the out-of-band management port communicates with a UART device that uses a serial protocol, typically at a standard COM port address.
Notice, though, that it is a goal for the industry to move to “legacy free” systems that are designed without Super I/O chips or legacy COM ports. To expose the same serial-port functionality in legacy-free system, the mechanism of choice is a UART in PCI I/O space, which can be as simple as a serial port on a PCI card.
However, several OEMs produce add-on management devices for controlling the computer in its pre-boot state. A natural extension of these devices is to use them as the EMS I/O device.
Using Windows software in conjunction with OEM-supplied device provides several benefits. Software-only solutions typically cannot provide all the functionality found on these OEM management boards (hardware reset, power on, and so on). However, combining both hardware and Windows software solutions can achieve an extremely compelling solution for corporate customers.
The non-legacy UART interface in PCI I/O space can be exposed regardless of the underlying device or its external connection. This allows the Windows Server 2003 EMS to use the same simple programming model, regardless of the device or bus that this device uses. The OEM can also abstract the output of the interface such that it is no longer restricted to a serial cable. For example, some of these devices have an RJ45 connector, allowing customers to extend their investment in Ethernet network cabling by implementing a private management network while avoiding the problems and cost of serial cable deployment.
NOTE: Support for non-legacy UARTs in system I/O on 32 and 64 bits and MMIO in the 64-bit versions of the Windows Server 2003 family is dependent on hardware being available for testing. If hardware is not available, only UARTs at the legacy addresses of COM1 and COM2 will be supported.
Out-of-Band Management Port Device Requirements
This section lists the requirements for the out-of-band management port device for the Windows Server 2003 family.
1.UART control register must function as a standard UART Device
The device must act as a 16550 or 16450 UART. Windows Server 2003 will test this device using the following process.
1. Save off the current modem status register.
2. Place the UART into diagnostic mode (The UART is placed into loopback mode by writing
SERIAL_MCR_LOOP to the modem control register).
3.The modem status register is read and the high bits are checked. This means SERIAL_MSR_CTS, SERIAL_MSR_DSR, SERIAL_MSR_RI and SERIAL_MSR_DCD should all be clear.
4.Place the UART in diagnostic mode and turn on OUTPUT (Loopback Mode and OUTPUT are both turned on by writing (SERIAL_MCR_LOOP | SERIAL_MCR_OUT1) to the modem control register).
5.The modem status register is read and the ring indicator is checked. This means SERIAL_MSR_RI should be set.
6.Restore original modem status register.
2.UART control register must be at a well-known address
The current plan is: On x86 systems, this address must exist exclusively in system I/O space (which includes legacy COM port address). On IA-64 systems, this address must exist at a legacy COM port address or in Memory Mapped I/O. Support for addresses other than legacy COM ports will be determined largely based on support by Hardware that OEM’s are able to supply.
3.Device that the UART is on must be available before Windows is loaded
In particular, the device must be available to the Windows loaders. This implies that the device must be configured by the BIOS during POST.
Recommended: The BIOS should expose the out-of-band management port in such a way that the port is available for redirecting BIOS initialization screens or that the surrounding hardware redirects the BIOS screens through some other method (“screen scraping”).
4.UART device must always be available to the system
For the Windows loader to communicate with this device, the address must be “pre-translated” to the processor-relative address, because the loader cannot call into the hardware abstraction layer (HAL) in order to translate a bus-relative address to a processor-relative address.
5.Address of the UART device may not change
The Windows headless software is not Plug and Play-aware, and it only stores the translated address for a device. If the device address were to be relocated, the headless software that wrote to the translated address would write to an invalid system address.
6.System has exclusive access to the out-of-band management port
The system will write directly to the out-of-band management port instead of going through the Windows I/O Manager. No device driver, for example, should also try to write to this device. In particular, there is no Windows support for a “crashport” that is only invoked upon a blue-screen, similar in concept to crashdebug.
7.System can include only one out-of-band management port
The Windows Server 2003 family does not support any scenario where one device is the output out-of-band management port and another device is the input out-of-band management port.
8.Out-of-band management port must remain highly available
For example, the device should not be powered off while the system is running.
Out-of-Band Management Port Implementation
The following describes how Windows Server 2003 and hardware must function together for proper EMS out-of-band management port detection and interaction.
Mechanism must be provided for determining the base address of the out-of-band management port
Windows Server 2003 performs a series of checks to detect the base address of the out-of-band management port. The following is the order of precedence of the settings that are checked (that is, 1 supercedes 2). For a system that will support Windows Server 2003 EMS, one of these mechanisms must be provided.
1.User specifies address in Boot.ini (IA 32 only). The user can indicate that one of the legacy COM ports is to be used for headless operation. By detecting the keywords COM1 or COM2 in Boot.ini for redirection, the system can deduce the I/O address of the device, because these devices are always at a well-known address. This is the least preferred method, because it allows conflicts between Windows and BIOS settings.
2.System detects address in Serial Port Console Redirection (SPCR) ACPI table (ACPI-enabled platforms). An ACPI BIOS can implement the SPCR ACPI table, which indicates the address of the out-of-band management port. This address must be pre-translated to a processor-relative address.
3.System detects address from EFI-based console output handle (IA 64 only). Windows can examine the console device handle (which may include “sub-device paths” to determine whether they are “headless” devices. If the device path for the console device is a UART device, the device path will have a UART device sub-path. Windows can then look at the other parts of the device path to determine the base address of the port. This might include examining the ACPI portion of the device path for the _CRS, and so on. Base addresses of PCI devices are not determined using this method.
Device initialization must be handled by BIOS
The headless-aware BIOS or system firmware must configure the out-of-band management port during POST so that BIOS startup screens and the Windows loader screens can be redirected during system startup.
Out-of-band management port base address must not change
This may be achieved in one of these ways:
•Out-of-Band management port resides on a bus that doesn’t relocate. If the out-of-band management port is a COM port on the ISA bus, then the port address will not move. If the device is on the PCI Root Bus, the device address will not move, because the root PCI bus also receives special treatment in Windows Server 2003; however, in future versions of Windows this may not be the case.
•Non-standard devices can be claimed by BIOS. Here, “non-standard” refers to any device not defined in ISA or PCI space. An ACPI BIOS can implement a Motherboard Resources Device for a non-standard out-of-band management port. This prevents the device resources from being claimed by another resource.
•Windows Server 2003 PCI Bus driver prevents device from being moved. During system initialization, the system bus drivers will initialize the devices on their respective bus. The bus initialization must be able to detect an out-of-band management port on the bus and ensure that the device is not moved. For Windows Server 2003, PCI is the only bus besides ISA that will be supported by Windows EMS. If the BIOS provides the PCI information in the Serial Port Console Redirection ACPI fixed table or the EFI console device path points to an appropriate headless port, then Windows will ensure that the device will not be powered off or moved.
This device will not be enumerated by PNP. This protects the port from having a PNP driver being loaded for it or being moved by PNP. Because the device will not be enumerated by PNP, none of the other functions of the device falling under the same header as the Out-of-Band management port will be enumerated, making it impossible to associate a device driver with the other functions on this device. These other devises must have their own PCI headers and decode logic.
A PCI Out-of-Band management port device can be located using the SPCR ACPI table, which provides sufficient information to describe the out-of-band management port. This data includes PCI bus, slot, and function number for the device. In addition, the device ID and vendor ID for the device will be included in the table. (0xFFFF vendor ID and device ID will indicate an ISA device in the SPCR table.)
Exclusive access to device must be enforced
•The system firmware can use the out-of-band management port for redirecting it’s UI.
It is recommended that the BIOS or service processor redirect all output until serial traffic is detected. The first character of the detected serial traffic must be transmitted. In this scenario, Carrier Detect on UART must be held high even when console redirection in occurring. Once serial traffic is detected, Windows EMS must have full and exclusive access to the out-of-band management port.
If no serial traffic detection code is implemented, once Int 19 on BIOS systems or ExitBootServices on EFI systems has been called, the Windows EMS must have full and exclusive access to the out-of-band management port.
•The out-of-band management port must always be present and available. It may not disappear or become inaccessible for writes or reads.
•Windows Server 2003 detects the out-of-band management port and does not expose this device to any higher-level interfaces.
Implementing Firmware for Headless Systems
The firmware must provide the Serial Port Console Redirection (SPCR) table, which allows Windows to determine the location and setting used by the firmware for console I/O on the serial port. This could be used to automatically match the Windows configuration with the firmware configuration.
The BIOS must support PXE-compatible network adapters, as defined in Preboot Execution Environment (PXE) Specification, Version 2.1, available at http://developer.intel.com/ial/wfm/wfmspecs.htm. For EFI-based systems, the remote boot protocols are defined in the EFI specification. See also “RIS and PXE Requirements” later in this paper.
It is important the firmware configuration, e.g. BIOS Setup, be available via the same out-of-band management port as Windows Server 2003 Emergency Management Services. If the out-of-band management port that the EMS uses is a legacy serial port, the BIOS or system firmware must redirect its console I/O to the same serial port and settings that Windows supports. Furthermore, if the redirection settings can be configured, they should default to the Windows-compatible settings cited earlier: COM1 9600 baud, 8N1 without flow control.
Serial console I/O must be in the format of VT100 plus the conventions defined in “Standardizing Management Console Output on the Serial Port Interface (VT100+)” later in this paper.
Firmware Localization Requirements
If the firmware uses a language other than English, the serial port output must be in UTF8 format as defined by the UNICODE Group (see http://www.unicode.org/).
•On a BIOS-boot system, the language used by the BIOS must be defined in the Serial Port Console Redirection Table (see http://www.microsoft.com/hwdev/platform/server/headless/default.asp).
•On an EFI-based system, this information is stored in the global environment variables as defined in the EFI specification, version 1.0 or later.
RIS and PXE Requirements
The Windows Server 2003 family provides Remote Install Services (RIS) on servers. This allows remote, network-based installation of the Windows EMS on a clean system. To take advantage of this capability, a network adapter that is PXE capable is required, as defined in Preboot Execution Environment (PXE) Specification, Version 2.1.
A PXE capable network adapter is not required. However, if a network adaptor that is PXE capable can be inserted into the system, the system firmware or BIOS implementation must allow the PXE boot to be a selection for the boot order. For example, an administrator might configure the BIOS to attempt to boot in this order: hard drive, CD-ROM, floppy drive, network.
Furthermore, the system firmware or BIOS must provide an option that the administrator can use to initiate a remote boot by way of a keystroke, in effect circumventing the boot order list. This key should be F12.
Being able to specify and circumvent boot order allows implementation of useful emergency recovery scenarios (see “Scenarios” later in this paper).
Designing Service Processor/ASIC or UPS
A service processor/ASIC UPS can provide headless management in conjunction with the support in the Windows Server 2003 family. The Service Processor/ASIC can provide support for dealing with management tasks that Windows Server 2003 can not provide, such as powering on the system, resetting the system when it is hard hung, retrieving Field Replaceable Units information or performing hardware diagnostics. They can also provide secured output on mediums more complicated than serial ports, such as HTTP on TCP-IP on Ethernet.
Service Processor/ASIC General Functionality Requirements
The ASIC or service processor must provide a mechanism to reset the system. The There are many opportunities for value-added capabilities while still adhering to these guidelines. For instance, Field replaceable units (FRUs) and sensor data etc. may be provided.
Service Processor/ASIC Internal Hardware Interface Requirements
To provide complementary functionality Windows Server 2003 EMS and the Service Processors must both be available to the remote Administrator. To this end, the Service Processor/ASIC must provide a pass-through connection between Windows and the management system. This allows the user to interface to both the service processor and Windows Server 2003 EMS via a single connectivity medium and a single cable.
The service processor/ASIC must provide a 16550 (preferred) or 16450 UART in system I/O (which includes legacy COM port addresses) on IA32, and MMIO or at a legacy COM port address on IA64, as an internal hardware interface. This UART hardware Interface must always be available to Windows Server 2003 EMS. I.E. The UART interface must be provided by hardware or firmware not a Windows Device driver so that it is available when the Windows Server 2003 Loader is running, when Windows Server 2003 is fully loaded and when there has been a blue-screen etc. This UART may not disappear or become unavailable to write to at time. For more information on the implementation of Out-of-Band management port hardware, see the above sections entitled “Providing Legacy Out-of-Band Management Port Hardware for Use with EMS” and “Providing Non-Legacy Out-of-Band Management Port Hardware for Use with EMS.”
NOTE: Support for non-legacy UARTs in system I/O on 32 and 64 bits and MMIO in the 64-bit versions of the Windows Server 2003 family is dependent on hardware being available for testing. If hardware is not available, only UARTs at the legacy addresses of COM1 and COM2 will be supported.
Non-legacy UART interfaces must be described fully in SPCR table. On IA32 systems, legacy COM ports should be described fully by the SPCR table. On IA64 systems, legacy COM ports must be described fully by the SPCR table (preferred) or via EFI console device path.
Service Processor/ASIC External and User Interface Requirements
These guidelines allow freedom of design in the in external and user interface while maintaining usability and integration of Windows Server 2003 EMS and Service Processor/ASIC. The Service Processor/ASIC may expose varying external hardware interfaces, such as serial port, RJ45 (Ethernet) or a proprietary connector. Furthermore, some external interfaces may support more than one communication protocol, e.g. Ethernet supports telnet, sockets and HTTP traffic among others. However, from the standpoint of these guidelines, these can be divided into two categories, those that can output only a single channel of communication e.g. serial ports with VT100, and those that can output multiple channels simultaneously e.g. Ethernet with HTTP.
Single Channel External Interfaces
When the external interface to the Service Processor/ASIC is a single channel external interface such as the serial port, it is only possible the user to interact with one Out-of-Band management entity at a time. The EMS and the service processor must be able to share this external interface in a reliable and useable way. To this end integration between the Windows Server 2003 EMS and the Service Processor/ASIC is particularly important since during the boot process the user will be using the same user interface, typically some form terminal to interact with both, and expect the same I/O conventions to be followed by both.
During the boot process the typical user experience must be
1)Power on the system (if supported) – Service Processor/ASIC Functionality
2)View and optionally interact with FW POST – Service Processor/ASIC and Firmware Functionality
3)View and optionally interact with the Windows Server 2003 Loader – EMS Functionality
4)View and optionally interact with the Special Admin Console (SAC) – EMS Functionality
The Firmware and Service Process must allow Windows Server 2003 Full control of the service processor after step 2 so that step three and on may occur. These means that complete control of the internal UART interface must be available and the Service Processor/ASIC must provide pass-through port functionally that allows Windows Server 2003 EMS to communication directly with in a manner exactly equivalent to a standard terminal attached via a null modem to a serial port.
During normal operation, service processor/ASIC must allow unconstrained communication between Windows and the management system. In this case Standardizing Out-of-Band Management Console Output and Terminal Emulation (VT-UTF8 and VT100+), available at http://www.microsoft.com/hwdev/platform/server/headless/default.asp, provides a mechanism to invoke and exit the Service Processor or ASIC. When the pass through-port is in use by windows, the service Processor must “snoop” the traffic on the pass through port for the proper escape sequence. The ASIC or service processor may interrupt the Windows use of the pass-through port when the appropriate escape sequence is sent from the management system and the Service Processor/ASIC “snoops” it. Then the Service Processor/ASIC sends an escape sequence as an acknowledgment to the management system that it has been invoked and then present its user interface on the serial connection.. The Service Processor should intercept the escape sequence used to invoke it and any serial traffic that follows the escape sequence until it returns to pass through mode. When the service processor is not in pass through mode, it should lower Carrier Detect (see the section “Exclusive access to device must be enforced” in this paper for the special case of initial BIOS/Service Processor console redirection) unless it buffers all data from EMS. Such a buffer should be configurable to on or off. The Service Processor must return to pass-through mode when the appropriate escape sequence is sent be from the management system. These escape sequences requirements are documented in Standardizing Out-of-Band Management Console Output and Terminal Emulation (VT-UTF8 and VT100+), available at http://www.microsoft.com/hwdev/platform/server/headless/default.asp.
Service Processor/ASIC Serial Port Pass-through Topology
When the service Processor is invoked and the user is interacting with it certain escape sequences must initiate specific behavior. These escape sequences and behaviors are documented in Standardizing Out-of-Band Management Console Output and Terminal Emulation (VT-UTF8 and VT100+), available at http://www.microsoft.com/hwdev/platform/server/headless/default.asp.
If the Service Processor/ASIC did not use the same conventions as the EMS, the user would have an extremely difficult time sending the proper commands escape sequences. A standard terminal must be used to maintain interoperability between Windows NET Server EMS and service processor from multiple systems from multiple vendors. However, no standard terminal covers the additional extended keys on the PC 101 keyboard e.g. neither VT100 nor any other standard terminal has an F12 key or a standard way of encoding it on the wire. To this end, Standardizing Out-of-Band Management Console Output and Terminal Emulation (VT-UTF8 and VT100+), available at http://www.microsoft.com/hwdev/platform/server/headless/default.asp, is provided. The service processor/ASIC and firmware must adhere to the same terminal conventions as described in the Standardizing Out-of-Band Management Console Output and Terminal Emulation (VT-UTF8 and VT100+), available at http://www.microsoft.com/hwdev/headless. The user interface must be accessible via a terminal or terminal emulator supporting either VT100+ or a terminal VT100.
Multiple Channel External Interfaces
When the external interface to the Service Processor is a multiple channel external interface, as LAN connection may be, the requirements for providing access to the EMS change slightly. The channel for EMS communication must always be available regardless of whatever other management tools and communication is ongoing.
The client software provided to manage the out-of-band functionality provided by the Service Processor/ASIC must provide a terminal interface that the administrator may use to directly access the EMS. The terminal portion of the client must behave as a standard 80X25 terminal supporting VT100 or VT100+, i.e. the experience of the user should be that of attaching a terminal via a null modem cable to a serial port.
In the multi channel scenario the service processor is not required to provide any interaction with it’s user interface via this terminal screen. However In this case, the required service processor/ASIC and firmware functionality must be available elsewhere in the client user interface. If the firmware is available through this console, the firmware must adhere to the guidelines in “Implementing Firmware for Headless Systems.” If the Service Processor/ASIC is available through this console, the Service Processor/ASIC must adhere to the guidelines in “Single Channel External Interfaces”.
UPS Requirements
An Uninterruptible Power Supply (UPS) can provide control of the power supplied to the server, which can in turn provide rudimentary management capabilities such as remote control of power off and power cycling. For the purpose of this document the term UPS also represents smart power switches which can offer the same management capabilities of a smart UPS but without the functionality of maintain power to the server when external power is lost.
A UPS can also allow serial communication to pass through it between a management system and the Windows headless server. That is, the management port could have a serial connection to an external serial port on the UPS, which could have a serial connection to the Windows headless server. If a UPS uses a pass-through serial port interface externally, this port must allow unconstrained communication between the system for which the UPS provides backup power, the management system, and Windows. The UPS can interrupt the use by Windows of the pass-through connection by way of an escape sequence sent from the management system. Using this mechanism a smart UPS can provide some of key basic functions of an onboard service processor for systems only have a serial port.
Note: To take advantage these capabilities, a server must be configured to automatically boot when power is applied.
Note: Some UPS provide applications that access the UPS, from the server being powered, via a serial port. The serial connection being used for EMS, between the UPS and the Server, cannot be accessed by an application on the server to access and configure the UPS. This requires 2 serial connections.
The following requirements apply for any UPS to be used to in conjunction with Windows NET Server EMS:
•The UPS must provide a mechanism to reset the system.
•The entire end-to-end pass-through serial path must present the serial signals from the system to be managed to the management console as though from a serial port through a null modem cable as described in “Selecting Hardware for Headless Systems” earlier in this paper.
UPS Pass-through Topology
•The UPS may interrupt the Windows use of the pass-through serial path when the appropriate escape sequence is sent from the management system. The UPS sends an escape sequence as an acknowledgment to the management system that it has been invoked and presents, if one exists, its user interface on the serial connection. The UPS should intercept the escape sequence used to invoke it and any serial traffic that follows the escape sequence until it returns to pass through mode. When the UPS is not in pass through mode, it should lower Carrier Detect unless it buffers all data from EMS. Such a buffer should be configurable to on or off. The UPS must return to pass-through mode when the appropriate escape sequence is sent be from the management system. These escape sequence requirements are documented in Standardizing Out-of-Band Management Console Output and Terminal Emulation (VT-UTF8 and VT100+), available at http://www.microsoft.com/hwdev/platform/server/headless/default.asp.
•The UPS user interface must adhere to the same terminal conventions as described in the Standardizing Out-of-Band Management Console Output and Terminal Emulation (VT-UTF8 and VT100+), available athttp://www.microsoft.com/hwdev/platform/server/headless/default.asp, The user interface must be accessible via a terminal or terminal emulator supporting either VT100+ or a terminal VT100. If the UPS did not use the same conventions as the EMS, the user would have an extremely difficult time sending the proper commands escape sequences.
Management Port Solutions for Partitioned Systems
A partitioned system must provide a management port per partition. The management port may not be added or removed from the partition dynamically.
Security
Security on access to power management tool like a Service Processor and Windows Server 2003 is an important consideration. Because of the nature of the changing states Windows software providing the EMS during the course of boot, Windows operation and possible failure, it would be impossible to provide a seamless and cohesive security story using only the Windows software. Therefore, Windows EMS relies on physical security in the case of simple hardware such as a serial port, and the security provided by any Service Processor, ASIC, UPS, terminal concentrator or other device providing access to the EMS if a less physically secure medium such as the network is provided by said devices.
Note: Any device providing access to the EMS may provide security even if its external interface is a serial port or other physically secure interface. Once the security requirements have been satisfied by the port must behave as specified above.
