Last night in my house I witnessed a prolonged discussion between two people of different
I recently had to assist a client troubleshoot their Dynamics CRM 2013 and Exchange 2010 server-side synchronization configuration which was not working in one of their environments. We were attempting to use impersonation so that the CRM Async Service account could synchronise mailboxes for CRM users.
We kept getting Http Unauthorized errors appear after running the ‘Test and Enable Mailboxes’ process. I tried all the different types of configuration – storing the credentials in CRM,Windows Authentication (which relies upon the service account), even storing the credentials for individual users. At the time I couldn’t confirm that impersonation was configured correctly, but I felt something else was wrong.
When individual user accounts failed to work with their credentials stored in CRM I knew something was definitely wrong. Continually getting this Http Unauthorized error message was driving me mad because I knew the credentials were correct, I could log on to Outlook Web Access with that account (also confirming that network connectivity from the CRM box to the Exchange box worked).
In the end I checked the Exchange IIS settings for the EWS virtual directory. This hosts the Exchange Web Services which are called by Dynamics CRM. For some reason Windows Authentication in IIS was disabled. What this meant was that no clients were being challenged (prompted for credentials), so no credentials were being sent back which meant that all calls were unathenticated. This matched with what I saw in the IIS logs – 3 x 401 errors with no username logged. Simply correcting this problem – setting Windows Authentication in IIS to enabled for the EWS virtual directory and voila, individual user credentials stored in CRM started working. Progress.
I then had some minor problems to fix with the Impersonation configuration, but that led to me the next challenge – how do you know for sure that Impersonation is configured correctly? I found a very useful tool that is initiated from PowerShell that is essentially a SOAP client. It allows you to provide credentials for an account (in my case the service account), communicate with the Exchange server via EWS and attempt to open other mailboxes (plus much more). This helps prove whether the configurations is correct or not.
This tool is called the Simple Exchange Email Client For PowerShell and is available here. It also relies upon these DLLs available here. Install this on a server (doesn’t have to be the Exchange server but that rules out other complications), run it up and give it a go.Invaluable. A more manual method would be to use a tool like SoapUI to hand craft the web service calls – but without being completely familiar with the API that would take longer.
Then, finally, you can configurethe CRM Server Profile in the usual manner and enjoy much success.