Logo
programming4us
programming4us
programming4us
programming4us
Home
programming4us
XP
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server
programming4us
Windows Phone
 
Windows Server

Exchange Server 2010 : Generating Reports (part 3) - Testing Mail Flow

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
5/20/2011 11:44:15 AM

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 Administrator@adatum.com.

Test-Mailflow -Identity VAN-EX1 -TargetEmailAddress Administrator@adatum.com


Figure 11 shows the output from this command.

Figure 11. Testing mail flow to a mailbox


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.

Figure 12. Testing mail flow to another Mailbox server


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.

Figure 13. Mail Flow Troubleshooter Welcome screen


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.

Other -----------------
- SharePoint 2010 PerformancePoint Services : Using Windows PowerShell and Cmdlets (part 2) - Cmdlet Samples
- SharePoint 2010 PerformancePoint Services : Using Windows PowerShell and Cmdlets (part 1) - Cmdlets Available Out of the Box
- BizTalk 2010 Recipes : Administration and Operations - Restarting the BizTalk Host Instance(s)
- BizTalk 2010 Recipes : Administration and Operations - Tracking Messages
- BizTalk 2010 Recipes : Administration and Operations - Debugging Orchestrations
- Monitoring Exchange Server 2010 : Debugging Network Connectivity (part 4) - Using Exchange Server ActiveSync
- Monitoring Exchange Server 2010 : Debugging Network Connectivity (part 3)
- Monitoring Exchange Server 2010 : Debugging Network Connectivity (part 2)
- Monitoring Exchange Server 2010 : Debugging Network Connectivity (part 1) - Using Telnet to Test SMTP Communication
- Backing Up Windows Server 2008 R2 Role Services (part 3)
 
 
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
 
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server