Dynamics 365/CRM

Installing Dynamics 365 Customer Engagement v9 On Premise

This post was originally published on this site.

Microsoft Dynamics 365 Customer Engagement v9 has been available On Premise for some time now, I believe it is since February-March sometime (Q1 timeline?). I haven’t been able to fiddle with it until very recently and it was actually the first time in 3 versions where there were considerable issues during the installation, which was sort of a disappointment.

This was published on CRM-Konsulterna’s blog but I keep it here as well to be able to search it myself.
To begin with, all of us having installed Dynamics CRM/365 Customer Engagement since different amounts of ”way back when” have gotten used to a HUGE amount of versions of different software that is compatible or soon-to-be-compatible or even used-to-be-compatible-but-not-since-rollup-8. This is now a thing of the past for good or bad, well at least the first two, I can’t really say that there will be software that won’t be supported as updates come.

For Microsoft Dynamics 365 Customer Engagement v9 On premise the list is very short. It’s Windows Server 2016 Standard or Data Center and SQL Server 2017 or SQL Server 2016 SP2 standard or enterprise (or developer for dev purpose). That’s it.
The entire list can be found here https://docs.microsoft.com/en-us/dynamics365/customer-engagement/on-premises/software-requirements-for-microsoft-dynamics-365-server

This means that we almost certainly can forget about in place upgrade of the production instance since the current system almost certainly doesn’t run on these versions.

The issues I’ve had installing v9 On Premise so far are two during the installation phase:
The first and most severe in my humble opinion is that you can’t install CE using anything but Latin1_General_Cl_Al (or possibly *_CI_AI) SQL collation, which is bad in my neck of the woods since Finnish_Swedish_CI_AS is the one that makes data order correctly for us.

Not only can’t you install and set up a new organization with anything but Latin1, you can’t upgrade an existing organization with anything but Latin1. I might be painting rather broadly saying ”anything” since I’ve only used Finnish_Swedish, but from searching the web this is what most people say.

When I’ve been trying to create or update and organization with Swedish_Finnish collation, not only does the installation/update fail, you also get an error message which is so long you can’t see the end of it and click whatever button might be available at the bottom.

In the CRM server logs, the error message is this:

Create new Organization (Name=0728c85d-0b6b-e911-841d-00155d02e70f, Id=test0430) failed with Exception:
System.Exception: Error.ActionFailed Microsoft.Crm.Tools.Admin.SetDatabaseCollationAction —> System.Data.SqlClient.SqlException: The statistics ’Attribute.ndx_Attribute_EntityId_ColumnNumber’ is dependent on database collation. The database collation cannot be changed if a schema-bound object depends on it. Remove the dependencies on the database collation and then retry the operation.
The object ’fn_CollectForCascadeShare’ is dependent on database collation. The database collation cannot be changed if a schema-bound object depends on it. Remove the dependencies on the database collation and then retry the operation.
The object ’fn_CollectForCascadeUnShare’ is dependent on database collation. The database collation cannot be changed if a schema-bound object depends on it. Remove the dependencies on the database collation and then retry the operation.
ALTER DATABASE failed. The default collation of database ’test0430_MSCRM’ cannot be set to Finnish_Swedish_CI_AS.

I really don’t know where in the database these objects reside but somehow they are very hard linked to the collation.

Issue number two is that reports aren’t working after the installation. I’ve heard that people are having issues installing the SRS. I haven’t had no such issue, but the reports weren’t working when I was done.

Now, there is an update available from Microsoft with version number which, according to discussions, I’ve seen should address reporting issues and collation problems.
I don’t know if the update has been hidden since I couldn’t find it earlier but was pointed to it on Microsoft’s partner forums. Here’s a page of available updates though. The 9.0.3 can be found as well as other updates: https://support.microsoft.com/en-gb/help/3142345/microsoft-dynamics-365-onpremise-cumulative-updates.

Unfortunately, this doesn’t solve the issue with collation and I’ve yet to see a solution for this so all you who are running 8.2 with Finnish_Swedish collation, I don’t think you can upgrade just yet.

After I installed the server, I encountered one more issue and that was user creation. I was totally unable to create any users. The error message I got was: ”Assembly Microsoft.Dynamics.Service.Plugins.dll can not be loaded.”. Asking away at one of my favourite go-to-places for weird-shit-happening-in-Cr…EEeeh…Microsoft Dynamics 365 Customer Engagement, the Community at Microsoft (in this case https://community.dynamics.com/crm/f/117/t/316849), I got an answer as you can see in the thread which I at first disregarded – as you can see – but then thought I might have a look anyway. So, not the answer per se but a nudge in a direction at least.
The file was present in the directory but why on earth can’t it be loaded?

Having no idea really what’s needed system-wise to be able to use the assembly folder and seeing that the permissions set for the async and sandbox service accounts match that of earlier versions, I cranked it to 11 setting “everyone can do anything” in that folder.
This did the trick. I can now create users in a system which isn’t behaving how I want it to do considering the collation isn’t what I want. I think that it’s probably not the greatest of ideas to have this security setting in that folder but I don’t know how to set it more restricted and still be able to use the system.
 The assembly folder isn’t something I’ve used since…. well… ages. I’ve used it for debugging some stuff since it was easier to place the dll there when it wasn’t behaving but after the introduction of solution in CRM 2011 the database is the place to have plugin code. Now it seems that Microsoft are starting to use the assembly folder for internal stuff, probably since it’s easier to do so in respect to the application not being a monolith any longer but that’s speculation on my side. What’s annoying is that the permissions aren’t set properly.

Rickard Norström
Developer at CRM-Konsulterna

Kontakta oss med dina frågor!

Känner du dig osäker eller är du redo att komma igång? Kontakta oss så svarar vi på alla frågor eller föreslår ett uppstartsmöte där vi går igenom era behov.