Author Note: 

I first want to apologize for the delay in continuing this series.  It’s not because of a lack of desire but more of a lack of resources.  Since I first wrote the Email Router Demystified series, we have released a new version of CRM which included a new option of Server Side Sync.  This series is not going to cover Server Side Sync and focus on the Email Router.  However, a lot of the troubleshooting can be applied between Email Router and Server Side Sync.  I also want to apologize for the mix of screenshots between CRM 2011 and 2013.  I have been adding little by little to this post for the last couple of years.  You will see that this post is very sizeable and why it took so long to put out here.

Let’s now get into the biggest reason why you are probably here.  This next post is to go over troubleshooting of the Email Router.  In order to troubleshoot the Email Router, you must have a basic understanding of the items previously discussed as well as a basic understanding of the configuration of the Email Router.  The configuration of the Email Router has not been discussed as it is pretty extensive and would require its own blog series.  If there is enough interest in the configuration of the Email Router, then I will cover this in another series.

In order to understand how to troubleshoot the Email Router, let’s look at the potential break points of the Email Router. 

Troubleshooting Email Router Configuration Wizard issues

The first part of the Email Router to ensure you don’t run into any issues is around the Email Router Configuration Manager.  If you run into errors within the Email Router Configuration Manager, you will face these same errors when the Email Router is trying to process the email requests.  We need to ensure that the configuration is error free.

Load Data

The first step of ensuring the Email Router is configured properly is to click on Load Data.  When clicking on Load Data, it is going out to the Organization service and retrieving a list of CRM users that have their User Profile configured for E-mail Router for the Incoming/Outgoing E-mail Access Configuration.  If you run into an issue when clicking on Load Data, this indicates an issue accessing the CRM services, either the Discovery or Organization service endpoints.  To troubleshoot this issue, ensure you take the URL provided within the Deployment Profile and append it with the following: URL/XrmServices/2011/Discovery.svc?wsd
URL/XRMServices/2011/Organization.svc?wsdl

This should show an XML response like the following:

If you get any error accessing this URL, then you will need to troubleshoot those errors before the Load Data will ever work.  Since there are a vast number of problems that can come up when accessing this URL, we will not cover any of these. However, knowing that Load Data is directly related to the Deployment Profile should help you

Service Account

If you are able to access the Organization and Discovery services within Internet Explorer and not able to within Load Data, it could be an issue with the account running the Email Router service.  When clicking on Load Data, it is running under the context of the Email Router service account.  This account can be found within Services (Start > Administrative Tools > Services) with the name of Microsoft CRM Email Router.  By default, the account running the Email Router service is Local System.

NOTE: The service account needs to be a Microsoft Dynamics CRM user or it needs to be added to the PrivUserGroup for CRM OnPremise customers.

If you experience an error where the Email Router Configuration Manager is not able to Load Data, try changing the service account running the Microsoft CRM Email Router service to a domain user.  I have seen many situations where the Email Router is not able to connect to CRM due to proxy configuration.  Within these environments, the internet proxy configuration is pushed out to users and not applied to servers/workstations. 

If you still experience issues while clicking on Load Data after changing the service account to a domain user, then look at using a web debugger, called Fiddler, to try and give more information about what actual HTTP errors we are getting.  Again, when clicking on Load Data, we are trying to access a couple of HTTP endpoints from CRM.  In order for Fiddler to log the HTTP requests coming from the Load Data request, the Microsoft CRM Email Router service account must be the logged in user.  Fiddler will only capture HTTP requests of the user that opened the application.  We will cover using Fiddler in a later section but let’s view a situation where Fiddler can be used to help identify an issue with Load Data.

Fiddler 

In this scenario, I can see that when clicking on Load Data I am getting a very generic response in my OnPremise environment with Claims and IFD enabled.  When using the Auth endpoint for the Deployment Profile, the error I get from Load Data shows:

However, using Fiddler, I can get a better understanding of where the failure is occurring:

The error shows that it’s coming from ADFS.  This could help me with troubleshooting as I now know to look at the ADFS logs and see what exception is being raised there.

Test Access

After we have successfully loaded the users from the Load Data button, the next step to ensure the Email Router will work properly is to click on a user and then click on Test Access.  So when we click on Test Access, what exactly is the Email Router doing?  There is a lot of speculation of what this is exactly doing so let’s demystify and document what it actually does.

Incoming

1. The first request being made is out to Exchange using EWS to do a GetFolder request for the default folder providing the user’s Mailbox email address and authenticating as the account within the Incoming Profile.  The response that comes back should be that of the Inbox.
2. Now, as the account within the Deployment Profile, it logs into CRM and does a series of Organization service requests.  The first one is a WhoAmIRequest.  The WhoAmI response contains the user’s UserId, BusinessUnitId, and OrganizationId
3. The next CRM request being made is CheckRouterCompatibility.  This is to verify that we are not using an older or newer version of the Email Router that is not supported by that version of Microsoft Dynamics CRM.
4. Lastly, we do a CheckIncomingEmailRequest and checking if the result comes back with a ReasonCode of ShouldDeliver

Outgoing

1. The first thing that happens is a WhoAmIRequest being made to the CRM server as the account specified in the Deployment Profile.  The WhoAmI response contains the user’s UserId, BusinessUnitId, and OrganizationId
2. The next request being made is CheckRouterCompatibility.  This is to verify that we are not using an older or newer version of the Email Router that is not supported by that version of Microsoft Dynamics CRM.
3. Lastly, it does one of the following:
   1. SMTP: The Email Router is doing a HELO request.  The router is looking for a ReplyCode of 220 within the response that comes back from the server.  We can emulate a similar request by using a Telnet as discussed HERE:
      
       
   2. EWS: The router is doing a GetFolder EWS request for the Default folder.  The response that comes back should be that of the Inbox.

As long as no error is presented during these requests, then you should see Succeeded responses within the Email Router Configuration Wizard.

The next part of this post is to cover Troubleshooting Outgoing email issues.