At Customer Effective, we recently moved to Office 365, including hosted Exchange. As part of this migration, we had to repoint our Microsoft Dynamics CRM e-mail router to hosted exchange. We use the e-mail router to route in-coming messages from our support email to CRM, and also to route out-going messages from CRM to Exchange.
As a first step, if you are configuring the CRM e-mail router to work with hosted Exchange, I highly recommend this excellent post from the CRM team blog: While it is a couple of years old, it is still very applicable to CRM 2011.
To make the change to hosted exchange, I logged on to our e-mail router server and opened the CRM E-mail Router Configuration Manager.
On the Outgoing and Incoming profile records I changed the E-mail Server Type to Exchange Online.
Incoming Exchange Profile
My next question was, what should I enter for the server URL for the incoming profile? For on premises, you typically do the url of your exchange server; however, for online Exchange, it requires the Exchange web services URL. It was not immediately apparent what that should be.
Hosted Exchange does offer an autodiscovery service. By checking the autodiscover checkbox, it is supposed to discover your URL for you. In my tests, this would show success when I tested the connection on the load users and queues tab of the email router configuration, but it would not actually work.
The URL I finally found that worked was *.outlook.com/ews/exchange.asmx (replace the * with your specific Exchange Online location).
Outgoing Exchange Profile
For the outgoing profile, I set the server URL to the same URL that I did for the incoming profile. The biggest challenge with the outgoing profile was the authentication to send outgoing e-mails.
In many deployments, the e-mail router is used to send system generated workflows from processes such as workflows. Given that these workflows can be triggered by multiple users, we want the notification e-mails to be sent “from” the user that triggered the workflow.
To make this happen, the account that you use to connect to Exchange for your outgoing email router profile requires “send as” permission for the user it is sending email as. For router-sent email, each user is not actually connecting to the router to send e-mails—the router is retrieving all pending send emails and sending them via a singe exchange account.
It was unclear what exactly was necessary to grant the account we specified “send as” permissions in Exchange online. We granted him send as privileges, but after testing we found that emails were not sending out of CRM.
It turns out that you have to grant the account “send as” privileges individually for each mailbox that you want to have emails sent as. If you don’t, emails from users for which you did not grant the privilege will not be sent.
If, on the other hand, you don’t want to grant “send as” privilege over other users mailboxes, the alternative is to select delegate. This will result in the message being sent “on behalf of” the user, and it will appear that way in the e-mails that are sent. This also requires that a specific delegate privilege be granted per mailbox to the service account that you specify in the router configuration manager.
Lesson learned—with hosted Exchange, you need to make granting “send as” privileges to the administrator service part of your new crm user provisioning process when you add new users, if you want emails from the web client or system generated emails to be sent as the user.
Bonus Tip: Enabling E-mail Router Logging
If you are experiencing issues with your e-mail router, turning on logging will give you much greater detail than the errors messages that appear in the E-mail router configuration manager or the event log. To enable logging, go to the C:\Program Files\Microsoft CRM Email\Service folder (if you selected the default location when you installed the router).
In this folder, you will find a file named Microsoft.CRM.Tools.EmailAgent.xml. This is the configuration file for the E-mail router.
Open the file and look for the following section:
<ConfigUpdatePeriod>3600000</ConfigUpdatePeriod>
<LogLevel>1</LogLevel>
<LogFile></LogFile>
Change the value in <LogLevel> to 3, and in the <LogFile> section, specify the location where you want it to put the log file (like c:/routerlog.txt.
The router log will give you a lot of detail, including granular detail on each incoming and outgoing e-mail that it processes.
Using the logs we were able to identify that the problem was the service account did not have send as privileges over the mailboxes it was trying to send mail as, and we were able to remedy the issue, and our emails are now once again coming and going without issue.
Post by: Joel Lindstrom,
