Choose your path Increase your proficiency with the Dynamics 365 applications that you already use and learn more about the apps that interest you. Up your game with a learning path tailored to today's Dynamics 365 masterminds and designed to prepare you for industry-recognized Microsoft certifications.
Visit Microsoft Learn
2020 release wave 1Discover the latest updates and new features to Dynamics 365 planned through September 2020
Release overview guides and videos Release Plan | Preview 2020 Release Wave 1 TimelineWatch the 2020 Release Wave 1 virtual launch event
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Upcoming TechTalks
Having waited so long to get my hands on CRM V9 On-Premise, I was frustrated to encounter problems doing a clean install.I don't know if this is bad luck on my part or a repeatable problem, but this is what I encountered during my install attempts.Coming from the UK we normally use the SQL Collation Latin1_General_CI_AS (similar to DOCI). This isn't the default as far as CRM is concerned, the product ships with the default collation Latin1_General_CI_AI. And if you install V9 without changing this... it installs just fine.
However, if you change the default collation (to match your SQL Server) the installation crashes with a Collation Change failure on scripts creating foreign keys etc.
Has anybody else encountered this problem?I was using the EXE install rather than an ISO image
Do you already find any solution ? We have the same issue... :(
Many thanks for confirming the same behaviours that I encountered. At least I know its not my setup, or me doing something wrong.
Looks like the installation scripts themselves are at fault, which is disappointing given this is V9 and not V1.
As for a remedy, I don't want to waste valuable time trying to fix the install package itself, but I am going to trying something to see how deep rooted the problem is.
The initial install of V9 was for my test tenant called "Sandbox". I'm going to install another tenant over the weekend using the deployment manager to see if that root has the same issues, and I'll post my feedback here.
Before we can role this out to our customer base MS are going to need to resolve these issues, hopefully in a timely manor.
Yes, same issue here, I also normally set it to CI_AS (for South Africa) ordering etc. and the setup failed. I rolled-back and did a fresh "Install" instance with Setup defaults (not my defaults) and it worked.
The error from before was also the size of the entire screen (higher than 1440px) so I could not even click on Cancel / Ignore / Exit...
I think this is rushed job from Microsoft as they were running out of time to publish this and keep their on-premise customers happy.
I have not tried to do the upgrade from 8.2.2 org yet... Good luck
Thanks everyone for the feedback.
I did use the Deployment Manager over the weekend to add a second instance, and I can confirm the collation bug exists via that method also.
To add insult to injury the MSCRM_CONFIG database does get created with the correct collation, it's just the organisational tenant that errors with a huge script error.
I'm always amazed how this wasn't picked up during testing, unless it wasn't!
I hope this gets fixed quickly as we now have V9 and lots of work pilling up and we can't use it. I would rather it was late and worked, than being on-time and useless.
We encoured the same problem during the creation of a new organization. For this particular issue we've contacted Microsoft (premier support). At the moment they are evaluating the issue. When they provide the solution, I'll get back.
Many thanks for the heads up on this. We've decided to install with the CRM default collation rather than the SQL default collation, as we had work stacking up. Hopefully when the installer is fixed we can re-install and return everything back to normal.
Talking of broken installers, we've also detected a problem with adding users to a V9 on-premise install. Apparently the installer forgets to add inheritance to folder permissions in the CRMweb which causes an error when adding new users. There is a post with a solution that's easy to find and fixes the problem (after a reboot).
Let me clarify. The issue is not the installer but the tooling which creates an organization. A default organization will be created automatically when installing Dynamics 365 with a full server configuration. That's why you are getting the error.
You can install Dynamics 365 v9 without a default organization and create one afterwards. However the Latin1_General_CI_AI collation is the only one without errors.
Keep you posted.
17:30:47| Info| OrganizationCollation Latin1_General_CI_AS selected from UI page...17:30:50| Info| OrganizationInfo.OrganizationCollation: Latin1_General_CI_AS...17:30:50|Verbose| The supported collation 'Latin1_General_CI_AI' matches the language of the database's collation 'Latin1_General_CI_AS'17:30:50| Info| The case sensitivity of the database collation is correct.17:30:50| Info| The database collation is correct....17:31:07| Error| 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 '#####' cannot be set to Latin1_General_CI_AS.
Microsoft did indeed clarify, that it is a bug an that they are currently working on the fix. When this will be released is unknown
Thanks for the confirmation, since the initial on-premise release, news of V9 has been very quite.
PS. Has anybody been able to get licence keys to transition to V9, we've only been able to develop and test using a demo key, and they only last for 90 days!
I promised to send an update regarding the collation issue. Microsoft provided a bugfix which indeed fixed the problems we had. It consists of an updated mdf file which resides in the Languages\XRM\sql\9 folder.
I'm not sure if I'm allowed to share this file, but I will ask the Microsoft Manager. Keep you posted.
There is an iso available in the Volume License section, since two weeks. This contains a license.txt file.
Any updates on this? I'm facing this issue too. We're unable to upgrade an organization with collation finnish_swedish, or create new ones with that collation.
I'm also facing issues with user creation, some plugin assembly from MS is missing there.
Microsoft has made a bugfix for this particular issue and has corportated this in update 0.3 which is avalailable here.
Business Applications communities