One of the great features of Microsoft Dynamics CRM is the ability to send out automatic notification emails triggered by certain actions, such as creating an account, closing a case, adding a note to a case, or converting a lead. This is done using the email router. So what happens when you have a CRM environment with a working email router setup, and then something breaks? Instead of simply restarting the server (which may fix the problem), you would be better off to first identify the real issue. This Dynamics CRM email router troubleshooting guide will show you how to troubleshoot step-by-step a previously working email router environment, configured for outgoing emails.
Step 1: Determine if there is a problem with sending emails from CRM
Issues that stem from the email router may be reported with only vague details. For instance, you could have user call to say that "emails are not working," and you will have to determine whether the problem is specific to your CRM email router, Microsoft Outlook, Microsoft Exchange, or something else.
Let's say, for example, Mike calls the help desk to with an issue where a work order was generated in CRM, but Bob was not notified. In this case, Mike is counting on a workflow to an automatically email to specified users when a work order is created or changed. If Mike is an advanced user, he might recognize the issue and ask, "Can you check the email router? It doesn't appear to be sending out emails." But that might not be the case with everyone.
No matter how the issue is first brought up, the thing to you need to determine first is whether the issue is related to emails coming out of CRM. Sometimes other things can be confused with an email router problem, such as networking, Outlook (offline mode, junk folder), or Exchange (password change, email address change). So first you'll want to check whether the user still has network connectivity and is still receiving emails.
Step 2: Determine if the issue is specific to just one user, or across all users.
There are two different paths for troubleshooting a user-related issue depending on whether it affects just one user or the whole organization, so you'll want to determine that right away. There are two quick ways to determine this:
- Check with another user, or a few additional users, to see if they also are experiencing problems.
- Test by sending an email activity yourself from CRM to see if you receive it.
The second method is preferred, since it cuts down on additional variables that could be causing the issue. For example, the asynchronous service could stop working, and your users may not be able to tell if they are testing it all the same way—by creating a record that triggers a workflow that sends an email. If the async is down, no emails will be generated, even if the email router is functioning correctly.
If you can successfully send and receive an email activity manually created within CRM, it's likely a user issue. Proceed to step 3. Otherwise, go to step 9, since it is likely a server issue instead.
Step 3: If you've determined this is a use-related issue, check whether the user's outgoing profile is set to "email router."
Go to Settings > Administration > Users, and open the specific user who reported the issue. Scroll down to a dropdown box called "E-mail access type – Outgoing." If it is not already set, change it to e-mail router and save the record.
Check whether the user has Approve access.
You should still be in the user record from the last step. In the ribbon, click Approve E-mail. Once this is done, give it at least a few minutes to determine if emails are coming through.
Alternatively, you can remove the requirements for having to approve emails for all users and/or queues. You can do this by going into Settings > Administration > System Settings, and in the email tab, "Process emails only for approved users/queues."
Step 5: Check if the email activity exists in CRM.
To find the corresponding email that was supposedly created in CRM that the user claims he or she did not receive, start an advanced find and change "Look for:" to email messages.
Under the criteria, select Direction Equals Outgoing.
Now click on Results in the ribbon.
Once you have the list of outgoing email activities in CRM, click on the Modified On column to sort, then search for the email that the user did not receive. You may also want to specify additional criteria in the advanced find to further narrow it down.
If the email activity does not exist, then the problem is not the email route. Instead, it's likely a failure in the process or a user-related error within CRM, such as:
- Not following correct procedure
- A problem with the asynchronous service
- Changes done in CRM where the user was not made aware
If the email activity does exist, you'll need to examine the status reason of the email activity. Proceed to the next step.
Step 6: Does the Status Reason show as Sent?
If the status reason shows as sent, that means the email router successfully sent the email through SMTP or Exchange, and the issue most likely lies outside of the email router.
- First check the user's junk email folder, especially if you are using the tracking token.
- Examine the user's client-side rules to determine if anything caused the email to be deleted/moved.
- Check the SMTP or Exchange server logs to see if the email was successfully delivered.
- Also check logs for the incoming Exchange, in case the emails were blocked or rejected.
Step 7: Does the email activity show as Sending?
An email activity should only be in sending status for a short time. If it is in perpetual sending mode, you may see the "Number of delivery attempts" repeatedly going up (ideally, this number should not be higher than 1.) You'll need to verify that the sender of the email has access to the server sending the emails. Also check the error logs on the email router server to determine if a specific reason is causing it to fail.
Step 8: Does the email activity show as Pending Send?
An email activity in pending send is one that does not have a means to be delivered, which could mean various things. Since we have already checked that the user reporting the issue is set to use the email router, we should double check that the sender of the email has that set as well.
Open the email activity and check the sender of the email. Whether it is a queue or a user, it should have outgoing set to email router and access approved. See steps 3 and 4 on how to set this.
If the email was generated from a workflow where the owner of the workflow is different than the sender of the email, then the sender needs to have all emails on your behalf set.
- Login to CRM as the sender of the email.
Go to File > Options.
Go to the email tab and check "Allow other Microsoft Dynamics CRM users to send e-mail on your behalf."
Note: it may be beneficial to have this setting for all users. Since having every user log in to CRM to change their personal options can be tedious, you can update all users at once through two different methods. If you have direct data base access, you can run a SQL update query, in the orgname_MSCRM database:
set issendasallowed = 1
If you are using CRM Online, or do not have database access, you can also set this setting by downloading the user settings utility, available free from Codeplex. This allows you to manage user settings, including the allow email setting, through a web interface.
If the email activity is still in pending send status after these steps, login to the email router server, open the email router configuration, go to the tab for "users, queues, and forward mailboxes," and click load data. Check if the sender of the email appears in the list, then click Test Access. Make sure it succeeds. Then click the Publish button, and see if the email gets sent. If not, proceed to the next step.
9) Check the email router service.
First, check if the service "Microsoft Dynamics CRM Email" is running. If not, then start the service. If the service does not start, check if it is running under a service account, and if so, update the password to make sure it is correct. You may also try running the service as local system.
If this is not the case, then go to the following folder: C:program filesmicrosoft dynamics CRM EmailService
Rename the file Microsoft.Crm.Tools.EmailAgent.SystemState.xml to something else (like .old). Then attempt to restart the service.
Note: If you have incoming profiles set up, there are further considerations to take before renaming this file, since it keeps track of the last threshold date. Essentially, if this date is lost and you have queues setup, all previous emails will be re-created in CRM.
If it still doesn't start, it is possible the config file is corrupt. Sometimes this happens after a rollup update, but it is not a common error. To fix it, rename the following file to something else: Microsoft.Crm.Tools.EmailAgent.xml. Then run a repair on the email router installation, which will recreate that file, and attempt to start the service again.
10) Test access to the organization.
If the service is running correctly, open the email router configuration, go to the tab for "users, queues, and forward mailboxes," and click load data. If you receive an error message, verify that the account specified in the deployment can successfully login to the organization.
For on-prem environments, the quickest way to check is in the deployments tab. Open the configured deployment and copy and paste the URL into a browser, still on the email router server, while logging in as the user specified in the deployment.
If you cannot login, then verify that the user still has access, along with the system administrator security role. Possible reasons for failure to connect are:
- Change of password
- Reduction in security rights for the user
- Disabling of the user
- Change in the deployment configuration (such as configuring of ADFS).
If you can login through a browser, check if the user is in the privUserGroup security group, within active directory.
For CRM Online, attempt to login through the regular CRM URL in the email router server. Some possible reasons why it would suddenly fail to stop working are similar to an on-prem environment. A change in the deployment configuration could be a migration from CRM Online Live-ID to Office 365, in which the discovery URL changes.
One last thing to check is if you can still create a discovery service. You can test this by going to Settings > Customization > Developer Resources, and click on the URL below discovery service. This will bring up a new page that starts with "DiscoveryService Service" at the top. Click on the link at the top, just to the right of svcutil.exe, which should bring up an XML page. If you see a 500 error in the XML, then the Discovery service needs to be repaired before the email router will start working. As a quick fix, try an iisreset on the front end application server.
11) If you can successfully load data, then click on test access.
If an error message is received, verify that the connection to the SMTP server is still valid with correct access, and that the SMTP service is running. The error messages here are usually very accurate, and will say the exact error (such as unable to relay, impersonation failure, etc.)
If access is succeeding but no emails are being sent, there are two things to check:
- The outgoing port is correct.
- SMTP/Exchange server logs, emails may be sending but getting rejected on the incoming side.
12) Additional considerations.
- It is advisable to restart the email router service (not the server) at least once a week. A restart is quick, painless, and can be safely done during business hours.
- When installing CRM or email router update rollups, we also recommend for both to have matching updates. For Office 365 Exchange, you will need at least rollup 10 for the email router.
- Sometimes when going to "test access" it will hang indefinitely, without ever succeeding or failing, even if everything is working fine. A quick fix is to restart the email router service, and then attempt to test again.
- More often than not, there is no need to restrict user's access to the email router for outgoing, so you should strongly consider allowing everyone by default. See step 4 on how to set this.
- Using an SMTP server to send emails can be a bit tricky, in the sense that your IP address may end up in spam block lists, such as Spamhaus. If you are using the built-in Windows SMTP server and have having issues with emails arriving at user's inbox, check the inetpub folder, in the badmail folder, to see if anything is showing up. Also check the queue folder, to see if they are being processed. If they are not, a restart of the SMTP service would be advisable. If a restart still does not process the queues, then you may need to investigate whether your SMTP server external IP address is indeed in a spam block list. For this reason, we recommend against sending out large email campaigns through an SMTP server. Consider instead PowerMailChimp, a CRM integration for mailchimp.com, which sends out emails through their own servers. You do not need an email router configured, and you will never have to worry about spam block lists.
If you've gone through these steps and are still having trouble, consider having PowerObjects help provide some support. We're happy to help!