Headless Servers

Headless servers are definitely one of the coolest new features in Windows Server 2003, and they can make data center management much more efficient. Windows 2000 already offers a great solution for remote administration in Terminal Services, but Windows Server 2003 goes one step further by always including Terminal Services, in at least remote administration mode, in every install of Windows Server 2003. However, remote administration isn't the complete solution for headless servers.

We've always been advocates of remote administration because it can help improve server uptime. For more details on this philosophy and how other operating systems rely on remote administration, visit www.samspublishing.com and enter this book's ISBN number (no hyphens or parentheses) in the Search field; then click the book's cover image to access the book details page. Click the Web Resources link in the More Information section, and locate article ID# A011303 .

After Windows is up and running, Terminal Services becomes the perfect remote administration interface. But what about before Windows is up and running, or if Windows crashes? Terminal Services isn't available then, and plenty of configuration and maintenance tasks need to be performed, including BIOS configuration, POST screen analysis, and so on. Several server manufacturer utilities run outside Windows and aren't accessible remotely through Terminal Services. A special combination of software and hardware is necessary for truly headless servers.

Tip

Looking for information on headless servers in Windows Server 2003's help files? Look for remotely administered servers and Emergency Management Services; headless isn't a term Microsoft felt was appropriate for the official product documentation. You will, however, see headless in many Microsoft white papers available on the Windows Server 2003 Web site.

Headless Hardware

Microsoft's specification for headless server hardware is contained within the company's Server Appliance Kit (SAK) because the industry tends to refer to headless servers as server appliances . The name implies exactly what they are: Boxes that plug into your network and function without the usual computer trappings of a mouse, keyboard, or monitor. Microsoft's SAK even includes a utility named Saprep.exe , which allows server manufacturers to disable VGA, keyboard, and mouse devices so they can't be used even if they're attached to the computer. Windows Server 2003 includes a special null VGA driver that's installed by Saprep.exe . The null driver enables the operating system to generate video images normally and simply discards the image data instead of feeding it to a display adapter card.

Servers also have to support specific hardware features for headless operation. Specifically , the hardware needs to allow administrators to perform the following tasks without the benefit of local input or display devices:

• Power the system on or off.

• Modify the BIOS or view POST screens.

• Select an operating system to start, or set startup options (such as Safe Mode).

• Utilize preoperating system utilities.

• Analyze STOP errors (the popularly named blue screens of death).

• Reset the system.

Most of these features are implemented through special out of bandwidth management (OOB) techniques, such as connecting special remote control devices to the server's serial port. The server's hardware and firmware must be capable of directing screen output to the serial port, where the remote control device can make it available to administrators running specialized client software. Microsoft includes such serial port support in its boot code, startup menu, STOP screen displays, and a special text-mode management console, all of which are a part of Windows Emergency Management Services (EMS), which is described in the next section.

By default, Windows expects serial ports to be set to 9,600 baud, 1 stop bit, no parity, and 8 data bits and to use hardware flow control. Essentially, Windows implements a VT100+ compatible terminal output, which is the standard for remote management on most Unix systems, providing a good deal of management client compatibility between Windows and Unix. Server firmware must permit text screens to be redirected to the serial port, as well, so that BIOS screens, POST screens, and other preoperating system screens can be viewed remotely.

Note

Interestingly, Microsoft's interest in headless servers comes at a time when hardware vendors are starting to eliminate legacy hardware, such as serial ports, from their designs. Oops! To accommodate this change, Windows Server 2003 supports not only built-in serial ports, but also add-on serial ports installed in a PCI expansion slot. Headless server operation is not supported over newer connectivity options such as USB ports.

Server manufacturers are also welcome to implement specific remote-control hardware directly within the server. For example, some manufacturers are installing hardware that appears as a serial port to Windows and the server's firmware but is externally exposed as an Ethernet connection. This enables the server to be assigned an IP address for OOB management and connected to a dedicated management network. Administrators can then connect directly to the remote management system from their workstations. This technique has been used in the past in proprietary solutions such as Hewlett-Packard's (formerly Compaq) Remote InSight add-in adapters and its companion software drivers, but it is now universally supported by Windows, provided the correct hardware is installed in the computer.

Microsoft defines a number of other specifications for the OOB hardware:

• The hardware must appear to Windows as a standard serial port using standard UART interface chipsets.

• The OOB hardware must be statically mapped and not require (or allow) Plug and Play configuration ” This is because the Windows EMS software doesn't include Plug and Play functionality. This requirement eliminates last-generation hardware, which allows the BIOS to dynamically remap serial port addresses.

• The OOB hardware must be available at all times ” This is because EMS executes without the benefit of a Windows Hardware Abstraction Layer (HAL).

• Windows will access the hardware directly, not through Windows's I/O manager ” No device drivers or other software will be permitted access to the serial port at any time, even when Windows is up and running perfectly .

• The OOB hardware should be powered independently and must not be turned off at any time.

We have some other recommendations for headless servers that aren't specifically required by Microsoft. For example, you should purchase only servers that implement a PXE-compliant network adapter and include BIOS settings that enable the computer to boot from the network. This feature makes the server compatible with Windows's Remote Installation Services (RIS), enabling you to install an operating system on the server without having a mouse, keyboard, or monitor attached. Also look for Uninterruptible Power Supplies (UPSs) that communicate via serial port, instead of USB, because USB communications require Windows to be running, making the UPS unmanageable in an emergency when Windows won't start.

Headless Software

We've already touched on EMS, the bits of Windows software that make headless servers possible. EMS is used mainly for OOB management; normal, or in- band management, is performed using tools such as the MMC and Terminal Services' remote administration mode. EMS kicks in during several system states:

• While the operating system is loading, EMS redirects text output to the server's OOB management hardware.

• When the operating system is running the text-mode portion of Windows Setup, EMS redirects screen displays to the OOB hardware. EMS can also redirect the graphical portion of Setup.

• When the operating system displays a STOP error, EMS redirects that output to the OOB hardware for administrator analysis.

Note that EMS doesn't provide any redirection when Windows completely crashes; if Windows goes, so does EMS. In that case, all you can do is reset the server. Some server manufacturers include the capability to reset servers through their OOB connections, particularly manufacturers who implement those connections as network interfaces. Specialized management software enables you to send a remote restart signal to the OOB hardware, which can then physically reset the computer, allowing it to restart Windows. Again, this is similar to the functionality provided by proprietary remote administration solutions such as HP's Remote InSight boards .

EMS isn't a single piece of software; rather, it's a service built into many Windows components :

• Ntloader and its equivalent for 64-bit systems

• Setup loader

• Text-mode Setup

• Recovery Console

• RIS loader

• STOP displays

• For more information on 64-bit systems and how Windows operates on them, see Chapter 15, "64-bit Windows," p. 253 .

Note

EMS is designed to redirect output to both the OOB hardware and any video card installed in the server. This behavior enables you to attach a monitor, assuming your server contains a video adapter, for management purposes, if desired.

EMS also includes two new components designed specifically for emergency management: The Special Administration Console (SAC) and !Special Administration Console (!SAC). SAC is the primary command-line environment for EMS and is available very early in the Windows Server 2003 boot process. You can use SAC to manage the server when Windows is running normally, during startup, during safe mode, and during the graphical portion of Windows Setup. SAC is always available after the Windows Server 2003 kernel is loaded and running. SAC is not a full-fledged Windows command line; it provides limited functionality, which includes

• Restarting or shutting down the server.

• Viewing running processes and end processes.

• Viewing and modifying the server's IP address.

• Generating STOP errors to force the creation of a memory dump file.

• Accessing a regular Windows command-line prompt. Simply enter the cmd command and use the Esc+Tab key combination to switch between the command-line window and the SAC window. SAC-launched command lines can run any text-based tools but cannot launch graphical tools such as Notepad. Additionally, you must provide domain or local user credentials before SAC will launch the command line, and any commands you launch will be under that user context.

• While viewing the graphical portion of Windows Setup, SAC enables you to press the Esc+Tab key combination to switch between the SAC window and the Setup log files, which enables you to troubleshoot Setup problems more easily.

The oddly named !SAC also accepts commands through the server's OOB hardware and is completely separate from SAC and the Windows command line. !SAC is available only after EMS determines that the server has failed or if SAC fails to load or function properly. !SAC enables you to redirect STOP message text and restart the computer if SAC is unavailable. Essentially, !SAC is a last-ditch attempt by Windows to provide remote access to your server so you can get it running again.

Remember that EMS isn't the be-all and end-all of remote management. Your server's firmware must provide OOB redirection for you to

• Remotely view POST screens

• Remotely edit the server BIOS

• Start a RIS-based setup (which also requires a PXE-compatible network adapter)

• Remotely respond to the Press any Key to Boot from CD prompt that Windows Setup CDs display when the system starts and the CD is inserted

SAC isn't available until Windows's kernel is loaded, and EMS itself doesn't start working until Ntloader executes. On 64-bit systems, the server's firmware must also redirect the boot menu because that menu is constructed by the server's firmware, and not by the Windows startup software.