After modifying the CRM URLs, a CRM user might receive a Message from webpage – “generic error” on his or her dashboard in Microsoft Dynamics CRM. The social pane (What’s new) will show “An error occurred. Please wait a few moments and try again. If the problem persists, contact a system administrator”.
Furthermore, the CRM webservices will also be unavailable.
While looking for a solution, I stumbled on the post “Changing CRM 2011 URL after installation” from Andy Dawson (thank you Google!). Whereas this blogpost has been made for a CRM 2011 installation and is mainly focused on modifying the URL used for CRM 2011 after installation, it seems to have nothing to do with this “Generic error”.
Surprisingly enough the post holds the steps which are the same ones I discovered to solve this problem. Moreover, it was quite interesting to read and to compare this with a Dynamics CRM 2013/2015 installation. I have to admit that I had a lot of help of a colleague at the office (thank you Mr. Miguel!) and I could not have found the solution without him.
I will follow the outlined steps by Dawson, illustrate them where possible and point out the differences.
First, to understand how the error occurs, you need to know what happened before the error. Dawson has discussed how you can change the bindings of your website. Somebody has probably modified the bindings for the CRM (2011/2013/2015) website on the server running CRM to a new value (e.g. port 5555) instead of an old value (e.g. port 80). Which caused the “generic error” on the dashboard. You can change these bindings yourself by doing these steps:
- Open IIS Manager
- Select the Microsoft Dynamics CRM website
- Click ‘Bindings’ in the action panel at the right of the screen
- Select the binding to modify
- Click ‘Edit’ and modify the host name and port to the new value.
- Close the dialog and IIS Manager.
Second, something which Dawson has not mentioned, you’ll need to add “Negotation” as second provider in the “Advanced Settings” from “Windows Authentication” from the CRM website.
Go to the website, choose Authentication.
Next, Windows Authentication, Providers, Add Negotation under NTLM (if is already added, make sure it is moved down).
Update CRM Deployment Manager
Third, you need to modify the global settings for CRM from within the Microsoft Dynamics CRM Deployment Manager.
- Start the Microsoft Dynamics CRM Deployment Manager.
- Right-click on the ‘Microsoft Dynamics CRM’ entry at the top of the left pane of the window shown.
- Click ‘Properties’.
- Select the ‘Web Address’ tab on the dialog which is shown.
- Modify the addresses appropriately. E.g. change your port from 80 to 5555 ([YourServer]:port). Note that if the binding type is modified from HTTP to HTTPS you will need to install the appropriate certificate into IIS as well.
- Click OK to close the dialog and close Microsoft Dynamics CRM Deployment Manager
Update the registry entry
Fourth, you’ll need to modify the necessary registry entries. Whereas Dawson only updated the ServerURL registry entry key with the new URL. You’ll need to modify the LocalSdkPort as well. The registry entry can be found at KEY_LOCAL_MACHINESOFTWAREMicrosoftMSCRM. Note that the key value should be of the form http(s)://<New URL>:<Port Number>/MSCRMServices.
Do not make mistakes in the value of the port. I had a Hexadecimal value of 50, which equals to 80. This had to be changed to a decimal value of 5555.
For those who paid attention, you’ll noticed that I had two HTTP bindings in IIS for my CRM website. Experience teaches us that this has only caused problems in the past. You can only have one HTTP and one HTTPS binding. If you have two HTTP bindings, choose one to keep and one to delete.
Dawson advised to restart the Microsoft Dynamics CRM Asynchronous Processing Service, or restart the server. Restarting the CRM Asynchronous Processing Service did not work for me and I’m not a big fan of restarting the server as I only do these as a last life saver. Doing an IISRESET comes before restarting the server. An IISRESET did the trick for me.
The error has disappeared and you can now visit the dashboard, without any annoying “Message from webpage” popping up.