Troubleshooting Exchange mail flow requires the application of fundamental troubleshooting principles, the ability...
to quickly narrow the scope of the issue, and the use of multiple tools and log files. Combining those elements should help administrators find and resolve the issues quickly.
The series of components and services responsible for Exchange mail flow is referred to as transport, or the transport pipeline. With each version of Exchange Server, Microsoft has changed how transport works. For Exchange Server 2007 and 2010, the transport architecture is very similar. Both versions have a hub transport server role and an edge transport server role. Microsoft designed edge transport to be installed in a perimeter network, and it is not a mandatory server role. This means many customers will only have hub transport deployed in the environment -- usually as part of a multirole server install -- without any edge transport servers.
While the edge transport role still exists in Exchange 2013 and 2016, hub transport does not. Instead, Exchange 2013 and 2016 use a front-end/back-end transport architecture, which is made up of several services and internal components. In Exchange 2013, the front-end transport services are part of the client-access-server role, which could be deployed separately, but is mostly deployed with a multirole installation, following the recommended practice. Microsoft simplified things in Exchange 2016 by consolidating client access services into the mailbox server role, but from an architectural point of view, the front-end/back-end design is still there.
Understanding how the transport architecture works
The front-end/back-end architecture is simple enough to understand when it is broken down into the basics. Exchange servers host a series of connectors that are configured automatically by Exchange setup. The connectors associated with front-end transport are responsible for receiving Simple Mail Transport Protocol (SMTP) connections from clients and other servers; they proxy those connections to a connector on the back-end transport services. The front-end service will make intelligent proxying decisions to route connections in the most optimal way; one way it does this is by using Active Directory site topology and database availability group memberships to determine the most efficient way to route an email to a mailbox. Back-end services can queue messages, route them to other transport services or deliver messages to mailboxes.
Although the architectural changes are important, there are several other factors involved in email getting from a sender to a recipient, including domain names and domain name system (DNS) records, network and internet connectivity, firewalls and other security devices, and client configurations.
With so many moving parts, troubleshooting Exchange mail flow can appear complicated. However, by applying fundamental troubleshooting principles, administrators can narrow any mail flow troubleshooting scenario to a more manageable set of possible causes. For example, in the case of an email from an external sender not being received, ask questions such as:
- Who sent the email? Are other people receiving email from that person?
- Who was the intended recipient of the email? Are they receiving email from other people?
- Did the sender receive any error messages or nondelivery reports? If so, what do they say?
Other ways to further the troubleshooting process
There are also several tools and log files that can help diagnose an Exchange mail flow problem. To start, I like to use the Inbound SMTP Email test available on the Microsoft Remote Connectivity Analyzer website. When this test is run, it will send an email message to the specified address, using each of the available mail exchange (MX) records in DNS. During this process, the site will perform an end-to-end test of every inbound email route from the internet into your organization.
Sites with a single MX record in DNS can expect to receive a single email message. Sites with multiple MX records and inbound routes -- for example, if you also have an MX record pointing to a disaster recovery site -- can expect to receive multiple email messages from the Remote Connectivity Analyzer. If all of the expected messages are received, then you've successfully tested DNS, internet connectivity, firewall access and internal routing to your mailbox, which eliminates those possible issues from the troubleshooting process.
Protocol logs can give more clues
When you are confident Exchange mail flow is functioning, the next step is to check protocol logs. Protocol logs are recorded by the receive connectors associated with the transport services. By default, the front-end connectors that handle inbound SMTP connections have protocol logging enabled, allowing administrators to review the protocol log files to see if any SMTP connections for the sender or recipient of the troubleshooting case have had errors. The protocol log files are located in "C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\Hub\ProtocolLog\SmtpReceive" by default and are CSV-formatted text files that can be read in Notepad, or analyzed using PowerShell or Log Parser.
If no protocol log entries are found for the email in question, then troubleshooting should move outward to consider any email security devices or services that scan email messages before they reach the Exchange Server. Or, if the protocol logs show the email message was received, then the troubleshooting should move inward to further investigate the Exchange transport pipeline.
Using PowerShell cmdlets to check queues
Email messages stuck in transport can be found by running the Get-Queue cmdlet in the Exchange Management Shell. Get-Queue shows the queues on the server, the number of messages in the queue and the status of that queue, such as Ready or Retrying. To look at more details for a specific queue, run Get-Queue with the queue identity. For example:
Get-Queue "EX2016SRV1\27" | Format-List
If the queue is having problems delivering messages, the LastError property for the queue will show some reasons as to why, such as DNS lookup failure or SMTP connectivity errors. Piping Get-Queue to Get-Message can show messages held within a queue. For example:
Get-Queue "EX2016SRV1\27" | Get-Message
If email messages are not stuck in a queue, then troubleshooting can proceed to a message-tracking log search. Message-tracking logs record all actions taken on an email message as it passes through the transport pipeline, which can help to identity issues such as routing problems or messages rejected by transport rules. Message-tracking logs are searched using the Get-MessageTrackingLog cmdlet. For example, this command will search for messages sent from Alan to John within the last day:
Get-MessageTrackingLog –Sender email@example.com –Recipient firstname.lastname@example.org –Start (Get-Date).AddDays(-1)
Message-tracking logs will also tell if an email message was successfully delivered to a mailbox. This helps with troubleshooting, because, often, a missing email message can occur either through an inbox rule on the recipient's mailbox or a delegate accidentally moving the message. Knowing Exchange delivered the message can help the administrator proceed with inspecting inbox rules and performing searches in Outlook to find the missing item.
Options for administrators when handling disabled email accounts
Areas to check when the network isn't the issue
Migration of public folders requires thought before action