Usually you’ll get alerted to this issue with a call saying that users have not gotten any new email for a while. They will still be connected to Exchange in outlook, you can still log on to the OWA and, when looking at your hub servers, you can see that the all services are up and running (Note that it is possible the transport service could be stopped…).

A number of reasons can exist as to why you are not getting any mail flow:

· Your recipient polies are not configured correctly

· The receive connector is configured incorrectly

· The mx record no longer exists

· The mail server is not reachable from the internet

· You ran out of space on your queue database drives

Let us look at each of these possible issues individually…

Testing mail flow

Before we actually go ahead and look at each of the items I would recommend, if possible, to test mail flow by running telnet and using the ehlo commands to connect to the server from both external and internal servers. That way you can narrow down where the issue is located.

Recipient policies

The recipient policies are responsible for “stamping” your users with the correct SMTP (email) address. If your users are not “stamped” with the correct address you will not receive email. Very simple yet oh so annoying… This will most likely be a problem you run in to at the setup of a new domain. Checking if the correct recipient policy is set up is quite simple and resolving it even simpler.

The mail server is not reachable from the internet

This could happen if a new firewall is installed but the rules and port forwarding are not configured correctly. If you want to test if the server is reachable from the internet try to use telnet to connect to the public ip address on port 25

telnet> o 132.157.125.23 25

Note that a default Exchange header response to this looks as follows:

If it does not look like this you are not connected to an Exchange server!

The mail queue

Exchange uses a number of queues to store the incoming mails before they get either sent on to other Exchange servers or delivers it locally. If the location of these queues are not changed they will be on the C:\ drive. As we all know, the C:\ drive has some strange gravitation field that causes it to fill up (unless you actually maintain that…). If you see it has less than 3GB available and you are not receiving email, you are faced with an automated protection mechanism that stops Exchange form accepting mail.

Exchange uses a number of queues to store the incoming mails before they get either sent on to other Exchange servers or delivers it locally. If the location of these queues are not changed they will be on the C:\ drive. As we all know, the C:\ drive has some strange gravitation field that causes it to fill up (unless you actually maintain that…). If you see it has less than 3GB available and you are not receiving email, you are faced with an automated protection mechanism that stops Exchange form accepting mail. This feature is called backpressure and is only present in the 2007 and 2010 versions of Exchange. Your C drive can, however, still fill up on an Exchange 2003 server . In case backpressure strikes you should see the following events:

Event log entry for critically low available memory Event Type: Error Event Source: MSExchangeTransport Event Category: Resource Manager Event ID: 15007 Description: The Microsoft Exchange Transport service is rejecting message submissions because the service continues to consume more memory than the configured threshold. This may require that this service be restarted to continue normal operation.

You have 2 possible ways to solve this:

1. Clean up your C drive

2. Move the transport queue location.

Personally I believe you should not leave the queues on the C drive as it is often overlooked, but then again, you should not allow the C drive to fill up anyway J.

To move the transport queues you should perform the following actions:

1. Open up a notepad session as administrator (right click, run as administrator)

2. Open the following file through notepad: C:\Program Files\Microsoft\Exchange Server\Bin\EdgeTransport.exe.config

3. Find the following section <appSettings>

4. Change the <add key=”QueueDatabasePath” value=” “> /> to reflect the new path.

5. Save and close

6. Restart the transport service

7. Verify the new mail.que and trn.chk files have been created at the new path

8. Remove the mail and trn files at the old path.

This should cover most of the issues you can encounter with mail flow. It is important to remember that these are all solutions for “bigger” issues, aka all users have been affect. In case there are only a number of users that are experiencing no mails use the message tracking log in the Tools section of the EMC to find out if they were even sent any mail… They might just be unpopular J.