Author: Luke Palmer
Connecting Dynamics 365 with Exchange is pretty standard stuff if the Dynamics 365 and Exchange are both on an Office 365 tenant. It’s, probably, one of the easiest and simplest configurations there is for Dynamics 365! But what if Exchange is hosted on-premise? Then it’s not so simple!
There has been an on-going issue with an existing project where we had tried and failed to configure email integration between Dynamics 365 and a client’s on-premise Exchange Server. After getting the client to follow and complete the pre-requisites documented in the Dynamics 365 administration guide, we ran into a ‘401 Unauthorized’ error message everytime we tried to test the Email Server Profile using the ‘Test Connection’ in Dynamics.
This resulted in a back and forth between us and the client in an attempt to troubleshoot the issue and find a solution. With confirmation, the pre-requisites had been followed to the T, and the user credentials were correct and working (we were able to access Exchange Web Server endpoint via a browser). we were stumped!
Researching online about the issue only returned links back to the official Microsoft documentation and forums where others had reported the same issue but without a solution being provided.
We were left with no alternative but to log the issue with Microsoft. Had they made a mistake in the official documentation? Had they completely missed out a necessary pre-requisite? Can Dynamics 365 actually communicate with an on-premise Exchange Server? At this point, I was beginning to have my doubts.
A quick call with a Microsoft support agent revealed all…
It turns out that when connecting Dynamics 365 to Exchange on-premise, the Test Connection button for the Email Server Profile within Dynamics will always return a failure message. The agent confirmed that the best way of testing an Email Server Profile that connects to an on-premise Exchange Server is to test a mailbox within Dynamics.
Now we knew to ignore the false error message we set to work getting the configuration completed but still received failure messages when testing individual mailboxes. It transpired that the client hadn’t created a new service account as per the pre-requisites and that they had instead provided credentials of a historic service account.
I got the client to create a new service account specifically for CRM (ensuring the ApplicationImpersonation role was applied) and used these credentials for the Email Server Profile. I also got the client to provide details of a mailbox on their Exchange Server that we could use for testing.
With the new service account, details of an Exchange Server mailbox and the knowledge to ignore the false error on the Email Server Profile connection test I was able to successfully test and enable a user mailbox in Dynamics 365 and have it integrate with the user’s Exchange Server mailbox.
So to confirm, when configuring Dynamics 365 to connect to an on-premise Exchange Server,
- Ensure a new dedicated service account, that has the ApplicationImpersonation role, is created on the Exchange Server
- Use the dedicated service account to configure the Email Server Profile record.
- Ignore the ‘Test Connection’ button on the Email Server Profile record (step 5 in the official guide from Microsoft for connecting to an on-premise Exchange Server).
- Locate a user mailbox to test, ensuring that the email address field of the user matches the address used for their mailbox on the Exchange Server.
- Approve the user’s email, run the test on their mailbox and wait for the ‘Success’ messages to appear.
At Dogma, our mission is to be our clients’ most trusted advisors. If you have any questions regarding this feature, call our team on 01296 328689 or drop us an email at info@dogmagroup.co.uk.
