3. Testing Mail Flow
Testing mail flow has two main purposes. The first is to ensure that messages
pass through the system without excessive delay (latency). The second is to
determine the volume of messages passing through the system in a given time. If
the message volume is increasing, maybe you need to plan for future investment
so that your organization can seamlessly cope with the anticipated expansion.
3.1. Using the Test-Mailflow Cmdlet
You can use commands based on the Test-Mailflow EMS
cmdlet to verify that each of your Mailbox servers can successfully send
itself a message and to verify that the system mailbox on one Mailbox server
can successfully send a message to the system mailbox on another Mailbox
server.
A system mailbox must be present on all
servers involved in the test. For example, the following command tests that
the Mailbox server VAN-EX1 can send email to the mailbox with the SMTP
address [email protected].
Test-Mailflow -Identity VAN-EX1 -TargetEmailAddress [email protected]
Figure 11 shows the output from
this command.
The following command tests that the Mailbox server VAN-EX1 can send email
to the Mailbox server VAN-EX2:
Test-Mailflow -Identity VAN-EX1 -TargetMailboxServer VAN-EX2
Figure 12 shows the
output from this command. Note that unless you have installed a second
Mailbox server VAN-EX2 on your test network, this command returns a test
mail flow result failure.
You can also use the Test-Mailflow cmdlet to verify
that email is sent between Mailbox servers within a defined latency
threshold. The ErrorLatency parameter specifies how long Exchange Server
2010 waits for a test message to be delivered before an error event is
logged in Microsoft System Center Operations Manager 2007. The default value
when a test message is sent to the local Mailbox server is 15 seconds. When
a test message is sent to a remote Mailbox server, the default value is 180
seconds. You can specify in the command whether error events are logged
using System Center Operations Manager 2007 by setting the MonitoringContext
parameter to $true (the default value is $false). If you set the value
to of
this parameter to $true the command populates the MonitoringContext object
with events and performance counters used by System Center Operations
Manager 2007.
You can specify the maximum time that the test runs before the result is
determined to be a failure using the ExecutionTimeout parameter. If no test
message or delivery report arrives before this time expires, the task ends,
and Exchange Server 2010 reports an error. When the task is run in the EMS,
the default setting is 240 seconds. When you use the MonitoringContext
parameter set to $true to specify that System Center Operations Manager 2007
is being used for server monitoring, the default execution time-out setting
is 15 seconds.
The ActiveDirectoryTimeout parameter specifies the number of seconds that
elapse before the task provides an informational message about the delay.
The default value is 15 seconds. You can specify the display name of the
mailbox to which test messages are sent by using the
TargetEmailAddressDisplayName parameter. For example, the following command
sends a message to the Kim Akers mailbox if a test message from Mailbox
server VAN-EX1 to Mailbox server VAN-EX2 experiences a delay greater than
100 seconds:
Test-Mailflow -Identity VAN-EX1 -TargetMailboxServer VAN-EX2 -ActiveDirectoryTimeout 100
-TargetEmailAddressDisplayName "Kim Akers"
Note:
SYSTEM CENTER OPERATIONS MANAGER
2007
System Center Operations Manager 2007 does not have built-in cmdlets.
If you are using this facility you can set the MonitoringContext
parameter to $true.
3.2. Using the Microsoft Exchange Server Mail Flow Troubleshooter
The Microsoft
Exchange Server Mail Flow Troubleshooter is a diagnostic tool that helps you
troubleshoot mail flow problems. The tool diagnoses retrieved data, presents
an analysis of possible root causes of problems, and suggests corrective
actions. You can use the Mail Flow Troubleshooter to troubleshoot common
mail flow problems and identify the root causes of symptoms such as the
following so that you can corrective actions:
Users receive unexpected non-delivery reports (NDRs) when sending
messages.
Expected messages from senders are delayed or are not
received.
Messages sent to recipients are delayed or are not
received.
Messages are backing up in one or more queues on a server.
Specifically, messages are remaining in the pending submission
queue on a Mailbox server.
Edge Transport servers are not synchronizing with Active
Directory.
The Exchange Mail Flow Troubleshooter is part of the Exchange Server 2010
Exchange Troubleshooting Assistant. You can access the tool from the EMC by
clicking Tools and double-clicking Microsoft Mail Flow Troubleshooter. As
with all Troubleshooting Assistant tools, the first time you access the Mail
Flow Troubleshooter, you are given the choice as to whether to check for
updates at start-up and whether you want to join the Microsoft Customer
Experience Improvement Program. If you choose not to check for updates (a
choice you would make on your isolated test network but not on a production
network), then accessing the tool subsequently takes you straight to the
Welcome screen.
On the Welcome screen, shown in Figure 13, you specify a name
for your analysis and select a symptom from the list in a drop-down box. You
can also specify whether to hide the detailed analysis results until the end
of the analysis. The symptoms you can choose in the drop-down box are as
follows:
Users are receiving unexpected NDRs when sending messages.
Expected messages from senders are delayed or are not received by
some recipients.
Messages are not received by some of the intended
recipients.
Messages are backing up in one or more queues on a server.
Messages sent by users are pending submission on their Mailbox
servers.
Problems with edge server synchronization with Active
Directory.
3.3. Users Receiving Unexpected NDRs
When you or your users receive an
unexpected NDR, you can select Users Are Receiving Unexpected Non-Delivery
Reports When Sending Messages. When you click Next, the troubleshooter asks
you what delivery status notification (DSN) code the NDR contains and
provides you with guidance on what the DSN code typically means and what
actions are suggested. For some DSN codes, the tool checks whether the
records in DNS are consistent.
3.4. Messages from Senders Delayed or Not Received
If your Exchange organization is not receiving any messages from the
Internet or if some users can receive mails from the Internet but some
cannot, you would choose Expected Messages From Senders Are Delayed Or Are
Not Received By Some Recipients. When you click Next, the troubleshooter
carries out several tests because the root causes of mail flow issues can
vary from a transient network condition to a suboptimal SMTP configuration.
Depending on the results it receives, the troubleshooter will perform one or
more of the following troubleshooting steps:
Ping the designated gateway or bridgehead server
Test connectivity over port 25 and other designated SMTP ports to
the designated gateway or bridgehead server
Check the status of the SMTP service and SMTP virtual
server
Check filtering configurations
Send a test mail from a designated gateway or bridgehead to a
designated address
Check for known SMTP proxies that may be blocking SMTP
conversations
Scan message tracking logs from the sending server to the
destination server to determine how far the test message has
traveled and start the queue troubleshooter if a backup is
detected
Verify that local domains are correctly registered in the
metabase
If one or more of these tests fail, you are presented with a hyperlink
with the message Tell Me More About The Issue And How To Resolve It.
3.5. Messages to Recipients Delayed or Not Received
If no messages are going out to the Internet, you cannot send messages to
a specific domain, or you cannot send messages to a specific external
address, you should select Messages Destined To Recipients Are Delayed Or
Are Not Received By Some Recipients. The troubleshooter will perform some or
all of the following actions:
Locate the most recent message submitted by a specified sender to
a specified recipient
Scan message tracking logs beginning from the sending server to
see how far the message has traveled and start queue troubleshooting
if a backup is detected
Check the status of the SMTP service or SMTP virtual server
Check SMTP connector configuration
Check address space (remote domain) settings in the SMTP connector
and the metabase
3.6. Messages Backing Up in Queues
If you suspect problems
related to queues, you can select Messages Are Backing Up In One Or More
Queues On A Server. Queue testing can also be triggered automatically from
the mail flow tests described earlier in this section. The actions the
troubleshooter carries out could include the following:
Detect retry or frozen queues and also queues that contain large
numbers of messages
Test whether DNS servers can be accessed from a specified
server
Check whether DNS returns valid records for the remote
hosts
Test connectivity to remote hosts
Check remote SMTP virtual server configuration and status
Check the metabase for event sink registrations
Check whether SMTP Proxies exist
Check whether antivirus software is blocking SMTP ports
Check link states
Check Categorizer performance
Check journaling configurations
Check for dismounted databases
Check for missing SMTP system mailboxes
3.7. Messages Pending Submission on Mailbox Servers
If you suspect that email messages are being held for too long in pending
submission queues on Mailbox servers, you should select Messages Sent By
Users Are Pending Submission On Their Mailbox servers. Symptoms of this
problem include Outlook Web App (OWA) user messages being stored in the
Drafts folder and Microsoft Outlook 2007 and 2010 user messages being placed
in the Sent Items folder but not being sent. The Mail Flow Troubleshooter
will check registry settings and MAPI connectivity.
3.8. Edge Server Synchronization
The configuration and recipient data on Edge Transport servers is kept up
to date by periodically synchronizing changes from Active Directory to
Active Directory Lightweight Directory Services (AD LDS). By default,
configuration data is synchronized to AD LDS once every hour, and recipient
data is synchronized to AD LDS once every four hours. If you observe that
your Edge Transport servers are not maintaining synchronization and suspect
problems in this area, you should select Problems With Edge Server
Synchronization With Active Directory.
The troubleshooter will check the synchronization intervals (it is
possible that another administrator has altered these using the
Set-EdgeSyncService EMS cmdlet) and will suggest
other steps you can take. It is possible to force synchronization using the
Start-EdgeSynchronization cmdlet, but this is not a
long-term solution to this problem.
