Author note: As you’ll notice with most of my blog posts, they tend to have a lot of information and are a bit long. Instead of sacrificing content, I’ll break up the posts into a series for posts. This way people don’t get overwhelmed with the amount of content but for those that want the deep technical details, they get that as well.
This article covers Message Analyzer and is the third article within the Email Router Demystified – Tools for Troubleshooting blog series. To get to a list of the other tools, go HERE.
Message Analyzer is such a neat tool developed by Microsoft. Message Analyzer allows you to capture all sorts of different data at the same time. For the purpose of this article, we will be using it simply as a network capturing tool.
You can get Message Analyzer here.
The install is pretty straight forward so we are not going to really cover any of the installation parts.
After installing Message Analyzer, you will need to do the following in order to capture network traffic
On the surface, the data being shown within Message Analyzer can be a little overwhelming.
What you are going to need are the IP addresses for every server you want to monitor the traffic on. This can help us figure out the traffic flow between CRM and the email server.
In my test environment, the IP addresses in play are:
Knowing that, I can make analysis a little easier by adding some aliases for the IP Addresses. To do this, I can right-click on the IP address within the Source or Destination column and go to “Create ‘Source’ Alias”:
Now I enter in the alias of my CRM server name (it has the .51 address) and click Save
I do the same thing for the Exchange server and now I can easily see where the requests came from and went to in the trace:
Next, I need to add filters to get data that is relevant to what I am looking for. When adding filters, I am going to try and filter the data as much as possible because the traces can end up getting pretty large. When we started the trace, we added some prefilters but I can do the same thing and add additional filters or if I didn’t add prefilters, I can add the filters now. In this case, I am only going to take a look at the SMTP traffic:
Now that I have the data filtered to the data I want, I can now see the request and the response within Message Analyzer. Now this is great for unencrypted data but not so great for traffic using TLS or SSL. However, even if we have to review encrypted traffic, we can get some sense of what is happening if we capture unencrypted traffic just to see what commands are being sent.
Again, we can spend a ton of time talking about the data returned by Message Analyzer and how to get the most out of the data but, for this article, we are simply going to focus in on the traffic.
If I look at the traffic, I can see that we start with the three way handshake and then CRM starts the requests.
So this is helpful to an extent, especially if it’s unencrypted data. We can simulate the same request by using TELNET.
We start off by establishing a connection to the email server (this should be the same server and port used in your Outgoing profile):
Now I simply do the same things we do as we saw in the trace:
We can get more details of what was the content of the email by looking at the payload from the MailPacket frame:
We can apply that same concept to POP3:
However, TELNET only works with unencrypted connections. If we are going to try to test an encrypted connection, you’ll have to use something like OpenSSL to test the connection. The commands are the same it’s just using a different application:
Again, we are using different tools to try and help us figure out where the issue lies. In this case, we are looking to see if the traffic is making it to and from the POP3 or SMTP server. If it is, are we able to make the same requests with other tools or is the issue simply with the email router? Using a combination of these tools allows us to confirm where the issue lies.