IT pros with experience with Exchange 5.5 or 2000 are probably aware of the Message Transfer Agent (MTA), which is an integral part of the Exchange Architecture. In versions predating today’s Exchange 2000 (and even 2003), the MTA was part of what Exchange administrators knew as the “core 4.” This included the Information Store, the “Directory,” the System Attendant, and the MTA.

According to Microsoft’s definition, “…the MTA submits, routes, and delivers messages to other MTAs, information stores, connectors, and third-party gateways. Connector and gateway messages, except messages routed by the Microsoft Mail Connector, are processed by the MTA for security, routing, and other purposes. Queues for each connector and gateway are displayed along with other MTA queues.”

In today’s implementation of Exchange, the MTA has taken a smaller role, becoming less critical and being replaced by the SMTP portion of Exchange 2000 and 2003. Nevertheless, the MTA is still important in today’s Exchange environments, particularly in the area of X.400 routing. We’re going to take a look at how you can troubleshoot MTA and recover from problems by using the MTACheck utility.

How to use MTACheck
MTACheck.exe is designed to provide what is known as a “soft recovery” of an MTA database that may be corrupted. MTACheck is not a utility that you should have to use every day. In fact, the times you will need to use it indicate there is some sort of problem. Here are a few scenarios in which you might use MTACheck:

  • MTA service will not start due to corruption or suspected corruption of the MTA database.
  • The MTA has entered an “uncontrollable state”—meaning that it possibly cannot be stopped through the Services tool in the Control Panel. This may be caused by a corrupted message entering the MTA database for processing or by some corruption within the MTA database itself. You should always give your service enough time to stop before classifying it as “uncontrollable”—five to seven minutes is usually acceptable. If you cannot stop it, you can go into Task Manager and kill its process (which is named EMSMTA.exe).
  • Messages are not being de-queued.
  • An extremely large message enters the server from the Internet and causes the queue to hang. The MTA does not process any messages while it is in this state, and consequently the queues just fill up.

The MTACheck program has logs that are simply text files to show the results of running the tool. MTACheck examines the internal database of the MTA to look for objects that are damaged and might be interfering with the functionality of the MTA. It places defective objects from the queues into files for you to examine later. In addition, MTACheck rebuilds the queues so the MTA can be restarted and return to processing.

Exchange 2000 tip

If you are using Exchange 2000, the Exchange 2000 Resource Kit contains a utility called MTAView that allows you to look at the message headers in the queue. This can be a helpful troubleshooting tool.

Before running the utility, make sure that you stop the Exchange MTA service. (Remember, if you cannot stop the service manually, you need to kill it via Task Manager.)

To run MTACheck, you must first locate it. Microsoft was kind enough to install it for you automatically—by placing it in the %EXCHANGE_ROOT %\BIN directory on your Exchange server.

Author’s note

Microsoft recommends backing up the following files before running MTACheck.exe:
\metadata\db*.dat
If something were to go awry while running MTACheck.exe, you may need to restore the MTA queue and copy these files back to the server.

From the command prompt, navigate to \exchsrvr\bin and type MTACHECK.EXE followed by the appropriate switches:

  • /v: Log verbose details.
  • /f: Log to a file. (The filename follows this switch after a space.)
  • /rd: Remove directory-replication messages.
  • /rp: Remove public-folder replication messages.
  • /rl: Remove link-monitor messages.

Example 1: Simple command
Our first example shows the components of a basic version of the command:
MTACHECK.EXE /v /f <yourfilename.log>

In Example 1, we’re simply interrogating the MTA database to verify just what is going on with it. Any issues detected will be reported in your log file. The above command sequence does a number of things. First it places the utility in verbose mode (/v). Second it provides a filename (/f). (The file will be stored in \exchsrvr\bin unless you specify another location.)

Example 2: Complex command
Now, let’s look at a more complex version:
MTACHECK.EXE /v /f <yourfilename.log> /rd /rp /rl

The important piece of Example 2 is the addition of the /rd, /rp, and /rl switches. The /rd switch removes all directory-replication messages, which will help clean the queue of some superfluous messages and allow MTACheck to get down to business. The /rp switch removes your public-folder replication messages. Finally, the /rl switch removes any link-monitor messages that may be clogging the queue.

Other MTACheck issues
Depending on your Exchange server’s hardware and any other applications that may be running on your server, MTACheck takes around a minute for every 1,000 messages it processes. If you have a large number of replication or link-monitor messages backed up in the queue, you can speed up MTACheck by removing replication and link-monitor messages with the /rd, /rp, or /rl switches. Remember, if you have an extremely large number of messages in your queue, MTACheck could take HOURS to complete.

Once MTACheck completes, you’ll receive a message similar to one of these:

  • Database clean, no errors detected.
  • Database repaired, some data may have been lost.
  • <number> queue(s) required repair out of <percent> detected.
  • <number> object(s) damaged out of <percent> detected.
  • Database has serious errors and cannot be reconstructed.

If the database is clean, it’s safe to restart the MTA service. If MTACheck indicates the database was repaired, make sure you delete any files in the \MTADATA\MTACHECK.OUT directory and then rerun MTACheck. Keep on running MTACheck until you get the database clean message, and then restart the MTA service.

Author’s note

I have seen the first attempt to restart the MTA after running this utility take a few minutes. Don’t panic—give it a few minutes before you do anything drastic.

After all that, if your MTA is still having problems, then it’s time to implement your disaster recovery strategy. It’s possible that there may be nothing you can do other than restoring from a backup. Ensure you exhaust all possible options before doing this. See this link for information on advanced MTA troubleshooting:

The system does its own MTACheck
Now you’ve learned how to run MTACheck manually, but did you know that it already runs for you automatically in some situations? In fact, when the MTA service determines that the MTA was not shut down “gracefully”—for example, if it were shut down by a power outage or hard reboot—the utility will run all by itself. If an automatic MTACheck happens to be run, events will be logged to the Event Viewers Application Log as well as the MTACHECK.LOG file.

Remember, if you think you’re having problems with your MTA, you can always enable Diagnostic Logging to help diagnose the problem. Consult the documentation specific to your Exchange version for more details.

Summary
As an Exchange Administrator, you’re charged with a very important task: Keeping the company’s e-mail services up and running on a 24×7 basis. Downtime is unacceptable in today’s environment, and tools like MTACheck are excellent to have in reserve for that instance when a minor hiccup could turn into a major headache.