If you're running Windows NT 4.0 on your Exchange server, you can either uninstall the OS and all other software and install NT Server 4.0, Terminal Server Edition, an expensive and labor-intensive process, or install some remote desktop-sharing software, such as Symantec's pcAnywhere, Altiris's Carbon Copy, or AT&T Laboratories Cambridge's Virtual Network Computing (VNC). I like VNC because it's free—go to http://www.uk.research.att.com/vnc. (As a bonus, the VNC viewer software is small enough to fit on a 3.5" disk, so I can carry it with me and run it on whatever machine I need to.) Admittedly, VNC is not as sophisticated or as fast as its commercial counterparts, and no formal organization supports it. As a result, you might find that another tool better suits your needs. All these remote desktop-sharing tools run on Win2K as well. No matter what host OS you're using, be sure to follow the software's security recommendations closely—you certainly don't want to provide random Internet users with access to your Exchange server's console.
Determining Whether the Machine Is Running
When you're away from your server and you realize that something is wrong, your first step is to find out whether the server is running. If you're lucky and it is up, you can ascertain specific problems (e.g., inbound mail is failing, Microsoft Outlook Web Access—OWA—doesn't work). In my case, I could ping the server's IP address, so I knew that the server was running and on the network, but I could also tell that POP3, IMAP4, and OWA were all dead. The server was answering POP3 and IMAP4 connections but rejecting logons for those protocols. Messaging API (MAPI) connections were failing, and attempts to load the OWA page for any user brought up the regular authentication dialog box, followed by a 503 error page.
Depending on your firewall configuration, you might not be able to ping a machine inside the demilitarized zone (DMZ) or firewall. Find out now whether you can ping a machine from the outside so you'll know what to expect when you need to remotely troubleshoot a server for real. Any test that will tell you whether the server is on the network will do: You can telnet to a well-known port or you can connect to a system that you know is up and use Windows tools such as Server Manager or the MMC Computer Management snap-in to try to connect to the misbehaving machine.
If your machine isn't running—say, because it's experienced a blue screen or because the power is out—you're probably out of luck. The one exception is if your server has one of those spiffy remote-management cards. Hewlett-Packard (HP), Compaq, Dell, and most other first-tier server vendors offer these cards, which let you dial or telnet into a text-based monitor that can identify the state of the machine's hardware. Some of these remote-management cards even show you a snapshot of what's currently on screen, a great feature for remotely debugging suspected or actual STOP errors. Most of these cards let you restart a dead machine because you connect to the card and not to the host system. This ability to revive a downed system is invaluable when you're not physically near the failed server.
Identifying What's Wrong
When you can ascertain that the computer is up and open for business, the next step is to use your remote console application. I fired up the Terminal Services client, which I had previously installed on a convenient computer at my remote location. If you can't install or use the dedicated Terminal Services client—perhaps you're at a customer site—Microsoft has an ActiveX control that you can install on your server. You can use this control to establish a Terminal Services session from any Windows machine that has Microsoft Internet Explorer (IE) installed. To download the ActiveX control, go to http://www.microsoft.com/windows2000/downloads/recommended/tsac/default.asp.
After you establish a remote console session, you can use the regular array of troubleshooting tools that you'd use if you were physically sitting in front of the machine. I typically start the troubleshooting process by using the Event Viewer to check for warning or informational events that can offer a clue as to what's wrong. Exchange logs most of its interesting events, including various types of errors and failures, in the Application event log. Applying a filter with the View, Filter command lets you see only warning or error events. Filtering out routine events can help speed the process of pinpointing a failure. After a bit of practice, you'll be able to look at an event ID and identify the problem. Get into the habit of searching Microsoft's Knowledge Base as soon as you encounter an unfamiliar event ID. Many common events are largely unmentioned in the Exchange documentation but are described in the Knowledge Base.
You can perform two other tricks from the command line, either through a remote console session or through Telnet, to help correct a problem:
- The Net Start and Net Stop commands let you start and stop individual services. Because Win2K and NT both understand service dependencies, you can simply stop the System Attendant (MSExchangeSA) service to kill all Exchange services. To run Net Stop in unattended mode, type
net stop msexchangesa /y
and watch your services shut down cleanly.
- The Microsoft Windows 2000 Server Resource Kit's Nltest command (described in Darren Mar-Elia, "10 Resource Kit Remote Administration Tools," April 2001, InstantDoc ID 20046) has a handy shutdown feature that lets you attempt to shut down a balky server from the command line on another machine. Sometimes a server that won't shut down from the console will honor an Nltest shutdown request. You need two switches to force a shutdown with Nltest:
nltest /server:<server name>
/shutdown:<"server hung">
Prev. page
1
[2]
3
next page 
