Inside Windows Server 1002003 [Electronic resources] نسخه متنی

Using Emergency Management Services (EMS)

It is often handy to access a server outside of the normal network connection. For example, the network interface at the server might not be functioning. Or, something has broken the connection between you and the server. Or, the server refuses to respond and you want to check out the problem.

Windows Server 2003 provides a way to access a server via a serial line connection. This feature is called

Emergency Management Services , or EMS. The name is a little misleading because there really isn't a service called Emergency Management. Instead, EMS represents a base functionality that can be enabled using a switch in Boot.ini. This switch redirects output to a serial port and listens for responses.

The simplest way to configure EMS port redirection is to use the BOOTCFG utility. Run the utility at a command prompt at the server where you want run EMS. Here is the syntax to redirect the first ARC path in a Boot.ini file to COM1 at 115200bps:

bootcfg /ems on /port com1 /baud 115200 /id 1

Here is the listing of the Boot.ini file that shows the changes in bold:

[View full width]
[boot loader]
timeout=0
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
redirect=COM1 
redirectbaudrate=115200 
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /
fastdetect 
/redirect 

When you boot the server with this configuration, EMS is enabled and you can pick up the output from the serial port. To make a serial-line connection to the server, you'll need a null-modem cable. Look for a serial cable with female DB-9 connections at each end. Don't use a LapLink data transfer cable. It won't work for this application.

Also, you'll need a terminal emulator running at a client on the other end of that serial line. A convenient terminal emulator comes in all 32-bit versions of Windows. It is Hyperterm, loaded from A

CCESSORIES | C

OMMUNICATIONS . Configure Hyperterm to use a COM port rather than a modem and configure the properties for the COM port at 8n1 with a 115200bps connection speed and hardware flow control (see Figure 21.19).

If you want to configure out-of-band connections to many servers in a server room, take a look at serial-port concentrators from vendors such as Muxmaster and Cyclades. These concentrators give you both a network and a dial-up connection to the serial ports and they incorporate logon security, a feature missing from standard EMS. You should never connect a modem directly to the serial port of a production server. Some 14-year-old kid will find it using a demon-dialer and you'll end up with all sorts of strange things happening to your system.

Special Administration Console (SAC)

When you make a serial-line connection to a server running EMS, you are presented with a text screen called the Special Administration Console, or SAC. This console has a short list of functions shown in Figure 21.20.

For the most part, the SAC functions are self-explanatory. For example, the t function mimics the Tlist utility in the Resource Kit by giving a list of the running executables and their Process IDs, or PIDs. You can use this information to find the PID for a hung process and then use the k function to kill the process. The restart function is handy for bouncing a hung server.

If, for some reason, SAC is unavailable, the system falls back on an emergency SAC called !SAC. This console has only four options:

• Restart .
  Performs an immediate restart.




• D .
  Displays Event log entries.




• ID .
  Displays server identification information.




• Q .
  Returns the serial port to normal operation.

EMS and Bugcheck

If a system crashes as the result of a kernel-mode stop error, EMS redirects the bugcheck screen to the serial port. Figure 21.21 shows an example.

Unless you have the server configured to not restart following the memory dump, this bugcheck window will disappear in a few minutes to be replaced with the SAC as soon as the server restarts.

If you configure your terminal emulator to capture all input, you'll be able to scroll up and see the bugcheck window. This gives you an idea where to look for problems following the restart