Microsoft dynamics 365 Patch#
We recommend using a version number such as 9.19 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. Versioning is important as it will come into play when you start working with patches. 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. Base SolutionĪfter you create your organizations and your publisher, you can start having fun and configuring your system. Once you create a publisher, add this publisher to your base solution.
Microsoft dynamics 365 install#
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. When you specify your own prefix, you’ll get a unique option value prefix as well. You’ll want to create a publisher and assign it a prefix (other than new_). You can restore your DEV org to a previous restore point if needed. Whether you have a 2 or 3 organization structure, you are always going to be working with an unmanaged solution in DEV.ĭon’t worry though, if you forget to export the Default solution, Microsoft does perform regular backups of your orgs. It’s very difficult to “undo” changes in an unmanaged solution. Backupįirst things first! It’s import to keep a backup of your default solution before making any changes.
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.
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. 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.Ī three organization environment is ideal.
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 unmanaged solutions, and import them into PROD.
In a two organization environment, your Sandbox is your development (DEV) org and your Production is your production (PROD) org. If you have three organizations, two Sandboxes and a Production instance, then you should use Managed Solutions. How many organizations do you have? If you have two organizations, a Sandbox and a Production instance, then you should use Unmanaged Solutions. I’m going to cover some best practices that you can use when managing and working with solutions in your organizations. Solutions allow you to package your configurations into one tidy “bucket” and move them between different organizations. All future blogs, will focus on Best Practices surrounding different configuration topics relating to Dynamics 365.īack in version 2011, the concept of Solutions and publishers was introduced in Dynamics CRM. This blog focuses on Dynamics 365 Solutions and Patches Best Practices. My first blog focused on defining the term "Best Practice" in relation to Dynamics 365.
Microsoft dynamics 365 series#
This is my 3rd blog in my 12 part series that talks about Microsoft Dynamics 365 Best Practices.