Building Hardware and Firmware

to Complement Microsoft Windows

Headless Operation
Version 1.0a - May 27, 2004

Abstract
The Microsoft® Windows® Server 2003 family of operating systems provides native
support for “headless” server operation on Windows platforms—that is, support for
operating without a local display. This paper describes the hardware and firmware
requirements and implementations guidelines to best support Windows headless
functionality.
The current version of this information is provided at This information applies for the
following operating system:
Microsoft Windows Server™ 2003
The current version of this paper is maintained on the Web at:
http://www.microsoft.com/whdc/system/platform/server/default.mspx
Content
Introduction.............................................................................................................................. 3
Headless Implementation in the Windows Server 2003 Family..............................................3
Designing Hardware and Firmware for Windows Server 2003 Headless Systems.................4
Providing Legacy Out-of-Band Management Port Hardware for Use with EMS......................4
Providing Non-Legacy Out-of-Band Management Port Hardware for Use with EMS..............5
Out-of-Band Management Port Device Requirements........................................................5
Out-of-Band Management Port Implementation.................................................................6
Implementing Firmware for Headless Systems.......................................................................8
Firmware Localization Requirements..................................................................................9
RIS and PXE Requirements................................................................................................9
Designing Service Processor/ASIC or UPS.............................................................................9
Service Processor/ASIC General Functionality Requirements.........................................10
Service Processor/ASIC Internal Hardware Interface Requirements................................10
Service Processor/ASIC External and User Interface Requirements...........................10
Single Channel External Interfaces..............................................................................10
Multiple Channel External Interfaces............................................................................12
UPS Requirements...........................................................................................................13
Management Port Solutions for Partitioned Systems........................................................14
Security............................................................................................................................. 14
 Building Hardware and Firmware to Complement Microsoft Windows Headless Operation - 2

Disclaimer
The information contained in this document represents the current view of Microsoft Corporation on the
issues discussed as of the date of publication. Because Microsoft must respond to changing market
conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot
guarantee the accuracy of any information presented after the date of publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES,
EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights
under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval
system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or
otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property
rights covering subject matter in this document. Except as expressly provided in any written license
agreement from Microsoft, the furnishing of this document does not give you any license to these
patents, trademarks, copyrights, or other intellectual property.

Unless otherwise noted, the example companies, organizations, products, domain names, e-mail
addresses, logos, people, places and events depicted herein are fictitious, and no association with any
real company, organization, product, domain name, email address, logo, person, place or event is
intended or should be inferred.

© 2004 Microsoft Corporation. All rights reserved.

Microsoft, Windows, and Windows NT are either registered trademarks or trademarks of Microsoft
Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their
respective owners.

Version 1.0a - May 27, 2004

 Building Hardware and Firmware to Complement Microsoft Windows Headless Operation - 3

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:

Version 1.0a - May 27, 2004

 Building Hardware and Firmware to Complement Microsoft Windows Headless Operation - 4

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

Version 1.0a - May 27, 2004

 Building Hardware and Firmware to Complement Microsoft Windows Headless Operation - 5

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.

Version 1.0a - May 27, 2004

 Building Hardware and Firmware to Complement Microsoft Windows Headless Operation - 6

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.

Version 1.0a - May 27, 2004

 Building Hardware and Firmware to Complement Microsoft Windows Headless Operation - 7

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.

Version 1.0a - May 27, 2004

 Building Hardware and Firmware to Complement Microsoft Windows Headless Operation - 8

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

Version 1.0a - May 27, 2004

 Building Hardware and Firmware to Complement Microsoft Windows Headless Operation - 9

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.

Version 1.0a - May 27, 2004

 Building Hardware and Firmware to Complement Microsoft Windows Headless Operation - 10

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

Version 1.0a - May 27, 2004

 Building Hardware and Firmware to Complement Microsoft Windows Headless Operation - 11

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.

Version 1.0a - May 27, 2004

 Building Hardware and Firmware to Complement Microsoft Windows Headless Operation - 12

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

Version 1.0a - May 27, 2004

 Building Hardware and Firmware to Complement Microsoft Windows Headless Operation - 13

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

Version 1.0a - May 27, 2004

 Building Hardware and Firmware to Complement Microsoft Windows Headless Operation - 14

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

Version 1.0a - May 27, 2004