General troubleshooting for transport issues in Exchange 2000 Server and in Exchange Server 2003 (257265)



The information in this article applies to:

  • Microsoft Exchange Server 2003 Enterprise Edition
  • Microsoft Exchange Server 2003 Standard Edition
  • Microsoft Exchange 2000 Server

This article was previously published under Q257265
This article is a consolidation of the following previously available articles: 257265, 281800, 274638, 325321, 289553, 296494, 314734, 323669, 821910

SUMMARY

This article provides information about basic troubleshooting utilities that you can use with transport components in Microsoft Exchange 2000 Server and in Microsoft Exchange Server 2003 to investigate transport issues. The most common issues involve mail flow. You should use these utilities to investigate the issue before you open a support incident.

MORE INFORMATION

Diagnostic Logging

You can use Diagnostic Logging to determine the root of a transport issue. To enable Diagnostic Logging on the MSExchangeTransport service, follow these steps:
  1. Start Exchange System Manager.
  2. Navigate to the server object.
  3. Right-click Server object, and then click Properties.
  4. Click the Diagnostic Logging tab.
  5. Under Categories, click MSExchangeTransport.
  6. Under Logging Level, click the appropriate logging level for the issue you are investigating (minimum, medium, or maximum).

Queue Viewer

You can use the Queue Viewer tool to maintain and administer your organization's messaging queues. It can help you identify and isolate mail flow issues. Queue Viewer is available on all Simple Mail Transfer Protocol (SMTP) virtual servers, Microsoft Message Transfer Agent (X.400), and all installed Microsoft Exchange connectors.

Exchange 2000

To access the queues, follow these steps:
  1. Start Exchange System Manager.
  2. Use the following path to locate the queue you want to administer:

    Administrative Groups\Admin Group Name\Servers\ServerName\Protocols\SMTP\SMTP virtual server\Queues\Queue

To locate X.400 queues, use the following path:

Administrative Groups\Admin Group Name\Servers\ServerName\Protocols\X.400\Queues\Queue

To locate MAPI system queues that are associated with connectors such as Microsoft Exchange Connector for GroupWise, Microsoft Exchange Connector for Lotus Notes, and Microsoft Exchange Connector for Lotus cc:Mail, use the following path:

Connectors\Connector Name\Queues\ Queue

If you can view the routing groups or the Administrator groups in Exchange System Manager, you must browse through these objects to reach Queue Viewer.

Exchange 2003

To access the SMTP queues in Exchange 2003, follow these steps:
  1. Start Exchange System Manager.
  2. Open the folder in the following location to find the queue that you want to administer:

    Administrative Groups\Admin Group Name\Servers\ ServerName\Queues

Protocol Logging

You can use Protocol Logging to track commands that an SMTP virtual server receives from SMTP clients, and to track outgoing commands. There are 4 types of protocol logs:
  • Microsoft Internet Information Server (IIS) Log File Format
  • NCSA Common Log File Format
  • ODBC Log File Format
  • W3C Extended Log File Format
The default SMTP protocol log format is the W3C Extended Log File Format. This log enables you to choose the information you want to track.

To enable the W3C logging in Exchange 2000 Server and in Exchange Server 2003, follow these steps:
  1. Start Exchange System Manager.
  2. Navigate to the SMTP virtual server.
  3. Right-click SMTP virtual server and click Properties.
  4. On the General tab, click to select the Enable Logging check box.
  5. Under Active Log Format, click W3C Extended Log File Format, and then click Properties.
  6. On the General Properties tab, specify the log file size and location.
  7. Click the Extended Properties tab and click the items you want to track.

Message Tracking

You can use the Message Tracking Center to search for all types of messages, including system messages, public folder messages, and e-mail messages. This can be extremely useful when you think a particular message is absent, or if you simply want to track the status of a message.

To enable Message Tracking on a particular server, follow these steps:
  1. Start Exchange System Manager.
  2. Expand Administrative Groups\Admin Group Name\Servers\ ServerName.
  3. Click the server name that you want to enable Message Tracking on, and then click Properties.
  4. On the General tab, click to select the Enable Message Tracking check box. This option logs information about the sender, the time that the message was sent or received, the message size and priority, and the message recipients.
  5. To record the subject of any message sent to, from, or through the server, click to select the Enable Subject Logging and Display check box.
To track a message by using the Message Tracking Center, follow these steps:
  1. Start Exchange System Manager.
  2. In the console tree, expand Tools, and then click Message Tracking Center.
  3. In the Server box, type the name of the server that is running Exchange 2000 Server or Exchange Server 2003.

    To see an available server, follow these steps:
    1. Expand the Message Tracking Center node in Exchange System Manager.
    2. Type a server name in the Server box, and then click Find Now.
Note You can search for a message that was sent from or delivered to a particular server that is running Exchange Server. You are required to specify only the server name.

For example, to search for a message to a specific user, type the user's alias. If you do not know the user's e-mail address, click Recipients to search for the user in the Active Directory directory service. There are many other search options that are available in the Message Tracking Center.

Some standard troubleshooting steps for tracking down mail failures

  1. Determine where the message is stuck. To do this, follow these steps:
    1. Track the message if it just seems to disappear. See whether it is stuck in the categorizer, the message transfer agent (MTA), the Internet Mail Service, the Badmail folder, or elsewhere.
    2. Examine the non-delivery report (NDR) for error codes and to see which server and which component is generating the NDR.
  2. Examine the server that is mentioned in the NDRs, and make sure that all the services are running. In Exchange System Manager, click Tools, and then click Monitoring and Status to review the status.
  3. See which event IDs are in the application event log.
  4. Increase diagnostic logging to MAX for the transport components.
  5. Examine the error codes in the NDR.

    Note These errors may give you the solutions, such as checking the Domain Name Service (DNS) or network connectivity.

    For additional information, click the following article number to view the article in the Microsoft Knowledge Base:

    256321 Enhanced status codes for delivery - RFC 1893

  6. Determine whether all the Exchange command verbs for the SMTP service are present. To do this, follow these steps:
    1. Establish a telnet session with the Exchange 2003 or Exchange 2000 computer on port 25. To do this, click Start, click Run, type telnet localhost 25 in the Open box, and then click OK.
    2. Type ehlo, and then press ENTER. The following list appears:
      250-ServerName.example.com Hello [IP address]
      250-TURN
      250-ATRN
      250-SIZE
      250-ETRN
      250-PIPELINING
      250-DSN
      250-ENHANCEDSTATUSCODES
      250-8bitmime
      250-BINARYMIME
      250-CHUNKING
      250-VRFY
      250-X-EXPS GSSAPI NTLM LOGIN
      250-X-EXPS=LOGIN
      250-AUTH GSSAPI NTLM LOGIN
      250-AUTH=LOGIN
      250-X-LINK2STATE
      250-XEXCH50
      250 OK

      However, if the following command verbs for the Exchange Server 2003 or Exchange 2000 Server SMTP service are not present, the association of the Exchange Server 2003 or Exchange 2000 Server computer to the SMTP service is damaged:
      250-X-EXPS GSSAPI NTLM LOGIN
      250-X-EXPS=LOGIN
      250-AUTH GSSAPI NTLM LOGIN
      250-AUTH=LOGIN
      250-X-LINK2STATE
      250-XEXCH50
    3. Type quit, and then press ENTER to quit the telnet session.
  7. Confirm that all Exchange directories are excluded from scanning by any antivirus program.
  8. Run Regtrace and collect a trace file on the Exchange 2000 or Exchange 2003 computer that has the issue.
  9. Obtain a raw property dump file of the object that you are trying to send mail to, even if there are no event IDs or NDRs. For additional information, click the following article numbers to view the articles in the Microsoft Knowledge Base:

    255253 How to perform a dump of a container or object in Exchange 2000

    271201 Alternative methods to obtain a dump of an object

    199412 Administrator program dump files (Admindmp.txt)

  10. Verify that all the required object attributes that are being set on the User, Contact, and other Active Directory attributes are correct on the global catalog server.

    Note This must be the same global catalog server that is being referenced by the Exchange 2000 or Exchange 2003 computer where the message is stuck or where the message is getting an NDR from. If there are several servers that are listed, examine the one that is on the top of the list.
  11. Compare the attributes of the objects that you verified in step 10 to the attributes of the objects that are on the Exchange 2000 or Exchange 2003 computer.

    For Microsoft Exchange Server 4.0, 5.0, and 5.x, compare these attributes to the raw properties of the object:
    Legacyexchangedn
    Homemdb
    Homemta
    mailNickname
    proxyAddresses
    msExchHomeServerName
    msExchMailboxSecurityDescriptor
    msExchMailboxGuid

    For additional information, click the following article number to view the article in the Microsoft Knowledge Base:

    281761 Attributes required to route messages through the categorizer

  12. If all the attributes are incorrect, follow these steps:
    1. Verify that replication is working between global catalog servers. For additional information, click the following article number to view the article in the Microsoft Knowledge Base:

      200525 Using NSlookup.exe

    2. Verify that the Recipient Update Service is working. For additional information, click the following article number to view the article in the Microsoft Knowledge Base:

      246127 How to check the progress of the Recipient Update Service

    3. Verify that the Active Directory Connector (ADC) and all Connection Agreements are working correctly if you have any Exchange Server 5.5 computers. For additional information, click the following article number to view the article in the Microsoft Knowledge Base:

      261227 Exchange 2000 servers do not replicate to the Exchange Server 5.5 directory

    4. Verify that Site Replication Service (SRS) is running if you have Exchange Server 5.5 computers, including in remote sites. For additional information, click the following article number to view the article in the Microsoft Knowledge Base:

      261227 Exchange 2000 servers do not replicate to the Exchange Server 5.5 directory

    5. If everything in the previous steps appears to be working well, manually correct the incorrect attributes with the ADSI Edit utility in Active Directory.

      Warning If you use the ADSI Edit snap-in, the LDP utility, or any other LDAP version 3 client, and you incorrectly modify the attributes of Active Directory objects, you can cause serious problems. These problems may require you to reinstall Microsoft Windows 2000 Server, Microsoft Windows Server 2003, Microsoft Exchange 2000 Server, Microsoft Exchange Server 2003, or both Windows and Exchange. Microsoft cannot guarantee that problems that occur if you incorrectly modify Active Directory object attributes can be solved. Modify these attributes at your own risk.

For more information, see the following Microsoft Support WebCasts:

Modification Type:MinorLast Reviewed:5/23/2006
Keywords:kbhowto KB257265 kbAudITPRO