I am fairly new to dynamics and trying to get my head around the deployment process. Currently in my CRM2011 production instance, the previous developer have only one managed solution (eg test_1_0_0_0) installed. Now I want to make changes for a new version of that solution ie 'test_1_0_0_1'. What is considered best practice in terms of deployment? Currently the process is to delete the old one and import the new one.
I have a feeling that this process is bad since, previously the data was wiped out from the deletion of that managed solution.
Many thanks
You can read about solution management in MS Dynamics CRM here
In your case managed solution test_1_0_0_0 was imported to your CRM environment (let's call it environment (1) from some other CRM environment (2), where this solution is unmanaged and you are able to provide updates to the solution over there. After you complete your updates in environment (2), export the solution from environment (2) as managed and import in environment (1). It will be managed in environment (1). But you should not delete any previous versions of the solution. All necessary updates will be successfully applied, even version of the solution was not changed from 1_0_0_0 to 1_0_0_1.
Related
I am in the unfortunate situation of having lost the unmanaged solution for our production environment in Dynamics 365. What I do have is an export of the managed solution that I am able to inspect.
I had tried to manually modify the managed solution to be unmanaged by updating <Managed>1</Managed> to 0. However when importing this modified solution into the same environment, the import failed with the message
"unmanaged solution expects full formXml" (error code 0x8004023B)
It's worth noting that I was attempting to import the modified unmanaged solution into an environment where the managed equivalent was already installed and in-use. I am not sure if importing this manually unmanaged solution into a fresh environment would be successful.
Questions:
What are my options in recovering an unmanaged and editable solution from this exported managed solution?
If an unmanaged solution is able to be recovered and installed in Sandbox, will there by any issues in updating the managed solution in
Production?
Is it possibly to simply add on a new solution, dependent on the base managed solution, that would allow me to modify the base
solution? I am pretty sure I can add features to the base solution but
would not be able to change or remove any features of the base
solution.
Would importing this modified unmanaged solution into a fresh environment have a better chance of importing without error?
you might want to check out thi article on how to manipulate solutions via SDK. https://learn.microsoft.com/en-us/dynamics365/customerengagement/on-premises/developer/sample-work-solutions
You shuld be able to re-create the unmanage solution though this.
Use Solution Packager
(https://learn.microsoft.com/en-us/dynamics365/customerengagement/on-premises/developer/compress-extract-solution-file-solutionpackager)
to extract your solution as managed.
In extracted folder in file Other\Solution.xml change Managed to 0.
Use Solution Packager to pack your solution as unmanaged
(/packagetype:Unmanaged) Import it into development organization.
Verify that all your customizations are there and valid.
No guarantees but it should work. You might loose some managed changes for forms and sitemaps. Most probably you aren't using them.
Also please do organization backups before importing solutions into your organizations. Just in case something won't go as expected.
We are in the process of creating and publishing a managed solution built on CRM 2016 8.1. This solution is meant to be forward-compatible with 9.x, and we plan to publish it to AppSource.
We may need to migrate our Publisher from one instance of CRM 2016 8.1 to another, and expect to be able to publish and deploy to the AppSource afterwards.
However, after much research, I can't figure out if the Publisher itself is easily migrated.
Let's say in our original instance, instance A, we have exported a managed solution and published it to AppSource.
Now we want to migrate to instance B. We import the unmanaged solution into B, make changes, increment the version number, and export a new version of the managed solution. We now try to publish this as an upgrade to our existing solution in AppSource (or by means of distributing an upgraded managed package to our clients).
Will this work? Or is there something that ties our publisher record to that instance that we need to be aware of?
Publisher information and other solution identification is maintained in the solution and transfers to your target organization. So if you apply your unmanaged solution to another org, that publisher will now exist in the target system, and you should be able to then export an update to a third system.
That being said, I wouldn't be shocked if you ran into issues carrying out this operation. There are still quite a few gotchas lurking within the solution metadata.
I have some questions regarding the registering/updating of 3rd party plugins that were previously loaded via a managed solution by a 3rd party.
The issue we are having is that they(3rd party) sent us a plugin update and a new plugin outside of the Managed Solution and had us register it manually though the registration tool. Then, next time we tried to import a later version of their solution, the Managed solution import failed. We eventually realized that there where duplicate rows in the pluginassembly and pluginassemblytype table that had the same Pluginassemblyid and plugintypeid respectively with different solutionids.
These solutionids were "Active" which I assume came from the manual registration and "IPM Global" which is our 3rd Party Managed Solution. The only way we were successful in getting the solution to import was to change the overwrite time
on the table(s) to 0 and then delete the "Active" pluginassembly and plugintype records.
Is there any other way to accomplish this same thing that is supported?
BTW. We did try to unregister the plugins before trying this, but there were too many dependencies in our workflows.
Wow, this is a thorny problem. Since you mention updating the tables directly, I'll assume that the system is on-prem.
Registering a plugin that exists in a managed solution outside of that managed solution is something I've never done, and while I have directly updated the plugin registration table, it is certainly something to minimize.
As unpleasant as it sounds, to get back to a good state in a supported way you may be looking at having to:
Backup the SQL database
Backup all the data from any managed solution entities.
Undo all dependencies on the managed solution (i.e. edit all the workflows so they no longer depend on the managed solution). To ease the pain of this piece you might want to experiment with exporting the affected workflows via an unmanaged solution. Then you could delete them rather than trying to weed out the dependencies. Then after you have the managed solution back in the system, you could theoretically import the unmanaged workflow solution to restore the workflow. But, admittedly this working depends on workflows finding the plugin assemblies they depend on by name rather than Id, which I'm not sure is the case - so like I said, experiment.
Unregister the "out-of-band" plugin
Uninstall the managed solution
Install a clean copy of the managed solution, INCLUDING the previously problematic plugin.
Restore/reconfigure the workflows
Restore the managed entities data
It's a lot... so much in fact that I would consider opening a Microsoft support ticket to see if they can provide any alternative methods to correct the situation.
In this situation I personally might also consider unsupported methods like using SQL to copy the tables of any managed entities before deleting the managed solution and then using SQL to copy the data back after the managed solution is fixed. Of course I (almost) never recommend using SQL in an unsupported way, so explore that option at your own risk (and with copious backups).
First, try to avoid direct DB updates in system tables whenever possible. You never know when it will hit you (next solution import, next CRM upgrade, moving to cloud, etc).
I assume that yours vendor solution contains entities and attributes and not only assemblies with SDK message processing steps. Thus you can't just simply remove that managed solution cause there will be data loss. Also I assume there are no workflow activities in their assemblies.
Ask them for solution with properly registered assemblies and SDK message processing steps. Then go into your organization with plugin registration tool (https://msdn.microsoft.com/en-us/library/gg309580.aspx) and unregister their assemblies. Then just import their latest solution. It should be able to import their assemblies with whatever is inside them.
It's good idea to restore copy of prod organization and playthrough whole process in safe environment first.
We are a distributed development team working on same solution while performing customization for our CRM instance.
At times, it becomes important to know who has done what changes, or which customization has been done by whom. For example, if I would want to know who has added/ modified/ deleted a few fields from a particular entity.
Is there any such provision in Dynamics CRM? And also, if there is approach can follow to track the changes in CRM solution.
Any help on this will be much appreciated.
One option would be the Solution Packager, which will allow you to pack / unpack a CRM solution into / from source control (like TFS)
For Dynamics CRM 2011, Microsoft suggests moving entity customizations from DEV to PRD by packaging the changes as managed (or unmanaged) solutions. Unmanaged is bad because you cannot remove the entities when you need to (deleting the solution only deletes the container, entities contained in the solution remain). In most lab examples during training, you’d customize the system, then export the customized entity as a managed solution, then import it into production. This solution-based approach is clean, makes it easier to control what’s in PRD, bundle related entities together, track dependencies, etc, so I get that.
There are times, however, when you need to dump the org on the DEV server and restore from PRD (to address a data-specific issue or for other reasons). We do that by disabling, then deleting the DEV org, then asking the DBA team to restore the CRM database from production, then we import the org back to the DEV server. But if we implement this “managed solutions”-based change migration process, won’t we lose the ability to change our entities after we dump DEV and recreate it from PRD, where these solutions are sitting in read-only mode? If we enable customizations in these managed solutions, will we be able to add new entities to the solutions or remove entities from inside the solutions without deleting the entire solution? Because I thought managed solutions are treated as a single unit of code, so it’s either delete all or delete none. Interested in learning how others have resolved this issue.
One way we have handled this is using a seperate clean dev machine which we use to manage the configurations as the "configuration master". That machine is not used for any other dev or test work. The dev machines for plugsin, etc. can be rebuilt from prod, but this machine continues to be the master for all solutions. Not an ideal solution, but it does avoid the "feature gap" of being able to convert managed solutions to unmanaged (maybe through some password facility)
I would advise against using solutions in these type of dev-to-testing-to-prod situation.
If you are unsure about this try to remove an entity in your dev environment and publish the change to your production environment.
Solutions are inclusive meaning that CRM doesnt remove fields and entities that where deleted in your solution.
The only way to remove an entity is to uninstall your solution therefore deleting the production data in all entities covered by your solution!
While in theory solutions seem perfect they are only usefull for third party vendors.
The goal of beeing able to rollback by uninstalling your solution is a pipe dream. Consider a data model update that involves data conversion. No magic function will reverse that.
It is a far simpler and reliable to restore your backup.