Message Tracking to find the first hop into Exchange 2013

Scenario: You have added new Exchange 2013 servers to your existing Exchange 2013 environment and you just configured your perimeter devices to route SMTP email to the new servers in addition to the old servers.  You want to gather a log of emails to review to make sure no issues are occurring, but you first need to trace down which emails are coming into the new Exchange 2013 servers so you can trace those emails down until they are delivered into the mailbox.

Determine the IP address or the DNS host name of your perimeter devices and run the command below.  We will use the IP 10.10.1.2 as the perimeter system delivering email into the new Exchange 2013 servers.

PowerShell:

Get-transportserver NewServerName | Get-messagetrackinglog -start “7/7/2015 9:00am” -eventID Receive | Where EventData -like “*10.10.1.2*”

Note: The event data will display the term “firstforesthop” and the proxied connection info (Info of the Perimeter Devices). The term ‘FirstForestHop’  wasn’t a good way for us to rely on a query as we have had a mix of Exchange 2010 and Exchange 2013.  When it entered into Exchange 2013, it would have ‘FirstForestHop’ listed in the event data even if it wasn’t really the first forest hop as it came in from Exchange 2010.  But it did have the Perimeter device info in which did provide successful queries.

 

15 Minute Message Delays when Receiving email

Scenario:  It was reported that mailboxes were receiving message delays when receiving a message.​ The customer stated the time was 15-20 minutes before the message would make it into the mailbox. The message header was showing the delay, but not showing what was causing the delay.

Cause: We found that one of the servers was not accepting any messages, thus causing that hop to be delayed.  15 minutes was how long it would take for the next hop to occur again. When the next hop would happen it would select a different server to send the message.

Troubleshooting: We ran the following command to see where the message was being delayed.

get-transportserver | Get-messagetrackinglog -eventID Defer -Start 3/18/15 | Export-csv C:defer.csv

When we opened the csv file we found the common Servername that was having the issue.  When we logged onto the server to attempt to restart some Exchange services, it was apparent the server was having other issues. We rebooted the server and all was well when it came online again.