test2
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.
