In this two-part blog series, we’ll explore the technology that is revolutionising customer service delivery in government. In our first installment, we examine the technology transformation from the perspective of back-office processes.
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:
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:
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.
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.
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:
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:
12) Additional considerations.
If you've gone through these steps and are still having trouble, consider having PowerObjects help provide some support. We're happy to help!