MSExchangeGuru.com

Learn Exchange the Guru way !!!

 

Test-Mailflow with Exchange 2013

Test-Mailflow is a cmdlet available in Exchange 2013. This command allows us to test the delivery of mails between two mailboxes. The test will be performed using the system mailbox. Test-Mailflow cmdlet basically tests the mail submission, transport, and delivery. This command is used to verify that the system mailbox on one Mailbox server can successfully send a message to the system mailbox on another Mailbox server. By running the command Test-Mailflow, we can find if the mail flow was successful or not. Along with the information we can also see the message latency info, which will be useful in finding out slow mail delivery due to server or network issue.

Test-Mailflow result:


Values:

Test-Mailflow Result: You get either “Success” or “Failure”

Message latency Time: The taken to deliver the test message. It is displayed in this format hh:mm:ss.ffff

List of Parameters that can be used with Test-Mailbox Cmdlet:

AutoDiscoverTargetMailboxServer

This switch determines whether to automatically populate a list of target Mailbox servers to which to send a test message. This task runs a query in Active Directory to find all Mailbox servers and then sends each server a test mail. Also note that when you use this switch you can’t use these parameters: CrossPremises, TargetDatabase, TargetEmailAddress or TargetMailboxServer.

TargetDatabase

This parameter specifies the mailbox database to which test messages are sent. Make a note of these parameters which you can’t use along with the TargetDatabase parameter: AutoDiscoverTargetMailboxServer, CrossPremises, TargetEmailAddress or TargetMailboxServer

TargetMailboxServer:

This parameter specifies one or more Mailbox servers in the local exchange org to which the test message are sent. When using this parameter we can’t use these parameter: AutoDiscoverTargetMailboxServer, CrossPremises, TargetDatabase or TargetEmailAddress

TargetEmailAddress:

This parameter specifies the SMTP address of the mailbox to which the test messages are sent. We can use this parameter to send test messages to a Mailbox server in a remote forest. Basically this parameter is used only for remote test. We can’t use these parameters with TargetEmailAddress parameter: AutoDiscoverTargetMailboxServer, CrossPremises, TargetDatabase or TargetMailboxServer.

CrossPremises:

This parameter is used to specify whether the mail flow test will be performed in cross-premises mode. Make sure to set this parameter to $true if your organization is using cross-premises deployment & to verify the cross-premises mail flow. Also note that when using CrossPremises parameter we can’t use these: AutoDiscoverTargetMailboxServer, TargetDatabase, TargetEmailAddress or TargetMailboxServer parameters.

ActiveDirectoryTimeout:

This parameter specifies the number of seconds that elapse before the task sends an informational message about the delay and the default value is 15 seconds.

CrossPremisesExpirationTimeout & CrossPremisesPendingErrorCount

These parameters are used when the commands are run by Microsoft System Centre Operations Manager 2007 agents for monitoring & Microsoft does not recommend running this command.

ErrorLatency:

This parameter specifies the duration of the wait time for a test message to be delivered before an error event is logged in Microsoft System Centre Operations Manager 2007. The default values are: 15 seconds when a test message is sent to the local Mailbox server & 180seconds when sent to a remote Mailbox server.

ExecutionTimeout:

This parameter specifies the maximum time that the task can run before the test is determined to be a failure. So when there is no test message or delivery report before this time expires, the task ends & an error is reported. The default value when the task runs in the Exchange Management Shell is 240 seconds & when MonitoringContext is used the value is 15 seconds.

MonitoringContext:

This parameter either includes or excludes the associated monitoring events and performance counters in the results. We can use these tow inputs $true or $false, however the default value is $false.

TargetEmailAddressDisplayName:

This parameter specifies a custom display name that’s used on events and reports in Microsoft System Centre Operations Manager 2007. If we don’t use this parameter the events & reports use the email address value specified by the parameter TargetEmailAddress.

Examples:

To test message flow from the server SERVER1 to the server SERVER2.

                    Test-Mailflow SERVER1-TargetMailboxServer SERVER2

To test message flow from the server SERVER1 to the e-mail address userA@msexchangeguru.com

                    Test-Mailflow SERVER1-TargetEmailAddress userA@msexchangeguru.com

We can specify the database to run the same command:

                    Test-Mailflow SERVER1 -TargetDatabase “MBX Database1”

We can pipe the output to ConvertTo-Html or ConvertTo-Csv and adding “> <filename>” to the command:

                    Test-Mailflow -AutoDiscoverTargetMailboxServer | ConvertTo-Csv > “C:test-mailflow 2015-05-05.csv”

Ratish Nair

Microsoft MVP | Exchange Server

Team @MSExchangeGuru.com



2 Responses to “Test-Mailflow with Exchange 2013”

  1. Malcolm Dryden Says:

    We are running Exchange 2013. Some specific users are experiencing messages that take 6 to 9 minutes to reach another Exchange User. I tried using the Test_Mailflow command on our Exchange ECP and the command does not exist. TechNet suggests that this command is only available in Exchange 2016 (on-premises). Any other ideas on testing mailflow in Exchange 2013?

  2. Prabhat Nigam Says:

    It can be anti-Virus scanning.

Leave a Reply

migrate exchange to office 365

Categories

Archives