Microsoft Dynamics CRM (Archived)

CRM 2011 - Outlook Client cannot connect

(0) Share

Report

Posted on by P.B.

130

Hello,

let me first give you an overview of my environment:

I've setup MS Dynamics CRM 2011 On-premise with separated application and database server. (DOMAIN\APPSRV; DOMAIN\DBSRV).

Port used for access is 55555 (yes, 5x5).

There are three domain accounts:

DOMAIN\svcCRM: service account for all services on APPSRV
DOMAIN\svcCRMdb: service account for database engine and reporting services on DBSRV
DOMAIN\svcCRMadmin: installation and administration account

Only HTTPS is used; the certificate is trusted and does not produce any errors or warnings in browsers.

The IIS application pool uses svcCRM as service account. Kernel mode is activated. useAppPoolCredentials is set to true. Authentication mode is set to "Negotiate" only (no NTLM). Anonymous authentication is allowed (IUSR).

Internet address in CRM deployment manager (4x): APPSRV:55555; binding type: HTTPS

Firewalls are disabled.

Workstation computers have *.appsrv.domain.tld added in Intranet security zone.

The following SPNs are added to the domain and delegation is set to "Trust all services (Kerberos only)":

SetSPN -S HTTP/APPSRV:55555 DOMAIN\svcCRM
SetSPN -S HTTP/APPSRV.domain.tld DOMAIN\svcCRM
SetSPN -S MSSqlSvc/DBSRV:51433 DOMAIN\svcCRMdb
SetSPN -S MSSqlSvc/DBSRV.domain.tld:51433 DOMAIN\svcCRMdb

The whole setup is working fine. I can add additional organisations in the deployment manager, I can connect to the website on "https://APPSRV.domain.tld:55555/organisation" and do stuff (manage users permission, add contacts, etc.).

Now I wanted to try out the CRM Outlook client (Outlook 2010).

I added my workstation user (DOMAIN\USER) to CRM (role: system administrator) and he can browse the website, too. I used the latest download version I could find (SetupClient.exe is dated 16th January 2012) and the installation went without errors.

After entering the URL (https://APPSRV.domain.tld:55555/) to the connection dialogue and clicking "Test connection", I get the following error:

There is a problem communicating with the Microsoft Dynamics CRM Server. The server might be unavailable. Try again later. If the problem persists, contact your administrator.

I enabled Kerberos errors for eventvwr.exe and there's the following entry:

The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server SVCCRM. The target name used was host/appsrv.domain.tld. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Please ensure that the target SPN is registered on, and only registered on, the account used by the server. This error can also happen when the target service is using a different password for the target service account than what the Kerberos Key Distribution Center (KDC) has for the target service account. Please ensure that the service on the server and the KDC are both updated to use the current password. If the server name is not fully qualified, and the target domain (DOMAIN.TLD) is different from the client domain (DOMAIN.TLD), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.

(I don't know why the "server" is the account svcCRM and the" target name" isn't an HTTP SPN).

After that, I tried to use "https://appsrv:55555" (NetBIOS name, not FQDN) and the error was similar, but this time, the "server" and "target" looked more logical:

The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server appsrv$. The target name used was HTTP/appsrv.domain.tld. This indicates [..]

There's also an error in C:\Users\USER\AppData\Local\Microsoft\MSCRM\Logs\Crm50ClientConfig.log:

13:42:15| Error| Error connecting to URL: https://appsrv.domain.tld:55555/XRMServices/2011/Discovery.svc Exception: System.ServiceModel.Security.SecurityNegotiationException: SOAP security negotiation with 'https://appsrv.domain.tld:55555/XRMServices/2011/Discovery.svc' for target 'https://appsrv.domain.tld:55555/XRMServices/2011/Discovery.svc' failed. See inner exception for more details. ---> System.ComponentModel.Win32Exception: Security Support Provider Interface (SSPI) authentication failed. The server may not be running in an account with identity 'host/appsrv.domain.tld'. If the server is running in a service account (Network Service for example), specify the account's ServicePrincipalName as the identity in the EndpointAddress for the server. If the server is running in a user account, specify the account's UserPrincipalName as the identity in the EndpointAddress for the server.

(But how do I specify the EndpointAddress?)

This was two days ago and I spent three days trying to correct this error. :/

I'd be really happy if someone could give me a hint why everything is working fine in browser, but the Outlook client won't work. I don't understand why the CRM Outlook client requests or gets a ticket with false information (account/SPN don't match the service accounts and SPNs).

Please let me know if you need additional information.

Kind regards,
P.B.

*This post is locked for comments

I have the same question (0)

All responses (9)

Answers (1)

graemed 415 on at

Like (0)

Report

You may need to add the IP address of the Microsoft CRM server to the Trusted Sites list of the Local intranet zone on the computer that is running the Microsoft Dynamics CRM client for Outlook

Start Internet Explorer.

On the Tools menu, click Internet Options.

Click the Security tab.

Click Local intranet, click Sites, and then click Advanced.

In the Add this Web site to the zone box, type the IP address of the Microsoft CRM server, and then click OK three times.

Restart Microsoft Outlook.

Can you also verify that the correct URL for the Microsoft CRM server is in the ServerURL and WebAppUrl registry keys

Click Start, click Run, type regedit, and then click OK.

Locate the following subkey:

HKEY_CURRENT_USER\Software\Microsoft\MSCRMClient

Verify that the URL listed in the

ServerURL

and the

WebAppUrl

registry keys contains the correct URL for the Microsoft CRM server.

An example of a URL in the

ServerURL

registry key is as follows:

http://servername:5555/mscrmservices

An example of a URL in the

WebAPPUrl

registry key is as follows:

http://servername:5555

If Microsoft CRM is installed on port 80, you do not need the port number listed in the registry keys.

Was this reply helpful? Yes No
AaronRic 10,035 on at

Like (0)

Report

I would recommend reviewing the Claims based authentication whitepaper. A few things I see here are NTLM must be enabled, you are using an HTTP port 55555 and if you have HTTPS configured, you need to be using an HTTPS port such as 443. Also, it is recommended to use a separate internal and external URL as an endpoint instead of the servername:port format

www.microsoft.com/.../details.aspx

Was this reply helpful? Yes No
P.B. 130 on at

Like (0)

Report

Thank your for your answer.

Unfortunately, adding the IP address of the server to the intranet zone didn't solve the issue.

The registry keys "ServerURL" and "WebAppUrl" are not present for the current user; I guess that's because the configuration wizard cannot finish because of the errors.

Kind regards,

P.B.

Was this reply helpful? Yes No
P.B. 130 on at

Like (0)

Report

[ Gnah, my previous post was addressed to Graeme Donnell. I thought it would be visible. ]

@AaronRic:

We don't have multiple domains and we don't plan to allow our users to access CRM from outside the company network. So I guess we don't need claims based authentication or separate URLs?

I changed the authentication providers in IIS to "Negotiate,NTLM", but the error still occurs in the CRM Outlook client.

We don't want to allow HTTP (or any unencrypted) communication to the server. Port 55555 is bound as HTTPS and (as I mentioned) it works without flaws in web browsers.

Kind regards,

P.B.

Was this reply helpful? Yes No
AaronRic 10,035 on at

Like (0)

Report

You might be best off creating a support request to further review the SPNs and configuration. However, I would first start by running a command prompt command of setspn -x to see if there are any duplicate SPNS at all related to CRM. If there are, you will need to remove these. Then, test the results. Next, you need to make sure that you have the HTTP SPNs for the service account that is running the CRM Application Pool. Also, if you are using HTTPS, make sure you only have the HTTPS binding and not an HTTP and HTTPS binding.

Was this reply helpful? Yes No
P.B. 130 on at

Like (0)

Report
Thanks again for your answer, Aaron.

SetSPN -X tells me that we don't have duplicate SPNs in our AD. There's a list of the SPNs that we use in the first post (plus a few more from the extensive testing). And in IIS, there already was only one binding .

By now, I have new information to make it more weird:

First, I changed all bindings from HTTPS/55555 to HTTPS/443 (plus SPNs without ports), but that didn't help.

Afterwards, I changed everything to HTTP/55555 and now, the Outlook client works! But without transport layer security. :(

So the client can work in our environment (WSDL/discovery and Kerberos apparently work), but the issue seems to be the combination with HTTPS.

FYI the changes that I made:

binding in IIS and binding type in the deployment manager

service URLs in the deployment manager

"ServerUrl" and "LocalSdkPort" values in the registry on the server

Was this reply helpful? Yes No
AaronRic 10,035 on at

Like (0)

Report

I think it would be best to create a support case at this time for a more thorough review of your configuration and the issue.

Was this reply helpful? Yes No
Zulqarnain 420 on at

Like (0)

Report

the computer from which you are trying to connect outlook to crm must be a member of the AD domain and you must be loged in as domain account, then you can connect your outlook to crm without any issue.

Was this reply helpful? Yes No
Verified answer

P.B. 130 on at

Like (0)

Report

@ Zulqarnain: This was/is the case in our environment.

Sorry for not posting the "solution" to this case. After endless hours of checking and setting SPNs in various ways, we tried something else and installed another CRM APPSRV on a completely new (virtual) server but used the same DBSRV and database like before (we didn't want to re-create our testing environment) - and everything worked fine!

I cannot say what exactly went wrong in the first place but a colleague had the assumption that there were SPNs set for the old APPSRV prior to my CRM installation (but they had been deleted long time before). It's a mystery until today; especially because the web authentication via Claims/Kerberos worked flawlessly...

Was this reply helpful? Yes No