When a Patch to Microsoft Dynamics 365 can break your instance


“When you come to the end of your rope, tie a knot and hang on.” — Franklin D. Roosevelt

We had problems importing solutions in a sandbox instances for Microsoft Dynamics 365. It was because different instances having different versions of Microsoft Dynamics 365. This article looks at the potential problems of patches.


We have been upgrading customisations to make them Microsoft Dynamics 365 version 10 compliant and removing the customisations which are depreciated in Microsoft Dynamics 365 version 9.

You can find a list of the important changes and what’s depreciated here:


There can be confusion about what you need to update with new versions. Microsoft supports the last 2 releases: Microsoft Dynamics 365 version 8 and Microsoft Dynamics 365 version 9. Customisations are depreciated in Microsoft Dynamics 365 version 9; they will still work in the current version, but it means you can’t use them in Microsoft Dynamics 365 version 10.

An example if the client api is depreciated


Now need to get the FormContext


so before you would have done this

var firstName = Xrm.Page.getAttribute(“hosk”).getValue();

now you need to do this

var formContext = executionContext.getFormContext();

var firstName = formContext.getAttribute(“hosk”).getValue();

You can make the change now but you only HAVE to make this change when you are using Microsoft Dynamics 365 version 10.


The Capgemini Dynamics team store customisations in source control, this allows us to create solutions and deploy them into new environments (we can create an environment and deploy all customisations with a click of a button). We can see the changes in Microsoft Dynamics 365 customisations.

We compare the xml changes of forms, views, JavaScript and all customisations. This week we noticed in the last patch Microsoft added a new section and JavaScript to the contact entity.

This raised the following questions:

1. Should this change happen in a patch release?

2. With Microsoft’s new direction of making all customisations as solutions, wouldn’t this functionality be optional?

3. What functionality could Icebreakers be? Would Microsoft suggest Icebreakers or you store them for each contact?

4. Patches are not meant to break functionality


A new section added to the form which could confuse testers and users, but it breaks the deployment because it added a dependency to new internal solution added.

We got an error about missing dependency to “Icebreaker  solution and msdyn_talkingpointsloader.js web resource during deployment testing on a separate tenant. The sandbox instances were upgraded with the latest patch, while extracting the latest changes, the section changes with some web resources and controls, adding dependency to “Icebreaker” solution.

Dev instance is version

Test instance is version

Between– (DB version) this solution and dependency was added, making it difficult to use multiple tenants because Microsoft controls when patches are installed. You can get into a situation where some of your instances have had a patch applied whilst you are waiting for Microsoft to apply patches for others.

When we put code into source control and include Microsoft’s changes, we then cannot install these solutions into the instances which have not had the patch applied.

Here is the Unhandled Exception:

System.ServiceModel.FaultException`1[[Microsoft.Xrm.Sdk.OrganizationServiceFault, Microsoft.Xrm.Sdk, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35]]: The action was failed after 0 times of retry. InnerException is: Microsoft.Crm.Tools.ImportExportPublish.ImportSolutionException: Solution manifest import: FAILURE — -> Microsoft.Crm.Tools.ImportExportPublish.ImportSolutionException: Solution manifest import: FAILURE — -> Microsoft.Crm.CrmException: The following solution cannot be imported: feature_Customisations. Some dependencies are missing. The missing dependencies are : ><Required key=”1510″ type=”66″ schemaName=”MscrmControls.TalkingPointsControl.TalkingPoints” displayName=”MscrmControls.TalkingPointsControl.TalkingPoints” solution=”Icebreakers (” /><Dependent key=”125″ type=”60″ displayName=”Contact” parentDisplayName=”Person” id=”{1fed44d1-ae68–4a41-bd2b-f13acac4acfa}” /></MissingDependency><MissingDependency><Required key=”1536″ type=”61″ schemaName=”msdyn_talkingpointsloader.js” displayName=”msdyn_talkingpointsloader.js” solution=”Icebreakers (” /><Dependent key=”125″ type=”60″ displayName=”Contact” parentDisplayName=”Person” id=”{1fed44d1-ae68–4a41-bd2b-f13acac4acfa}” /></MissingDependency></MissingDependencies>


You only have a few days’ notice and you have no ability to control when patches are applied. Some Dynamics instances were on one version and the others instances waiting for the patch to be applied. This can create solutions which can’t be imported into some of your instances. You must monitor when patches will be applied and check if all your instances have had the patch applied.

The documentation surrounding patches is sparse and there can be significant changes. There is a risk of a patch breaking customisations in production — with a small time to test, how do you mitigate this problem? If Microsoft gave a detailed list of the changes it would help to risk assess the patch.

When I worked on projects using Microsoft Dynamics CRM on premise, the best practice was to never take the latest patch but install the patch before that. This way you could buffer yourself from Microsoft breaking Microsoft Dynamics. I wrote a blog post on it Should you keep up with Microsoft Dynamics CRM release cycle?

Microsoft could implement the latest patch to be a beta version and make it operational or move to a monthly release schedule.

In the past when patches broke production, the infamous patch of Microsoft Dynamics CRM 2011 patch 12 — where Microsoft changed how JavaScript worked and broke many instances. I discuss it CRM 2011 — Things learnt when reviewing Javascript code on form loads


Most of the times patches come and go, fix bugs and no one notices. It’s good that Microsoft regularly fixes bugs — that benefits its users. If Microsoft could improve its documentation, give more warning and make significant changes in more significant patch numbers this would resolve many of the problems. This is the online service world we live in and it’s a more exciting way of living.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.