web
You’re offline. This is a read only version of the page.
close
Skip to main content

Notifications

Announcements

No record found.

Community site session details

Community site session details

Session Id :
Customer experience | Sales, Customer Insights,...
Suggested Answer

Cannot connect to CRM 8.2 on prem using CrmServiceClient from C# console application

(3) ShareShare
ReportReport
Posted on by 26
I have developed C# console app that connects through the XRM to the CRM 8.2 on prem. 
 
Everything works fine locally on my machine, the console app connects to the CRM 8.2 on prem successfully. 
 
The problem arises when I deploy the app on a windows server. It doesn't want to connect to the CRM 8.2 on prem.

I tried many times, changed the XRM version, nothing helps. 
 
I use the CrmServiceClient and pass the connection string like, usually it's the URL, the organization name, the AuthType and RequireNewInstance true
 
It worked with the same connection string before, never changed it, just when I deployed the app once again on the server, it just doesn't want to connect to the CRM anymore. 
 
Nothing major was changed, the servers that app connects to and the CRM urls are the same. 
 
I checked the restrictions on the server, seems all good, the app starts but doesn't connect to the crm 8.2 on prem. 
 
The user running the app has enough rights to connect to all the resources it needs, also it has an admin role in the crm.
 
I also tried to run the app with different user and on different server, nothing helped. 
 
I use the Microsoft.CrmSdk.XrmTooling.CoreAssembly.8.2.0.2 and the version of the tooling connector version is 2.2.0.0
 
Running the app on .NET 4.6.1 and also tried running it on 4.5.2. 
 
Did anyone else ever experienced such scenario? 
 
Answers would be highly appreciated. 
I have the same question (0)
  • RAkesh Agarwal  MTC Profile Picture
    4 on at
    Hi 
     
    Did you check the firewall at that server try to turn that off.
  • crm 8.2 developer Profile Picture
    26 on at
    Thanks for the idea. I have checked this and it shouldn't be an issue because we have another app on the same server that connects to the same CRM 8.2 on prem and works without any issues. 
  • Suggested answer
    Saif Ali Sabri Profile Picture
    2,351 Super User 2025 Season 2 on at
    This issue typically occurs due to missing prerequisites or environment configuration differences between your local machine and the target server. Here’s a concise checklist to resolve the issue:
    ✅ Key Checks and Solutions:
    1. Ensure TLS 1.2 is enabled (CRM 8.2 requires it): Add this at the start of your code:
    csharp CopyEdit
    ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
    1. Windows Server Missing Dependencies: Install the Microsoft Dynamics 365 SDK runtime dependencies:
    2. Correct CrmServiceClient Connection String: Make sure the connection string follows this format for On-Premises IFD:
    ini   CopyEdit
    AuthType=IFD;Url=https://yourorg.yourdomain.com;Domain=yourdomain;Username=yourusername;Password=yourpassword;RequireNewInstance=true
    Or AD (Active Directory):
    ini   CopyEdit
    AuthType=AD;Url=http://yourcrmserver/yourorg;Domain=yourdomain;Username=yourusername;Password=yourpassword;RequireNewInstance=true
    1. Firewall/Network Restrictions:
      • Confirm the server can reach the CRM URL (test via browser or Invoke-WebRequest in PowerShell).
      • Ensure port 443 (HTTPS) is open if using IFD.
    2. Check for Proxy or Credential Issues:
      • If there's a proxy, set CrmServiceClient.ProxyTypesAssembly accordingly.
      • Try explicitly using CrmServiceClient.UseDefaultConnection = false.
    3. Enable CrmServiceClient Logs for Diagnostics: Add this to get logs:
    csharp  CopyEdit
    CrmServiceClient.MaxConnectionTimeout = new TimeSpan(0, 2, 0); // Optional
    CrmServiceClient client = new CrmServiceClient(connectionString);
    Console.WriteLine(client.LastCrmError);
    Console.WriteLine(client.LastCrmException?.ToString());
    ✅ Recommendation:
    Deploy logging and test a minimal connection-only console app on the server to isolate the issue. 9/10 times, it's either TLS or missing dependencies on server.
  • Suggested answer
    Daivat Vartak (v-9davar) Profile Picture
    7,835 Super User 2025 Season 2 on at
    Hello CRM 8.2 Developer,
     

    es, this is a classic and often perplexing scenario where an application works perfectly in a development environment but fails upon deployment to a server. The fact that it worked previously on the server makes it even more intriguing.

    Here's a breakdown of potential causes and a systematic approach to troubleshoot this issue:

    1. Authentication Issues (Most Likely):

    Even though you're using the same connection string and the user has CRM admin rights, the way authentication works in a server environment can differ.

    • Kerberos Delegation: If your CRM 8.2 on-premise uses Kerberos authentication (which is common in domain-joined environments), the server where your console app is running might not be configured for proper Kerberos delegation. This means the server itself might not be trusted to pass the user's credentials to the CRM server.

      • Troubleshooting: Involve your domain administrator to check the Kerberos delegation settings for the server hosting your console application. Ensure it's trusted for delegation to the CRM server's service principal names (SPNs). 

    • NTLM Blocking: While less secure, if your CRM falls back to NTLM, the server might have stricter NTLM policies that are preventing the connection.

      • Troubleshooting: Check the security policies on the server and the CRM server related to NTLM authentication. 

    • Service Principal Name (SPN) Configuration: Ensure the SPNs for your CRM server are correctly registered in Active Directory. Incorrect or missing SPNs can cause authentication failures.

      • Troubleshooting: Use the setspn -L <CRM Server Name> command on the CRM server to list the registered SPNs. Verify they are correct for the CRM services (HTTP, MSSQLSvc, etc.). 

    • Firewall on the Server or Network: While you mentioned checking restrictions, double-verify the firewall on the server hosting your console app. It might be blocking outbound connections to the CRM server on the necessary ports (typically 443 for HTTPS or 5555 for HTTP if not using SSL). Also, check any network firewalls between the two servers.


    •  

    2. .NET Framework and Security Context:

    • Server Security Policies: The Windows Server might have more restrictive security policies regarding network access or code execution compared to your local machine.

    • Application Pool Identity (if running within IIS): If you're deploying this as a scheduled task or a service running under a specific application pool identity, ensure that identity has the necessary network access and permissions. Even if the logged-in user has rights, the service might be running under a different account.

    • Missing .NET Framework Components: While you've tried different .NET versions, ensure all necessary components for network communication and security are installed on the server.


    •  

    3. DNS Resolution:

    • Server DNS: Ensure the server where your console app is deployed can correctly resolve the CRM server's URL. A simple ping <CRM URL> from the server's command prompt can help diagnose this.


    •  

    4. CRM Server Issues (Less Likely if it works from your local machine):

    • CRM Service Status: Although unlikely if it works locally, quickly check the status of the Dynamics 365 services on the CRM server itself.

    • CRM Network Configuration: Verify if any network-related configurations on the CRM server have changed.


    •  

    5. Assembly Loading Issues (Less Likely with CrmServiceClient):

    • While less common with CrmServiceClient, ensure all the required CRM SDK assemblies are correctly deployed alongside your console application on the server. However, the error message would usually be different if this were the case (e.g., "Could not load file or assembly").


    •  

    Troubleshooting Steps:

    1. Enable Detailed Error Logging: Modify your console application to log very detailed error information when the connection fails. This might include the exact exception type, inner exceptions, and stack traces. This will provide more specific clues about the failure.

    2. Test Connectivity with Test-NetConnection: On the Windows Server, use the Test-NetConnection PowerShell cmdlet to test the TCP connection to the CRM server on the appropriate port (e.g., Test-NetConnection -ComputerName <CRM URL or IP> -Port 443).

    3. Run the Console App with Different User Accounts on the Server: Even though you tried this, be absolutely sure you are running it under the exact same user context that has CRM access and that the server process is indeed running as that user.

    4. Simplify the Connection Code: For testing purposes, create a very basic console app that only attempts to connect to CRM using the CrmServiceClient. Remove any other application logic to isolate the connection issue.

    5. Check Event Viewer on the Server: Examine the Windows Event Viewer (Application and System logs) on the server for any errors related to your application, network connectivity, or security.

    6. Temporarily Disable Windows Firewall on the Server (for testing ONLY): As a temporary diagnostic step, try completely disabling the Windows Firewall on the server hosting your console app to see if that resolves the connection issue. If it does, you'll need to configure the firewall rules correctly. Remember to re-enable the firewall immediately after testing.

    7. Monitor Network Traffic (Advanced): Use a network monitoring tool (like Wireshark) on the server hosting your app to see if any connection attempts are being made to the CRM server and if there are any errors at the network level.

    8.  

    In summary, the most likely culprit is an authentication or network-related issue specific to the server environment. Focus your troubleshooting efforts on Kerberos delegation, NTLM policies, SPN configuration, firewall rules on the server, and DNS resolution. Detailed error logging in your application and using network connectivity testing tools on the server will be crucial in pinpointing the exact cause.

     
    If my answer was helpful, please click Like, and if it solved your problem, please mark it as verified to help other community members find more. If you have further questions, please feel free to contact me.
     
    My response was crafted with AI assistance and tailored to provide detailed and actionable guidance for your Microsoft Dynamics 365 query.
     
    Regards,
    Daivat Vartak

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Responsible AI policies

As AI tools become more common, we’re introducing a Responsible AI Use…

Neeraj Kumar – Community Spotlight

We are honored to recognize Neeraj Kumar as our Community Spotlight honoree for…

Leaderboard > Customer experience | Sales, Customer Insights, CRM

#1
Tom_Gioielli Profile Picture

Tom_Gioielli 73 Super User 2025 Season 2

#2
Gerardo Rentería García Profile Picture

Gerardo Rentería Ga... 43 Most Valuable Professional

#3
Daniyal Khaleel Profile Picture

Daniyal Khaleel 32 Most Valuable Professional

Last 30 days Overall leaderboard

Product updates

Dynamics 365 release plans