Managing Dynamics 365 Solution Components and Configuration data

Previously I clarified when and how to use managed and unmanaged Solutions, and I would like to further elaborate on using Dynamics 365 solutions for deploying your customisations. Its also important to understand that the solution file whether it is managed or unmanaged may not include all configurations but will include the metadata that defines your customisations including the following;

When creating and exporting the Solution file you will also be given the option to export additional configurations such as;

Export System Settings – This option will copy the settings corresponding to the Dynamics 365 Administration System Settings area.

Entity Metadata -The Main Entity Settings if you wish to overwrite the given entity settings such as Audit and SiteMap options etc.

However the Solution zip file will not contain the following customisations, and thus should be regarded as configuration data when planning your solution releases. The components not included in Dynamics 365 Solution Files include the following;

• Business Units
• Users
• Teams
• Queues
• Goals
• Subjects
• Product Catalogue
• Document Templates
• SLA / Case Creation Rules
• Personal Views / Dashboards –
• Personal User Settings

Including these configurations in your solution releases requires either exporting the required configuration data from the corresponding entity. This can be achieved by using the export to excel functionality including in Dynamics 365 or by using Configuration Migration utility that it included in the Dynamics 365 SDK. Alternatively, you can run a data load / integration job but this may require setting up by the dba each time such a customisation is made and may not always be the best approach especially for small configuration packets.

Maintaining Guids

The Guid is the unique key value of the record, generally you should always allow the system to generate the guid for indexing purpose but for configuration data this can be an exception. The benefit of maintaining the GUID of configurations data across all your environments will ensure that the references are consistent and the like hood of workflow references breaking as well as custom code will be reduced. Since configuration data is part of your solution and is not customer data it will not have a bearing on indexing and will keep your environment variables and deployments consistent.

Export to Excel

The export to excel feature in Dynamics 365 is ideal for simple data structures such as lookups or configurations that do not many dependencies or relationships.

• Manually Export & Import Excel File, which is available from the entity record view ribbon and allows to filter the records for export.
• Guid is included in the first column which is initially hidden from the Excel view. You can map this first column to the corresponding lookup field when you want to maintain the original guid.
• Ability to create mappings File in Dynamics 365 for regular imports
• Limited to first 100000 records or 10,000 for pre crm 2015
• Ideal for simple records with little or no relationship dependencies

Configuration Migration Tool

The configuration was made for the very reason of shipping configuration data for solutions, especially when you have a lot of configuration data with many dependencies and relationships the configuration migration tool is here to the rescue. Its Included in the Dynamics 365 SDK or Nuget package download Tools folder $\devtools\Tools\ConfigurationMigration

• Creates Data Schema and XML which is great to use when there are complex relationships involved
• Keeps Same GUID as Source, useful for deployment and dependencies
• Simple to use

Limitations

• Limited to config data, Struggles with large Data Sets and does not support full database migrations.
• Only works if Schema is exactly the same Schema between environments, so if you have an extra field in the target solution the configuration migration tool will not work.
• Includes all records for given entity, which means you cannot isolate specific record conditions as you can with export to excel.
• Also Copies Root Business Unit, which means you will have to overwrite the XML in the Configuration Data package

Migrating Business Units and Teams is possible whilst maintain the original Guids with Configuration Migration utility, however you will need to replace the existing Root Node Business Unit Guid with the Target BU guid so that it does not create a duplicate and references the existing Target Root BU. This can be achieved by performing a ‘find and replace’ on the root business unit in the XML and replacing its guid with value that exists in the target.

Migrating Personal Views & Dashboards

Only system views and Dashboards are included in the solution, sometimes there may be a requirement to build personalised views and dashboards that are only accessible for a given team or group of users. Migrating Personal Views Requires impersonating the Users involved in order to access the User Tables to retrieve the personal View records, and create the personal view records for the corresponding users. In order to Migrate the Personal Views from one deployment to another the Personal View need to first be Shared with the Administrator, as personal view are not by default accessible to the administrator in Dynamics 365, only the user who created the personal view, as they could be millions of personal views within the system. Once its shared to the administrator responsible for the deployment you can use several approaches to transfer the views, but I personally find using the XRMToolbox the easiest way to migrate personal view from on environment to another. The XRMToolBox provides a utility to migrate personal Views, which is far simpler than trying to use a a Data Migration https://www.xrmtoolbox.com/plugins/Carfup.XTBPlugins.PersonalViewsMigration

Solution Package Deployer

The Package Deployer provides the ability to create a solution package that contains multiple solutions as well as configuration data and custom code. The Solution Package template is provided in the Dynamics 365 SDK and Nuget packages, and allows you to include your configuration data in your solution deployments as well as a user guided interface to provide a more user friendly approach to deploying multiple solutions package. The Solution packager can only be built and configured with Visual Studio, and full instructions on how to build a solution package are included in the following instructions https://msdn.microsoft.com/en-gb/library/dn688182.aspx

Once you have built the Solution Package dll in Visual Studio you will need to run the Package Deployer to execute it, and you will need to share the full package deployer files to your users in order to execute the dll.

• Installs multiple solutions in the correct order
• Imports data from CSV or Configurations Migration package
• Allows to provide customises html pages for user guided friendly deployments
• Provides the ability to execute custom post deployment scripts required for custom web services or SQL or SSIS packages

There are also alternatives to the Configuration Migration that do not require Visual Studio and use Json to execute multiple Solution Imports and Config data

• Lucas Alexander – https://github.com/lucasalexander/AlexanderDevelopment.CrmDeploymentWizard/releases
• https://github.com/lucasalexander/AlexanderDevelopment.ConfigDataMover/releases/tag/v1.11.0.1
• David Yack – https://github.com/davidyack/CRMEasyPackageDeploy

You may also be interested in reading my related articles on Dynamics 365 Solution Release management articles;

http://www.crmconsultants.co.uk/managed-vs-unmanaged-solutions/

http://www.crmconsultants.co.uk/improving-release-management-with-solutions-in-dynamics-crm-2016/

http://www.crmconsultants.co.uk/crm-release-management-best-practices-at-crmug-reading/