Share via

Managed Solution Replacement in Microsoft Dynamics CRM 2011

  • Article

Microsoft Dynamics CRM 2011 introduced the concept of solution management—packaging your customizations so they could easily be deployed to other environments. In CRM 2011, there are two types of solutions: Managed solutions, which prevent the solution from being modified in the environment to which it is imported, and unmanaged solutions, which allow for the solution to be modified after it is imported.

I typically recommends that users deploying internal customization changes should do so using unmanaged solutions. Managed solutions are great for Independent Software Vendors (ISV’s) who are selling their intellectual property and don’t want it to be modified by their customers, but for internal customization of your base CRM solution, managed solutions can cause some challenges. Even in highly secure environments, there are typically some level of customization changes that need to be made in a CRM production environment, such as view, chart, and dashboard changes. Also, maintaining a managed solution requires that you preserve an unmanaged copy of that solution somewhere, since that is the only way you can update the solution or delete components.

For these reasons, I recommend that most CRM environments use unmanaged solutions for their internal base customizations.

So what do you do if you configured your CRM base solution as a managed solution and you want to change it to an unmanaged version?

There are a couple of different options you could potentially choose in order to deal with this type of scenario. The option we will explore is the option of deleting the managed solution, and then reimporting an unmanaged version of the same components. This option assumes you have a separate development environment used to build the customizations where the unmanaged solution can be obtained. While every environment and situation will obviously contain its own unique characteristics, the following outline should be a helpful guide.

The removal of a Managed solution will do three things:

  • Removes all custom entities and components contained within the solution
    • i.e. entities, web resources, processes
  • Removes all customizations to system entities contained within the solution
    • i.e. fields, views
  • Deletes the data that is held within these custom entities and fields

We can now begin to plan how to rebuild our managed environment as unmanaged.

Administrative User Setup

Before beginning the process, you will want to create a new CRM administrative user in your CRM Production environment. This user will be the user account that you use to reimport the data. Log in as the user and set the user’s timezone settings to GMT/UAT.

The reason we want to set up a user with a timezone of GMT is because that is the base timezone for CRM. By reading the CRM data backup as this user and writing data to CRM as this user, all CRM time values will remain correct. Several years ago the date when Daylight Savings Time starts and ends in the US was changed. As a result, if you import the data back in for previous years as a user that is not on GMT, some of the records will be off by an hour.

Data Preservation

Back up your production MSCRM database and restore to SQL Server under a different name. This is the database that we will use to reload data into our custom fields and entities.

Solution Replacement

Before you can successfully delete the managed solution, you will need to remove any dependencies between the system and the components within your solution. This can include fields on forms, nav bar links on forms, or processes involving customized components. When attempting to delete a managed solution, you will be presented with a list of all dependencies tied to the solution. Using this list is the best way to determine what changes to make to your system in order to have a successful deletion. Once all of the dependencies have been removed, publish all customizations and delete the managed solution.

We strongly recommend that you attempt this first in a copy of your production environment prior to doing it in production.

You can now import the same solution, only unmanaged, to restore all customizations.

Notes

  • Any personal views/charts/dashboards in any custom entities will be lost in the solution replacement
  • When you reimport the solution, custom entity object type codes will change in the database. If you have any reports or custom development that calls records using the OTC, this may break them. If this applies to you, I recommend updating your code to call hyperlinks using the entity name rather than OTC. See the CRM SDK for more details.
  • When you reimport the solution, you may find that some processes, such as workflows, cannot be published. This can happen because they reference a record that does not exist (because the data was deleted). Update these workflows after importing the data to fix any broken links, then re-publish.

Data Replacement

You can now reimport the data to the custom entities and custom fields. We recommend using SSIS with the Kingswaysoft adapter, or Scribe Insight.

The reason we recommend using one of these tools is because both will automatically map the fields from source to target, so it makes it very easy to reimport the records.

Notes :

  • Use your restored backup as your source and map to the environment where the solution was replaced
  • identify which entities include custom fields
  • Identify dependencies—which entities need to be imported before others. If you have a relationship between two entities, and one includes a lookup field to the other, you need to import these entities in the correct order.
    • In some cases, you have many relationships, and you cannot practically determine the order in which they should be imported. In this case, do a two-pass operation. First, import just the base fields, such as ID, name, owner, transactioncurrency (if applicable). Then, when all entities have been imported, do a second pass populating all of the other fields
  • Be sure that you map the record ID/GUID fields when the records are created—if you don’t do this, your job will be much harder. If you map the GUID fields, all relationships will work when imported.
  • Be sure that you map createdon to overriddencreatedon. You can only populate this when the record is created, and this is what will set the created on date for the record to match the original version.
  • There are a handful of fields that you do not want to map, such as version number, import sequence.
  • There are several fields that you cannot import—you cannot overwrite modified by, created by, modified on.** **
  • Custom data cannot be reimported for closed opportunities. This should be taken into consideration when following this approach.
  • By taking this approach, you should not have to reimport activities or activity parties, as these are system entities. However, if you have activities or notes where the regarding object is a custom entity, you will need to update the regardingobjectid on those entities and change the regardingobjectidtypecode to the new OTC for the entity. Some activity entities allow you to update regarding object on closed activities. For example, e-mail, appointment, and note all allow you to update regarding on a closed activity; however, task does not. In that case you will need to change the status of the task to open, update regarding object, then close the task.

Verification

Once the solution replacement is finished, you will want to verify that the solution replacement and the data load were successful. I recommend the following checks

  • SQL row counts—verify that every affected entity has the same number of rows as the backup database contains.
  • SQL data values—compare the data values between the backup database and the production MSCRM database to verify that values match. I recommend Redgate Software SQL Data Compare. It will quickly compare tables or views between two databases and identify where things are different.

Note some differences are expected, and redgate will allow you to exclude specific columns. For example, with multi-currency deployments, frequently the base currency field values will be different. This is how CRM works with exchange rates. For example, when I create a record, the base money fields are populated with the current base currency values, based on the current exchange rate; however, if I reimport those records and the exchange rate has been changed, the value in the base currency fields will be different; however, the value in the currency field will match.

  • CRM UI comparison—I recommend importing a copy of your backup database into a CRM environment and comparing several things inside the user interface with the production environment post solution replacement:
    • Verify that all custom forms behave the way they did before—check creating, updating, and saving a record
    • Verify security role assignments—if your solution includes security roles, when you remove the solution, the roles will get de-linked from the users to which they are assigned. Reimporting the unmanaged version of the solution will restore the security roles, but it will not re-link them to the appropriate users. By restoring a backup of your CRM environment, you can run the user summary report from each environment and compare and update the production environment appropriately
    • Verify duplicate detection rules and audit settings. When you reimport the solution, auditing will be disabled and duplicate detection rules will be unpublished. Compare your environment with the restored backup CRM environment and set duplicate detection and auditing to match.
    • Verify processes—compare the list of active workflows and dialogs in your environment with the backup environment—see if there are any unpublished that were published pre-solution replacement and publish them. Also see if there were any user-owned processes that were not defined in the solution, and import them if they are missing.