Tag Archives: dynamics crm 2013

“The target principal name is incorrect. Cannot generate SSPI context” error message during Dynamics CRM Setup

1 Reply

During Dynamics CRM 2015/2013 setup you might encounter this error in the final system checks process:

11

This is caused due to improper SPN’s (Service Principal Name) configuration for the SQL server. To resolve this follow these steps:
1. Connect to your SQL server and go to services (Start -> services.msc) from there locate your SQL service and check the Log on account

22

2. Open CMD with Run As Administrator and run the following commands one by one (you need to use a high privileged domain account):

setspn –A MSSQLSvc/<SQL Server computer name>:1433 <Domain\Account>
setspn -A MSSQLSvc/<SQL Server FQDN>:1433 <Domain\Account>

In my case the syntax would be:

setspn –A MSSQLSvc/CRM-SQL:1433 TZOOKI\sqlsvc
setspn –A MSSQLSvc/CRM-SQL.tzooki.com:1433 TZOOKI\sqlsvc

cmd

Notes:

  • If you are running SQL with NETWORK SERVICES or NT Service\MSSQLSERVER – then you need to register the SPN’s for the machine name (it is less likely to encounter this error in that scenario – but possible) – example:
    setspn –A MSSQLSvc/CRM-SQL:1433 TZOOKI\crm-sql
  •  If you changed the default SQL port from 1433 to something else – then you need to update the commands accordingly

3. In Dynamics CRM setup click back & next – Problem should be solved – You can now continue the installation.

Another approach:

If you have issues with the CMD commands then there is a way to solve this with a simple GUI instead:
1. Connect to your Active Directory server -> open the ADSI Editor and locate your service account (or machine name if you are using NETWORK SERVICES or NT Service\MSSQLSERVER)
2. Right click -> Properties

3

3. In the Attribute Editor locate ServicePrincipalName and click Edit.
4. Add your SPN’s accordingly:

4

5. Click OK & Apply – You installation should now go through without issues

Good Luck with the rest of the installation 🙂

Microsoft.Crm.CrmSecurityException: Could not find GUID for server: SERVERNAME$ With SearchFilter:samAccountName

Leave a reply

Hi everyone!

I have stumbled into the following issue during a CRM 2013 setup: You run a regular installation and the setup completes with the following error:

Action Microsoft.Crm.Tools.Admin.ProvisionBusinessAction failed.

Once I closed the error I noticed that CRM was actually installed and all the services were running, but the Organization was in a “failed” status and was inaccessible. When I tried to delete it and recreate it – it fails again with the same error.
After a closer look at the error log I found the following entry:

Microsoft.Crm.CrmSecurityException: Could not find GUID for server: SERVERNAME$ With SearchFilter:samAccountName

So I did some googling and found a few people that encountered this problem with an ADFS deployment – but nothing solved my issue.
Eventually the problem in my case was that ports 3268 & 3269 were blocked (those are the Global Catalog LDAP & Global Catalog LDAP SSL ports) and the solution to this was to open those ports in the Firewall.

If you encounter the same issue you need to check if the required ports are open against your current Domain controller:

1. Open CMD with run as admin and type “echo %LOGONSERVER%” – this will return the DC you are authenticating with.
2. Then type Telnet dcname port# (You need to add the Telnet client feature through the server management console).
For example: telnet DC01 3268

If you receive a message that a connection cannot be made – this means the ports are blocked and need to be opened by your IT staff / Sys admin.

You should run this test for all the required protocols:

Service Name TCP
LDAP 389
LDAP SSL 636
RPC Endpoint Mapper 135
Global Catalog LDAP 3268
Global Catalog LDAP SSL 3269
Kerberos 88

In any case you should always verify that all the required ports are open according to “Connectivity and Firewall Port Requirements for Microsoft Dynamics CRM 2013” document – which you can find here:

http://www.microsoft.com/en-us/download/details.aspx?id=40324

Hope this one was informative & Helpful 🙂

Michael.

CRM 2013 Fetch XML reports not working

Leave a reply

Here’s a scenario:

You install a fresh deployment of Dynamics CRM 2013 on one server using a domain account as the CRMApppool in IIS and Microsoft SQL with SSRS on a second server – Installation goes smoothly and everything works just fine including out-of-the-box reports – except that when you try to create and run Fetch XML reports you get the following error:

“the report cannot be displayed. (rsprocessingaborted)”

Image

Here is what you need to do (The changes that we’ll make might cause CRM to be unavailable for short periods of time):

1. Check the identity of the CRMAppPool. To do this simply click Start -> Run -> type inetmgr -> Press Enter. Expand the server name and under application pools check the CRMAppPool identity.

Image

2. You need to register an SPN for this identity – Let’s assume that the identity is domain\crmservice and the CRM server name is just crmserver.

Open CMD with “run as administrator” and type the following commands one by one:

setspn -A HTTP/crmserver domain\crmservice

setspn -A HTTP/crmserver.domain.com domain\crmservice

Important notes:

  • In the second line you need to use your domain’s FQDN – domain.com is just an example.
  • I’m assuming that you installed CRM on port 80, if not or if you are using host headers you will need to create the proper SPN’s along with the port number – for example:  setspn -A HTTP/crmserver:5555 domain\crmservice

You should get a confirmation that the SPN’s were registered successfully.

3. Browse to your SSRS URL (Probably: http://sqlserver/reports) and click ‘Details View’ on the right, then browse to:

YourOrganization_MSCRM > CustomReports > MSCRM_FetchDataSource – Inside make sure that the data type is set to ‘Microsoft Dynamics CRM Fetch’, the connection string has your Organization Name and connect using is set to ‘Credentials supplied by the user running the report’

Image

Save & Close.

4. Do an IIS reset (should work without but just in case…) Open CRM and check your FetchXML reports – they should be working now – It’s very important to check everything locally on the CRM server & remotely from clients or other server.

VERY IMPORTANT:

As we did changes in SPN’s that may mess up Kerberos authentication – you should check that CRM is available locally and from remote clients – If you are able to browse CRM locally (or using I.P) but you are getting 401 authentication error (after being asked for credentials 3-4 times) when trying to access from a different server or client using the CRM URL – do the following to resolve this:

  • On the CRM server open IIS and go to the Microsoft Dynamics CRM website -> Open the Configuration Editor

Image

  • Under Section browse to the following location – system.webServer -> Security -> Authentication -> Windows Authentication

Image

  • Inside make sure that UseAppPoolCredentials is set to True:

Image

  • Do an IIS reset on the CRM server. This procedure should resolve the 401 authentication issue and your CRM should be accessible from all clients along with the working FetchXML reports.

If from some reason your CRM started behaving “weird” or this process caused other issues you can revert all the changes we did by simply deleting the SPN’s and changing back UseAppPoolCredentials to False.

To delete the SPN’s use -D instead of -A:

setspn -D HTTP/crmserver domain\crmservice

setspn -D HTTP/crmserver.domain.com domain\crmservice

Remember that it’s best to do all those changes after working hours, as some of them might cause CRM to be unavailable. Also if you have a testing environment – it’s always better to test those things there before we do them on the production servers.

Good Luck!