Microsoft Dynamics 365 Solutions and Patches Best Practices

This is my 3rd blog in my 12 part series that talks about Microsoft Dynamics 365 Best Practices. My first blog focused on defining the term “Best Practice” in relation to Dynamics 365. This blog focuses on Dynamics 365 Solutions and Patches Best Practices. All future blogs, will focus on Best Practices surrounding different configuration topics relating to Dynamics 365.

Back in version 2011, the concept of Solutions and publishers was introduced in Dynamics CRM. Solutions allow you to package your configurations into one tidy “bucket” and move them between different organizations. I’m going to cover some best practices that you can use when managing and working with solutions in your organizations.

Dynamics 365 Organizations

How many organizations do you have? If you have two organizations, a Sandbox and a Production instance, then you should use Unmanaged Solutions. If you have three organizations, two Sandboxes and a Production instance, then you should use Managed Solutions.

In a two organization environment, your Sandbox is your development (DEV) org and your Production is your production (PROD) org. You will build your solution and patches in DEV, export them as unmanaged solutions, and import them into PROD.

In a three organization environment, one of your Sandboxes is your development (DEV) org, the other Sandbox is your user acceptance testing (UAT) or quality assurance (QA) org, and your Production is your production (PROD) org. You will build your solution and patches in DEV, export them as managed solutions, import them into UAT/QA first and after testing is complete, import them into PROD.

A three organization environment is ideal. If you’ve ever used unmanaged solutions to deploy configuration changes to Production, then you know that it’s difficult to “undo” those changes without manually deleting and/or updating each component that was part of the solution. Using managed solutions allows you to easily delete the solution, which will undo the changes that were made when the solution was installed and put the organization back to the state it was in prior to the solution being installed.

Backup

First things first! It’s import to keep a backup of your default solution before making any changes. It’s very difficult to “undo” changes in an unmanaged solution. Whether you have a 2 or 3 organization structure, you are always going to be working with an unmanaged solution in DEV.

Don’t worry though, if you forget to export the Default solution, Microsoft does perform regular backups of your orgs. You can restore your DEV org to a previous restore point if needed.

Publishers

You’ll want to create a publisher and assign it a prefix (other than new_). When you specify your own prefix, you’ll get a unique option value prefix as well. This will prevent conflicts with any other solutions you may install from other vendors as well as any Microsoft updates that use the default new_ prefix with the default option value prefix of 10,000. Once you create a publisher, add this publisher to your base solution.

Base Solution

After you create your organizations and your publisher, you can start having fun and configuring your system. Create your solution in your DEV org. Give it a simple name such as “ABC Customizations” where ABC is also the custom prefix of your publisher, select your publisher, and enter your version number.

Versioning is important as it will come into play when you start working with patches. We recommend using a version number such as 9.0.0.030119 where 9 represents the Dynamics release, the first 0 represents the publisher release (your release number), the second 0 represents the patch version, and 030119 represents the release date. In this example, this is the first solution created for a new org in D365 v9.

Always work in your solution. Try not to make configuration changes on the fly where you’re on the Account form and you customize the form using the button in the command bar. If you add a new field this way two things will happen. First, the field will have the new_ prefix and second, the new field will not be part of your solution.

Adding Components

When adding components to your solution, only add the necessary components. Don’t junk up your solution with items that aren’t needed. When you’re adding entities, you’ll see two checkboxes in the upper right-hand corner. Unless you’ve changed the entity options, you don’t need to include the Entity Metadata and you almost NEVER want to include All Assets when adding an existing entity to a solution. If you create a new entity then the metadata and all assets will be included, but this is expected since it’s a new entity.

If you follow a strict deployment structure, then you will never need to add “required components” to your solution as those components will already be in your source system. You should review the list to make sure you didn’t miss anything but you should select the option to not add these components to your solution. If you see something on the list that you missed, add it manually after selecting to not add the components to your solution.

When you’re ready, export your solution as unmanaged or managed. You shouldn’t need to include any of the settings unless you have a specific reason to do so. Once exported, you can then import the zip file into your PROD or UAT/QA org.

Patches

Depending on how many changes you needed to make, your base solution could get pretty large. Going forward, when you need to make additional configuration changes, you’ll want to use Patches.

From your Solutions list, select your ABC Customizations solution and click Clone a Patch. Give your patch a meaningful Display Name. If your changes link back to a support ticket, then you can use that as your Display Name with a brief description. You want to make the Display Name something meaningful other than the default of ABC Customizations. You’ll notice that you can’t change the first or second number in the Version Number. This is by design. The third number will automatically increment for each patch you create and there is no reason to change this. You’ll want to change the last number to the current date. This will give you instant visibility as to when each patch was built and/or deployed.

Continue to Clone a Patch from your base solution as-needed to make your configuration changes. Patches take much less time to deploy than the full-blown solution. Patches can be deployed out of sequence as well, as long as all of the components required are in the patch and/or in the target organization. This is a nice feature as you could be working on two different patches and get done with the newer one first but you won’t have to wait for the first one to be deployed to deploy the changes in the second patch.

Clone Solution

Anytime a major update occurs you should clone your solution and change the first number of the version. Remember that the first number represents the Dynamics release. When you clone a patch, you’re able to change the last two numbers. When you use Clone Solution, you’re able to change the first two numbers. The second number will increment automatically, similar to how the third number increments with patches, and it’s best not to change that number. The first number should be changed to match the Dynamics version number. In the example, 9.0.0.030119, the solution was built in version 9. When there is an upgrade to version 10, you’ll want to use Clone Solution and change the version to 10.1.0.010120.

During your testing in DEV, you’ll want to use the newly created solution to make any necessary changes. When your PROD org is upgraded to the new version, you can then deploy your full solution from DEV to PROD and both orgs will be in sync with your customizations.

Wrap Up

This may seem like an overload of information, but once you start using patches and deploying them, it will become second-nature. The speed in which you can deploy a simple patch is fractions less than deploying a full solution. A solution is simply a bucket of configuration items that allows you to transport changes from one org to another. The more items you have in your solution/patch, the longer it will take to export and import.

Contact Us!

Please contact us today if you have questions about Microsoft Dynamics 365 Solutions and Patches Best Practices or if you have a topic or certain Dynamics 365 component that you are particularly interested in hearing about in regards to its Best Practices. If your unmanaged solutions are out of control, don’t worry!  We can help you with that too.

Beringer Technology Group, a leading Microsoft Gold Certified Partner specializing in Microsoft Dynamics 365, CRM for Distribution, Office 365,  Managed IT Services, Backup and Disaster Recovery, Cloud and Unified Communication Solutions.