Sometimes e-mail mysteriously stops flowing in and out of an Exchange Server. This type of mail flow stoppage tends to be very disruptive for both senders and recipients because important messages are either lost in transit or delayed. When mail suddenly stops, it’s important to get it flowing again as quickly as possible. This isn’t always as easy as it sounds because there are lots of different variables that can cause mail flow to cease on an Exchange system. Let's look at the process of diagnosing and correcting a mail stoppage.
Check the basics
Before you start analyzing log files or trying to repair databases, it’s a good idea to check the basics. For starters, you'll want to verify that all of the necessary Exchange services are running. You can do this by opening the Control Panel, double-clicking on the Administrative Tools icon, and double-clicking on the Services icon. This will open the Windows 2000 Service Control Manager.
All of the various services are listed in alphabetical order. Scroll through the list of services until you find the Microsoft Exchange section. Any Exchange-related service with a startup type of Automatic should have a status of Started. Pay close attention to the Microsoft Exchange MTA Stacks service, since it's ultimately responsible for mail flow. If a service has stopped, simply right-click on it and select the Start command from the resulting shortcut menu to restart it. If you run into errors, you may need to reboot the system.
Once you've verified that all of the Exchange services are running, you need to verify connectivity between the Exchange server and the rest of the world. The easiest way to do this is through a series of ping tests. Start by opening a command prompt window and using the ping command to ping your organization’s DNS server by IP address. If the ping fails, you have a bad network card, a loose cable, a downed DNS server, or some other connectivity issue.
If you're able to ping your DNS server by IP address, you'll want to make sure the DNS server is able to resolve host names. Try pinging another machine in your organization, but use the machine’s host name in the ping rather than its IP address. If the ping is successful, that means the DNS services are working correctly. If the ping fails, you might check the spelling of the host name and your Exchange server’s TCP/IP configuration, and verify that the machine you tried to ping is online and configured properly.
If you can ping within your organization successfully, try pinging your Internet gateway by IP address to make sure the gateway is recognized. If that works, try opening a Web browser and visiting a couple of Web sites. If this works, communications look good.
If you haven’t yet located the cause of the problem, I suggest rebooting the server before you do anything else. Although Exchange 2000 seldom has reboot issues, I've seen a few situations in which a reboot made mail begin to flow again. After the machine reboots, give Windows a few minutes to start all of the necessary services. Once you've verified that all the services are running again, see what else is running on the server. I've seen situations in which a malfunction in a third-party Exchange application caused a mail flow problem. For example, I once saw an antispam application malfunction and block all inbound and outbound messages. Try temporarily disabling any antispam applications, Exchange antivirus software, or any other Exchange applications that might be running. You should be able to quickly determine whether one of those applications is causing your mail flow problem.
One final basic check you'll want to perform is to determine who is affected by the mail flow problems. For example, do some quick tests to see if users can send messages to other users, to themselves, and to the outside world. If internal mail flow is working but external mail flow isn't, it could be that a setting within your corporate firewall is blocking one of the necessary ports.
A port issue
The easiest way to determine if a blocked port could be to blame for your problem is to check your firewall logs to see if any changes have been recently made to the firewall’s security policy. You can also use a port scanner to determine if the appropriate ports are open. There are several good online port scans, including one at GRC.com.
Unfortunately, I can’t tell you exactly which ports should be open because those ports will depend on your Exchange configuration. The ports will vary depending on which services and protocols you use, whether you use a front-end/back-end configuration, and whether you're using things such as SSL, dynamic DNS, or port forwarding. However, if you aren’t quite sure which ports should be open, I recommend checking out Microsoft’s Knowledge Base Article 278339, which lists the various ports used by Exchange 2000.
Check the MTA queues
Once you've covered the basics, the next step is to examine the Exchange MTA queues. To access the queues, open the Exchange System Manager and navigate to your organization \Administrative Groups \ your administrative group \ Servers \ your server \ Protocols \ SMTP \ Default SMTP Virtual Server \ Queues.
When you select the Queues container, you'll see a list of the currently existing queues and the number of messages within each queue. If this is the first time you've ever looked at the queues, you might be in for a shock. You'll probably have several queues related to spam, as shown in Figure A. This does not mean that your server has had a security breach.
When a message is destined for a remote domain, Exchange 2000 creates a temporary queue for it. Other messages destined for the same domain are also placed into this temporary queue. This allows Exchange to send multiple messages destined for a common domain in batches rather than having to establish a separate session for every single message.
Normally, these temporary queues are deleted as fast as they are created. However, if Exchange is unable to find a route to the destination domain, the queue is preserved and Exchange attempts to resend the messages later. If the messages have not been sent within a specific amount of time, the queue and the messages within it are removed. In Figure A, none of my temporary queues are more than two days old. Also, each queue has either a green check mark icon or a Retry icon to indicate the queue’s status.
The queues shown in Figure A are all pretty healthy. My antispam software is blocking delivery to the temporary queues shown. What would indicate a real problem, though, would be if a queue pointing to a legitimate domain had a steadily increasing message count. This would indicate that messages were going into the queue, but were never being processed.
In such a case, you'd probably want to examine the contents of the queue. To do so, expand the Queues container to reveal the individual queues. Select a queue containing messages, and the pane on the right will display a message saying Enumerate Messages From Queue Node. This is actually a safety feature. The problem is that Exchange can take a long time to display all of the messages within a queue. To prevent the System Manager from bogging down your server, individual messages are hidden unless you specifically request to see them.
To view the individual messages, right-click on the desired queue and select the Enumerate 100 Messages command from the resulting shortcut menu. When you do, Exchange will display the first 100 messages in the selected queue. Once the individual messages have been displayed, right-click the first message in the queue and either freeze or delete it (with or without the nondelivery report). Often, a corrupted message at the beginning of a queue will cause the entire queue to back up. Removing the corrupt message will usually get the queue flowing again. If you want to work with the entire queue rather than individual messages, you can right-click on the queue itself and either freeze or delete every message in the entire queue.
Queue flooding is a common problem. When this occurs, the queue has so much inbound mail that it simply can’t keep up, and messages start accumulating in the queue at a rapid rate. This condition may be caused by a Denial of Service (DoS) attack, an e-mail virus, or by someone using your server as a relay point. DoS attacks and viruses are beyond the scope of this article, but I do recommend checking to make sure that your server isn’t being used as a relay point by spammers.
To disable relaying, open the Exchange System Manager and navigate to Administrative Groups | your administrative group | Servers | your server | Protocols | SMTP | Default SMTP Virtual Server. Next, right-click on the default SMTP virtual server and select the Properties command from the resulting context menu. On the Default SMTP Virtual Server Properties sheet, select the Access tab and click the Relay button. You’ll now see the Relay Restrictions dialog box, which gives you a choice of blocking relay traffic from everyone except the domains or IP addresses listed on the exceptions list, or only for the domains listed on the exceptions list. Whichever option you choose, click the Add button to display the Computer dialog box. This dialog box allows you to enter an IP address or DNS name for a single computer, or an entire subnet address or domain name, which would apply to an entire group of computers.
The Relay Restrictions dialog box contains a check box that reads, Allow All Computers Which Successfully Authenticate To Relay, Regardless Of The List Above. By selecting this option, you can control relaying on a user basis rather than on a computer or domain basis. Just keep in mind that if you decide to control relaying on a user basis, all users with a valid username and password will be allowed to relay messages. You won’t be able to prevent specific authenticated users from relaying messages.
MTA Check utility
Like almost everything else in Microsoft Exchange, the MTA Check utility relies on databases. These databases are stored in the \EXCHSRVR\METADATA folder. While the information stores use .edb databases, the MTA uses .dat databases. Each .dat file is numbered sequentially and stores a single message. When the message is sent, the database file is truncated and reused for another message. If a database file becomes corrupt, the MTA may be unable to send messages.
This is where the MTA Check tool comes in. MTA Check is a command line tool that analyzes MTA databases and repairs any consistency problems that might be encountered. You can get MTA Check by downloading it from Microsoft.
As you can see, troubleshooting Exchange mail flow issues can be tough because there are a number of variables involved. I've provided you with a step-by-step approach for diagnosing and repairing mail flow problems in Exchange.