Problems with Microsoft Dynamics 365 patches

“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.

Upgrading

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

Xrm.Page

Now need to get the FormContext

executionContext.getFormContext();

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.

Patches

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

Problems

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 9.0.2.54–9.0.2.189 (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.

Solutions

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.

Conclusion

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.