Fixing a corrupt Message Transfer Agent in your Microsoft Exchange Server

In this article, I’ll look at fixing a corrupt Message Transfer Agent (MTA). A variety of events can cause your MTA to become corrupt. When the ILOVEYOU virus was introduced, many people tried to manually delete it from the MTA queues, which caused serious problems. Sometimes there is an easy fix to this situation, but other times you have to do a little file manipulation.

Quick fix

The MTA’s function is to provide addressing and routing information for sending messages from one server to another. If you are attempting to bring up your Exchange Server services and the MTA will not start, try running the Mtacheck.exe utility from a command prompt. Doing so will usually fix inconsistencies in the MTA database. If you get a message similar to the following when running the Mtacheck.exe, you should read on:

D:>Mtacheck /v
Error in Queue-Desc-Object (ID 1) initialization
Database contains serious errors and cannot be automatically repaired.

Other fixes

The cause of database problems can be that some of the MTA database files have been manually deleted or corrupted. It is not likely that the MTA deleted any of its core database files on its own. The core database files are as follows:

Db000001.dat through Db000009.dat
Db00000a.dat through Db00000f.dat
Db000010.dat through Db000019.dat
Db00001a.dat through Db00001f.dat
Db000020.dat through Db000026.dat

Verify that all of these files are in the exchsrvrMtadata folder. If any of these files are deleted, the MTA will continue to run, because they are in cache. You will only notice problems when you stop the MTA service and attempt to restart it. Now, follow these steps:

1. Make a backup of the Mtadata folder. If you have more than one Mtadata folder, it’s important to back up the correct one. You can verify the MTA database path by running Regedt32.exe and then navigating to the HKEY_LOCAL_MACHINESystem CurrentControlSetServicesMSExchangeMTAParameters key. View the MTA Database Path registry value and note the path. Many people do not back up the Mtadata directory because it is not really highlighted in the Microsoft Disaster Recovery for Exchange. Most of the emphasis is placed on the Priv.edb, Pub.edb, and Dir.edb files. Even if you use a backup program such as ArcServe with the Exchange Agent, the Mtadata folder doesn’t appear in the Exchange Server tree.

2. If any of the core files are missing from the Mtadata folder, copy Db000002.dat through Db000026.dat from the ServerSetupPlatformBootenv folder on the Exchange Server 5.5 CD to the Mtadata folder.

3. Do not copy Db000001.dat if it is missing; instead, restore it from tape backup. If no tape backup exists, then the Db000001.dat cannot be recovered and the messages currently present inside the MTA database will be lost.

4. Once you have copied the files from the CD to the Mtadata folder, remove the read-only attributes.

5. Run the Mtacheck utility twice, and you should get a message that states Database clean, no errors detected. Try starting the MTA service, which should come back up online and begin processing messages.

If you still get an error while starting the MTA, it may be because the work queue is corrupt or destroyed. To correct this problem, try the following:

1. Rename the Mtacheck.exe utility located in the exchsrvrbin folder to Mtacheck.sav.

2. Copy the Mtacheck.exe utility located on the Exchange Server 5.5 CD (version 1960.3) or the Exchange Server Service Pack 1 CD (version 2232.18) to the exchsrvrbin folder. You do this because the newer version of Mtacheck.exe that comes with Microsoft Exchange Server 5.5 Service Pack 2 (SP2) or Service Pack 3 (SP3) does not recreate the Db000027.dat file (the work queue) when it has been corrupted or deleted. If the Exchange Server computer has been upgraded from a previous version (such as Exchange Server 5.0), the work queue may have a different file name, such as Db00002b.dat. You should associate the work queue file name with the one mentioned in the Mtacheck output file. The output file should contain a line that states Checking queue MTAWORKQ (id 01000027).

3. Run the Mtacheck utility twice and then try starting the MTA service. It should recreate the work queue and come back up online and begin processing messages.

4. Be sure to replace the old Mtacheck.exe file with the newer Mtacheck.sav file.

Remember to always move or rename files instead of deleting them. Also, include the Mtadata folder in your backup routine–doing so can save you the trouble of having to try to recover your MTA. //

Troy Thompson, MCSE+Internet, is a freelance consultant in the Louisville, Ky., area.

Latest Articles

Follow Us On Social Media

Explore More