The /server switch tells Nltest which server you want to target, and the /shutdown switch lets you specify a reason (e.g., "server hung") that will appear in the event log.
My Exchange server hadn't logged any interesting event messages, so I couldn't immediately tell what was wrong. The fact that POP and IMAP users couldn't log on was a clue to the problem. The services were up, but because Exchange 2000 uses DLLs that IIS loads to handle POP3 and IMAP4 traffic, I couldn't vouch for the health of the Store. I began to suspect that my server was having trouble reaching a Global Catalog (GC) server because logon requests for POP and IMAP were immediately failing. (I have only one domain, so the GC server and domain controller—DC—are the same machine, even though I have two GC/DC computers.) A quick flourish of the Dsadiag tool from the Win2K support tools helped me identify part of the problem: My Exchange server wanted to talk to the GC named thunderstorm, which I had shut down while waiting for a new Fibre Channel adapter. The quickest way to fix the problem would typically be to stop and restart the Store, forcing it to find another GC. You wouldn't want to take this approach during the middle of a business day, but I figured I could get away with it during a noncritical time. However, when I tried to stop and restart the Store, it hung—always a sign that something is amiss.
Cutting to the Chase
Because I couldn't just shut down the Store, I had to shut down the entire machine. I pressed Ctrl+Alt+End to trigger the Windows Security dialog box from within the Terminal Services client and selected Restart, but nothing happened. So I used the Terminal Services client to attach to another server, opened a command window, and typed
nltest /server:cyclone
/shutdown:wedged
The command shut down the server cleanly, and when the server came back up, all was well. OWA, IMAP, POP, and MAPI users could all get their mail, and Exchange was bound to the correct GC.
Learning Valuable Lessons
Would I follow the same procedures again? Possibly. In this case, the server's availability requirements were fairly low and I had created a known good backup the day I left for my vacation. I judged the risk of data loss to be minimal, and the odds of a successful restoration as high. Of course, you might want to follow a more deliberate course of troubleshooting if you have someone at the server who can help you, particularly if the trouble you're having requires you to stop the Store, run Eseutil, or run Isinteg. You can benefit from my experience by doing the following:
- Set up some kind of remote console access tool on any server that you might need to fix remotely; install the corresponding client (or make it available for download) on the machines you'll need to use while you're out of the office. Make sure you do so securely, and be sure to test your setup while you're still in the office.
- Make sure that you install the Win2K and Exchange 2000 support tools, which are located in the support folder on the product CD-ROM, on any machine that you might need to fix remotely. Installing the Win2K Server and Exchange 2000 resource kits is probably a good idea as well.
- Consider using a tool to alert you when something unusual happens. Exchange 2000 and Exchange Server 5.5 both include server-monitoring tools that can email you when something's amiss; you should probably consider combining these built-in features with a third-party tool that can send you pager messages (when your email server is down, it can't send you email).
- If others will be near the server while you're on the road, teach them as much about Exchange as you can. In the best case, they can fix problems without your intervention; at worst, you'll have someone who can change tapes or otherwise provide a spare pair of hands when you're not there.
End of Article
Prev. page
1
2
[3]
next page -->
