The solution that didn’t want to be installed, but ended up being installed!

Aaaargh, what a day! Today I was wrapping up the setup of an on-premise Dynamics CRM 2016 (Update 1) testing environment for a client. One of the last tasks I had to do was to update the unmanaged solution we developed on Dynamics CRM 2016 online.
Whatever I tried, the solution didn’t want to be installed on the on-premise environment. The import log didn’t show any error, just some items that were unprocessed.


Whatever I tried no luck, I was able to install some parts of the solution, but other parts refused to be installed. I was lost!

Then a collegue pointed me on a server sided feature called: Server Level Tracing.

Server Level Tracing is a feature that can be activated on the Dynamics CRM on-premise versions by adding two registry values on the server to HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\MSCRM.

  • TraceEnabled
    DWORD (32–bit)
    0 (disable) or 1 (enable)
  • TraceRefresh 
    DWORD (32–bit)
    value between 0 and 99 (This value must change for Microsoft Dynamics 365 to detect a change to any of the other trace values in the Windows registry)


I created the registry keys and restarted the server. Once up and running again, I decided to start the import again. The result was the same (import failed, no clues in the import log file).

Then I initiated a remote desktop session with the CRM server, opened the C:\Program Files\Microsoft Dynamics CRM\Trace folder and found a large number of trace files.


I noticed that a number of files had a size of 0 bytes and I noticed a couple of files with a large size. I decided to open the largest one and scrolled down to the bottom, scanning for the word “Exception”.


There it was “Crm Exception: Message: The language code 1043 is not a valid language for this organization, Errorcode……”. *WUT!*

This confused me, I’m running on a server with only the 1033 language in place (US english), the solution I had, contained multiple languages (English, Dutch, French, German, Chinese).
I was in the blind assumption that when I have one of the languages as the base language on the server I would be able to import the solution.  You also know what people say about assumptions:

An assumption is the mother of all ****ups!

The only thing I could do was to open the customizations xml and remote all foreign language references from the solution file. Notepad++ turned out to be my lifeguard, as I could do a couple of simple regex expressions to find the languages I wanted to remove, e.g.

<.* languagecode=”1043” />

I also cleaned up the <languages> section in the bottom of the customizations.xml, then I saved the file and placed it back in the solution file. The next attempt importing the solution succeeded.

Mission Accomplished!

My tip of the day:
In case you get stuck when importing a solution, do check if the CRM server supports all languages specified in the solution. If you are missing languages you can either install the missing language packs or remove the language elements from the solution.