Troubleshooting Mail Flow Issues in Exchange Server

by Brien M. Posey [Published on 21 March 2017 / Last Updated on 21 March 2017]

This article discusses some tools and general techniques for troubleshooting Exchange Server mail flow issues.

Exchange Server tends to be one of the more critical applications for many organizations, so when mail stops flowing, it is important to restore mail flow as quickly as possible. Fortunately, there are a variety of techniques that can help to resolve the problem.

Start with the Basics

Before jumping straight into the troubleshooting process, it is a good idea to gather some basic information about the problem. Taking a few minutes to better understand exactly how the mail flow issue is impacting the organization can help you to narrow down the possible causes of the problem, and may reduce the overall troubleshooting time. Some of the key questions that I recommend answering up front include:

  • Are all of the users affected by the problem, or does the problem only impact some users?
  • If only some users are affected, then what do those users have in common with one another? Are all of their mailboxes on the same server?
  • Does the problem occur with all mail flow, or is it limited to a specific type of mail, such as mail coming in from the Internet?
  • When did the problem start? Did any other significant events occur around that time, such as a patch being applied, or a piece of hardware failing?
  • Is Exchange displaying any error messages?

Once those basic questions have been answered, there are two things that I like to check for any on premises Exchange servers. First, I like to check to make sure that all of the required system services are running. The reason why I like to start out by checking the Exchange Server related services, is because it is easy to check the state of a service, and I have run into several situations over the years in which problems were traced to services that had stopped.

You can use the Service Control Manager to check the various services, but personally I like using PowerShell, because PowerShell makes it easy to cut through the clutter and find exactly what you are looking for. Here is a command that I like to use:

Get-Service | Where-Object {$_.Name -Like ‘MSExchange*’ -and $_.Status -eq ‘Stopped’}

As you can see in Figure A, this command displays Exchange Server services that have stopped.

Figure A

Image

 

You can use PowerShell to view the Exchange Server services that have stopped.

The second thing that I like to check up front is the amount of storage space that is available to the mailbox databases. In theory, administrators should be fully aware of how much storage space is available. In reality however, I have encountered multiple real world situations in which Exchange came to a grinding halt because it ran out of storage space.

 

The Test Mailflow Cmdlet

Another technique that I sometimes use when trying to diagnose a mail flow issue is to use the Test-MailFlow cmdlet. There are both advantages and disadvantages to using this cmdlet. The advantage is that the Test-MailFlow cmdlet is really flexible and allows you to test a variety of conditions. The disadvantage however, is that the cmdlet can only be used for on premises diagnosis. It does not work with the Office 365 cloud.

One of the most common uses for the Test-MailFlow cmdlet is to test mail flow between two Exchange mailbox servers. To do so, you need only to specify the name of the source and target mailbox servers. Suppose for instance that you wanted to test mail flow from a server named E2K16MBX1 to a server named E2K16MBX2. You could accomplish this by using this command:

Test-MailFlow E2K16MBX1 -TargetMailboxServer E2K16MBX2

As an alternative, you can test mail flow from an Exchange mailbox server to a specific E-mail address. To do so, run the Test-MailFlow cmdlet locally on the server that you want to test, and then specify the -TargetEmailAddress parameter, followed by the E-mail address that you want to test. You can see how this works in Figure B. Notice that the cmdlet not only reports that the test was successful, it also reports the message latency.

Figure B

Image

The Test-MailFlow cmdlet can test mail flow to a specific mailbox.

As previously noted, the Test-MailFlow cmdlet is very flexible, and there are a number of different parameters that you can use within your tests. You can find the full command syntax at: https://technet.microsoft.com/en-us/library/aa995894(v=exchg.160).aspx

 

The Exchange Remote Connectivity Analyzer Tool

Another tool that I like to use when diagnosing Exchange mail flow problems is the Exchange Remote Connectivity Analyzer. This is an online tool that tests an Exchange Server environment to verify that the correct firewall ports are open, and that the Exchange Servers are functioning correctly. You can find the tool at: https://testconnectivity.microsoft.com/

The Exchange Remote Connectivity Analyzer contains a number of diagnostic tests for Exchange, including some that are dedicated to testing inbound and outbound SMTP mail, POP mail, and IMAP mail. In addition, the tool does a good job of testing the AutoDiscover service, which is critical to proper client connectivity. You can see the available tests in Figure C.

Figure C

Image

The Exchange Remote Connectivity Analyzer Tool offers a number of different diagnostic tests.

The thing that I like about this tool is that the diagnostic information that it provides is generally very helpful. The test steps are organized into a tree view. If you look at Figure D for example, you can see the partial results of a mail flow test. In this case, the mail flow test failed, and the Exchange Remote Connectivity Analyzer was able to trace the cause to the message being blocked by Spamhaus.

Figure D

Image

The Exchange Remote Connectivity Analyzer was able to determine the cause of the failed test.

Conclusion

Hopefully, one of the diagnostic tools discussed in this article has helped you to resolve your Exchange Server mail flow issues. If not though, then be sure to check the server’s event logs. The event logs sometimes contain more detailed diagnostic information than what Exchange tends to display within its error messages.

 

See Also


The Author — Brien M. Posey

Brien Posey is an award winning author who has written over 3,000 articles and written or contributed to 27 books. You can visit Brien’s personal Web site at www.brienposey.com