Configuring Outlook Client usually involved making sure the regular stuff was done i.e.:
- Adding the server url to trusted sites.
- Checking whether the machine time matches the server time.
- Able to access Dynamics CRM through Web Client.
- Whether Windows Identity foundation was installed.
- Credentials cache cleared (Note: You can clear the credentials by going to the control panel -> credential manager. Then under Windows credentials, and generic credentials, remove any entry that starts with Microsoft_CRM)
All this was in order and it still did not allow configuration. We even went through the Outlook diagnostics wizard that walks through the various possibilities but nothing came to the rescue.
We had configured Outlook Client for an On-Premise system recently and therefore the issue was probably due to the IFD configuration. Something was not right with the IFD configuration. One well known issue in this regard was with using Windows Server 2012 and the mex endpoint issue as described here: http://cognettacloud.com/?p=861. But that was not the case here.
Let me first show the error that we received while configuring the Outlook client:
The error log showed the following error:
10:50:38| Error| Error connecting to URL: https://uat.adventure.com:444/XRMServices/2011/Discovery.svc Exception: Microsoft.Crm.CrmException: Authentication failed
at Microsoft.Crm.Outlook.ClientAuth.ClientAuthProvidersFactory`1.SignIn(Uri endPoint, Credential credentials, AuthUIMode uiMode, IClientOrganizationContext context, Form parentWindow, Boolean retryOnError)
at Microsoft.Crm.Application.Outlook.Config.DeploymentsInfo.DeploymentInfo.LoadOrganizations(AuthUIMode uiMode, Form parentWindow, Credential credentials)
at Microsoft.Crm.Application.Outlook.Config.DeploymentsInfo.InternalLoadOrganizations(OrganizationDetailCollection orgs, AuthUIMode uiMode, Form parentWindow)
We also tried connecting CRM using Plugin registration tool and it failed too.
We found the following blog that guided us to the real issue.
It was the ADFS mex issue – not the one about missing mex endpoint but the mex endpoint not running. Browsing the mex endpoint https://sts1.adventure.com/adfs/services/trust/mex returned a 503 service unavailable. ADFS logs does not indicate any error about this when you try to login through the outlook client. However when you restart the ADFS service, look for the following error in the log:
Event ID: 102
There was an error in enabling endpoints of Federation Service. Fix configuration errors using PowerShell cmdlets and restart the Federation Service.
System.ServiceModel.AddressAlreadyInUseException: There is already a listener on IP endpoint 0.0.0.0:808. This could happen if there is another application already listening on this endpoint or if you have multiple service endpoints in your service host with the same IP endpoint but with incompatible binding configurations. —> System.Net.Sockets.SocketException: Only one usage of each socket address (protocol/network address/port) is normally permitted
ADFS & Dynamics CRM was installed on the same box in this case and so the Sandbox Service was running on this server. Incidentally the port being used by Sandbox Service & ADFS is the same port 808 and therefore the conflict in starting the mex endpoint.
The solution then was to change the ADFS service port from 808 to another one.
To change port, we can use the below powershell command. Here, we are setting port as 809 for ADFS service.
Powershell command :
Set-ADFSProperties –nettcpport 809
Note: The first step to running a powershell command that most sites list is to attach the snappin
However, running this command in Powershell in Windows Server 2012 returns an error. It appears that command is no longer required and the snappin is already attached.
After this you need to restart the ADFS service and check if you are able to browse mex endpoint url.
Once you have verified the mex endpoint URL is running, you will be able to successfully connect to Dynamics CRM Web Services using all the client tools be it the Plugin Registration tool or the Outlook client. I did not try the Tablet client or the Mobile client but certainly that too would have failed to connect if the mex endpoint was not running. This is going to be one check that I would add after every IFD configuration to ensure this does not repeat. Thanks to Bhavesh the blog writer for pointing us in the right direction.