Even though, in general, there should be no problems in a well running environment, you will often need to troubleshoot such problems as a result of bad WAN links or interrupts on VPN’s.
First, you should consider what protocols are actually being used in your email environment.
If you are running a native Exchange Server 2000/2003 environment switched to native mode, the only protocol that is being used is SMTP. If you are in mixed mode (and probably have Exchange 5.5 in your network) you will also use the X.400 transport stack. Perhaps you will note that there is still the MTA stack within a native environment but this is only for X.400 and/or RPC interoperability and nothing more.
In addition to this, there is another protocol that is being used for communication between Outlook and Exchange; this is the MAPI protocol that uses a set of RPCs itself.
With Exchange Server 2003 there is an implementation of only one view for every queue running on your server. If everything is working well, you should not have any emails in your queues anyway. But if queues are constantly growing without shrinking your server is having problems and you as administrator should be able to deal with this problem as soon as possible.
Figure 1: Message Queues in Exchange Server 2003
Troubleshooting Message Flow
Figure 2: Message Flow Basics
a) DNS Connectivity
Possible reasons for problems on incoming or outgoing email may be:
DNS server misconfigurations
Problems with the recipient policies
Filtering enabled for the domain enabled
Most of these message flow problems will have their root in DNS problems, so the first thing to check when troubleshooting is your DNS server. This can best be achieved using some core troubleshooting tools like:
All of these tools provide detailed information related to DNS name resolution. If you want to dive deeper into one of these, you should check the knowledgebase http://support.microsoft.com and get the individual how-to’s. Another way to check your external DNS is at a site such as www.dnsreport.com.
b) Non Delivery Reports
Non-delivery reports are always submitted to the original sender of each email and also to an administrative person ([email protected]). The general structure of NDRs is defined in RFC 1893. Each NDR provides a 3-digit status notification code that defines the failure in detail. Each of these three digits provides information about the failure itself and can be translated as follows:
- 2.x.x è successful transfer
- 4.x.x è persistent failure
- 5.x.x è permanent failure
The following list describes second and third digit:
x.1.0 è other address status
x.1.1 è bad destination mailbox address
x.1.2 è bad destination system address
x.1.3 è bad destination mailbox address syntax
x.1.4 è destination mailbox address ambiguous
x.1.5 è destination mailbox address valid
x.1.6 è mailbox has moved
x.1.7 è bad sender’s address syntax
x.1.8 è bad sender’s system address
x.2.0 è other or undefined mailbox status
x.2.1 è mailbox disabled, not accepting messages
x.2.2 è mailbox full
x.2.3 è message length exceeds administrative limit
x.2.4 è mailing list expansion problem
x.3.0 è other or undefined mail system status
x.3.1 è mail system full
x.3.2 è system not accepting network messages
x.3.3 è system not capable of selected features
x.3.4 è message too big for system
x.4.0 è other or undefined network or routing status
x.4.1 è no answer from host
x.4.2 è bad connection
x.4.3 è routing server failure
x.4.4 è unable to route
x.4.5 è network congestion
x.4.6 è routing loop detected
x.4.7 è delivery time expired
x.5.0 è other or undefined protocol status
x.5.1 è invalid command
x.5.2 è syntax error
x.5.3 è too many recipients
x.5.4 è invalid command arguments
x.5.5 è wrong protocol version
x.6.0 è other or undefined media error
x.6.1 è media not supported
x.6.2 è conversion required and prohibited
x.6.3 è conversion required but not supported
x.6.4 è conversion with loss performed
x.6.5 è conversion failed
x.7.0 è other or undefined protocol status
x.7.1 è delivery not authorized, message refused
x.7.2 è mailing list expansion prohibited
x.7.3 è security conversion required but not possible
x.7.4 è security feature not supported
x.7.5 è cryptographic failure
x.7.6 è cryptographic algorithm not supported
x.7.7 è message integrity failure
c) Message Tracking
The best way to have a log file of any messages that are being transported by Exchange is to enable Message Tracking in the properties of each server or by using a server policy and including all servers in that policy. With the message-tracking feature in your Exchange System Manager, you are now able to find detailed documentation of each step taken by an email within Exchange.
Figure 3: Message Tracking Center
d) Monitoring and Advanced Logging
In general, the best way to get any information on problems regarding your Exchange servers is to implement a good infrastructure of monitoring and logging. Exchange server itself provides a great set of tools for monitoring. There is not only the well-known performance monitor that you can use; Exchange itself provides some monitoring features of its own. You have to configure what indicators (servers, connectors, etc.) you want to monitor in the properties of your Exchange server in Exchange System Manager on the monitoring tab.
If you are thinking of implementing it, be careful that each server does not monitor itself. That would likely result in you getting information on problems after you have already solved them.
Figure 4: Monitoring
After having done this, you can set your monitoring method using the tools entry in Exchange System Manager.
The second built-in procedure for monitoring is to use any advanced logging feature. On the properties tab of each of your virtual servers (e.g. SMTP, IMAP4, POP3, HTTP…) you have the ability to configure your advanced logging features using a file or an ODBC connection at target. That means SQL Server may also be a collection point of protocols. And it is one of the best ways for analyzing the logs of the whole network.
And if you really need more detailed and professional solutions you should think of SNMP – there is an Exchange Server MIB – or by using Microsoft Operations Manager with the appropriate management pack for Exchange server and/or Active Directory.
Every administrator should be aware of the possibility of having trouble with message flow within each messaging environment; not only within an Exchange server environment. But if you, as an administrator, prepare yourself and your environment for monitoring and logging you will have a smart way to act as soon as possible should problems appear at some point in the future.