onsdag 21 augusti 2019

How can I find which user is Deployment Administrator?

There’s always the interesting step when you get to handle an on premise CRM that someone else set up. The system was almost always set up a long time ago, which in this case means more than three years, and no one remembers or knows which account that was used to set up the system.
What you need to do very often requires you to be deployment administrator, a term which no one knows what it is in the IT department of the customer. That is the normal case.

So, how do you find out which account it is that has the deployment administrator right? The answer is the following query against the MSCRM_CONFIG database:


It seems that the “Name” column is populated with the account name of the account that is deployment administrator. I’ve had a look at a couple of systems available to me and it has been correct in all of them.

Rickard Norström
Developer at CRM-Konsulterna

tisdag 13 augusti 2019

Update of Microsoft Dynamics 365 Customer Engagement on premise version 9

Some water has flowed under the bridge since my last session with installing a Dynamics 365 
Customer Engagement on premise version 9 and my last attempt was sort of a disappointment.
Now Microsoft has released update 6 (version and it actutally seems as if the issues has been resolved. In June I installed the update 5 ( which sorted out some of the issues but there were a good number of strangeness left.

My memory is not quite with me at this time what I was struggling with but there were some missing dll:s if I remember correctly and they seemed to be coming from SQL Server 2014. I'm not quite sure of this so it might have been something else. That doesn't really matter because as of version I can create an organization with Finnish_Swedish collation and that was the last of the issues that has been present.

So to install a Microsoft Dynamics 365 Customer Engagement v9 on premise this is what you need.
* A Windows Server 2016 (standard or data center)
* A SQL Server 2016SP2 (standard or enterprise) or a SQL Server 2017 (if you have
* An Active Directory 2008 or later (this has actually not changed since.... 2010)
(full prereqs can be found on https://docs.microsoft.com/en-us/dynamics365/customer-engagement/on-premises/software-requirements-for-microsoft-dynamics-365-server)

Then you install the server software and set up a latin collation organization, since you can't do anything else on the vanilla version 9. After this, install (or later if applicable, this is written in August 2019). After you have done this you can create or upgrade your organizations running on Finnish_Swedish collation. This only took some 8 months to fix...

As for the SQL server 2017 requiring update 3, I have no idea atm how that should be done. Back in the days of CRM 2011 you could hotfix your installation media with the Update Rollup files but I don't know if that is something you can do now.

Anyway, we can finally use v9 on premise for other collations that latin.

One note on this, since I made some interesting security changes on the folder structure earlier I might test to do a clean installation sometime. Hopefully the issues I was facing earlier with the file security has been remedied as well.

Rickard Norström
Developer at CRM-Konsulterna

Installing Dynamics 365 Customer Engagement v9 On Premise

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