As part of my role at TSG I often get asked about email set up with Dynamics CRM. With Dynamics CRM 4 and 2011 email messages were sent and received either via the email router or via Outlook, this was great as you could track email messages against a case, contact, account etc. in CRM. In Dynamics CRM 2013 the Email Router and Outlook are still available, however as with the previous version of CRM you have to have Outlook open in order to synchronise contacts, appointments and tasks, something which doesn’t really lend itself to mobile working with the cloud.
One of the new features that came in with Dynamics CRM 2013 was the long awaited Server-Side Exchange Synchronisation.
Here we can see that now Server-Side Exchange Synchronisation runs as part of the CRM Asynchronous Service and connects to the exchange web services. This means we no longer need a dedicated service, and if we’re using CRM Online with Exchange on Office 365, we can have them integrate in the cloud, and access our Contacts, Appointments, Tasks, and tracked Emails via our PC, Windows Phone, and Surface Pro 3 all using Outlook!
Features of the Server-Side Exchange Synchronisation include the following:
Feature | Description |
Efficient Resource Utilization | Server-Side Synchronization provides management of mailboxes and allows you to disable inactive mailboxes with the Microsoft Dynamics CRM web application. You can prevent resource hogging by applying upper limits to polling intervals and concurrent connections to external email systems. |
Migrating Email Router Profiles | Switching from the Email Router is simplified by providing the capability to migrate Email Router incoming and outgoing profiles to Server Profiles for Server-Side Synchronization. |
Service Isolation | Server-Side Synchronization has separate queue-management and configuration settings for asynchronous operations. |
Error Reporting | Server-Side Synchronization provides error logging and reporting within the Microsoft Dynamics CRM web application. |
Performance Counters | New counters have been added to the asynchronous service for measuring queue performance and email processing.
|
So what are the supported configurations?
The following table shows the support configurations of CRM and Exchange, and what items will be synchronised.
CRM Deployment Type | Email System | Email Synchronization Supported | Synchronization of Contacts, Tasks, and Appointments Supported | Protocols Used |
Online | Exchange Online | Yes | Not at RTM, but now available | Exchange Web Services |
On-premise | Exchange 2010 Exchange 2013 | Yes | Supported | Exchange Web Services |
Online and On-premise | POP3 (incoming) SMTP (outgoing) | Yes | Not supported | POP3 SMTP |
Note: Server-Side Exchange Synchronisation does not support Exchange 2007, however the email router does.
We can do this by going to the Exchange Server, and opening an Exchange Management Shell. Then we need to run the following command:
Where crm-exchange.service@test.local is the account we want to use to connect to exchange.
Note: If we don’t grant the exchange impersonation role to this user, when we test the mailbox later we will receive the following error in the alerts:
Testing without SSL with Dynamics CRM 2013 On-Premise
To allow the saving of credentials when SSL is not used, we can run the following commands:
To allow the use of connections to servers that do not use SSL, we can run the following commands:
Note: A guide to using PowerShell with Dynamics CRM can be found on MSDN here which has a number of useful of cmdlets for administrating a Dynamics CRM Deployment.
Then we click on Create Self Signed Certificate from the right hand menu.
We enter a friendly name for the certificate and click OK.
We click on the Add button and select HTTPS from the Type drop down, we leave the port as 443 and select our newly created self-signed certificate from the SSL Certificate drop down list, and click OK.
So on the Web Address tab, we select the Binding Type as HTTPS and ensure the server addresses don’t have a port number associated to them, and this is because 443 is the default HTTPS port so we don’t need to specify it.
1. Create an Email Server Profile.
2. Configure the Mailbox record for the users to use the newly created Email Server Profile.
3. Configure Microsoft Dynamics CRM 2013 to use Server-Side Email Synchronisation.
From Dynamics CRM we go to Settings > Email Configuration, and select Email Server Profiles.
1. We click on New > Exchange Profile from the ribbon menu
2. In Name, we type “Exchange Test”.
3. In Auto Discover Server Location, we select No.
4. In Incoming Server Location, we type “https://TEST-CORE-02/EWS/Exchange.asmx”. (Where TEST-CORE-02 is the name of our exchange server)
5. In Outgoing Server Location, type “https://TEST-CORE-02/EWS/Exchange.asmx”. (Where TEST-CORE-02 is the name of our exchange server)
6. In Authenticate Using, we select Credentials Specified in Email Server Profile. Note: if the User Name and Password fields are disabled, this is because the web application is not accessed using HTTPS and we haven't disabled SSL via PowerShell.
7. We then enter our username (including the domain) and password.
8. In Use Impersonation, we select Yes.
9. In Use same settings for Outgoing, we select Yes.
10. If necessary, we click Advanced to expand the Advanced tab and can review the settings.
11. On the ribbon menu, we click Save & Close.
Now we need to configure a user mailbox record, so from Dynamics CRM we go to Settings > Email Configuration, and select Mailboxes.
1. We double click on the User record
2. Then we can select the Email Server Profile from the list, i.e. “Exchange Test”
3. We can specify the Incoming, Outgoing and what method we wish to use to Synchronise Appointments, Contacts and Tasks.
Once we have saved the Mailbox record, we can then click on the Test & Enable Mailbox from the ribbon menu.
Finally we need to configure the global email settings. From Dynamics CRM we go to Settings > Email Configuration, and select Email Configuration Settings.
We can then set Process Email Using to Server-Side Synchronisation, along with specifying the default synchronisation method for our users.
Note: The reason we use exchange web access as opposed to outlook is that if we had the CRM Outlook Plugin installed then it could synchronise with CRM as opposed to proving that the synchronisation actually took place at the server level.