Here's what happened:
We downloaded a managed solution from a 3rd party.
In the .zip, we can clearly see it only specifies 2 new fields for Account
HOWEVER after importing into CRM... when in CRM we open and look at the managed solution... it shows every single field for Account! Not just the new ones from the zip
We'd like to uninstall the managed solution, and only remove the 2 new Account fields
BUT... the managed solution in CRM now shows every single custom field on Account. Will we lose those too if we delete? Or is it normal for managed solutions when viewed in CRM to show every field for the entity, and we can safely assume only those we saw in the .zip will be removed?
From top of my head I could not recollect from my experience why the managed solution showing your custom fields or is it intended.
Though it should not remove any of your custom components when you’re deleting/uninstalling the third party managed solution, I cannot comment on any third party about perfection.
I would recommend you to do a dry run by installing the managed solution in any sandbox environment and testing yourself by deleting it. This way you can be sure.
Typical managed solution should not remove any of our customization when uninstalled. They should only wipe out their components.
Related
In all environments, there is a field MXM_RemoveMe we want gone from the Account "Information" Form (one of the Account's OOTB Managed Forms, but of course we've customized it on our own a lot by now)
In Dev, I remove MXM_RemoveMe from the Account "Information" Form.
I put that Form in an Unmanaged solution in Dev, export and import into QA. Publish all.
Problem: but the "MXM_RemoveMe" field is STILL on the form in QA.
What could cause this? Do we have to manually remove fields from Forms in all environments? I don't think that's the case normally.
I've verified this behavior in a specific test after the fact. If I add a field to the Account form in QA... then export/import from Dev that Form (Unmanaged) WITHOUT the field... it still stays in QA! I encourage everyone else reading this to do this simple test themselves and see the same behavior I see.
How should this be handled/understood?
I think this is because the form itself is managed. The system simply adds fields to the form on import and does not simply overwrite unmanaged changes any more. In older versions of Dynamics CRM this did not work this way though.
When you prefer to continue working with unmanaged solutions (I feel there are valid reasons to do so), a best practice would be to always copy managed forms first and modify, export and import the copy instead of it.
The copy would be in its entirety an unmanaged form. Up to now I have never seen issues with those forms when imported in target environments in an unmanaged state.
I might be wrong here but this might be changed in the modern make.powerapps.com compared to how it worked in the classic import experience. You might have the option to overwrite your customizations there(not recommended).
https://learn.microsoft.com/en-us/powerapps/maker/data-platform/update-solutions#overwrite-customizations-option
Probably the safest way is to manually go about and delete the components.
Could have to do with solution layering and using the accounts OOTB managed form. Usually, id say it is better to use a custom form
I have a managed solution where I want to add a process/workflow with custom entities. I am able to add process in unmanaged solution for custom entities but have any way to do in managed solution or any alternative way to do so?
Please suggest me what I can do.
Managed solution is not recommended for regular development lifecycle projects, as the future schema changes will be challenging. Managed solutions are good for redistributable components like CRM REST Builder, where author want to have full control & customizations are not allowed in those components as that may break future upgrades of that particular managed solution.
Still you can go ahead & create a standalone solution with your custom entities, then add a WF for that entity. Finally you can export as managed solution to import in other environments (usually only Prod). This way you can customize anytime in lower region like Dev/QA, but Prod can have managed solution & if anything goes wrong - deleting managed solution in Prod will wipe out components + data. You can change in Dev again & a fresh exported Managed solution can be imported in Prod.
Managed solution components cannot be directly customized.
We have a large solution that we are trying to import into another one of our Dynamics 365 online environments. However, the solution is missing around 3 pages worth of required components when we try to export it. If we try to add the required components through the "Add required components" button in the solution, then we can only do it 1 record at a time. This would take a very long time to do. Is there a better way to import these required components? If not, what is recommended in this situation and what are some best practices for managing solutions in a Dev -> Test -> Prod environment scenario?
There are so many reasons why a solution might fail on import, and even more "best practices" for pushing a solution from DEV to TEST to PROD.
Firstly, always make sure that each of your environments is as close to the same as possible. What do I mean by this? Mainly, make sure the managed solutions from each environment match up. Many times, dependencies are pulled in from managed solutions due to bad solution design. WHich brings me to...
Secondly - when you are adding components (entities) to your solution, are you clicking the "add all assets" button? If so - stop doing this. There is no need to pull in 'all assets' on ANY OOB CRM entities. Of course, a custom entity, you may want to pull in all assets. But say you're pulling the Contact entity into your solution, to build a few new fields and customize a form. Instead of all assets, just bring in the shell of account (no assets selected). If you want to clone a form, and make changes, include that form ONLY, then open it and save as, and you will have it in your solution. If you "add all assets", then you're bringing in every relationship in the Contact entity, which is typically where your dependencies will go wonky. Only include those assets you truly need - and always try to avoid including OOB relationships.
In the long run, there is no 'short way' or quick way, to identify and fix your dependencies. What I typically do is take a few screenshots, and go through them 1 by 1 and resolve them. The error should tell you what artifact is causing the error, and which element requires that artifact. You have to resolve each of these, and then re-attempt the import.
If you post some screens, Ill try to help you resolve the issues.
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.
How can I remove the solution: Free Base Trial Solution from my trial online CRM 2016? I also have another solution called : Project Field Service which I am unable to remove.
I also removed my sample data, but I can still see lots of Contacts created by Owner: System. How can I remove this as well? Are these related to the solutions I want to delete? Thanks.
You can go to settings -> solutions and delete the solutions from CRM. If they are managed, it will remove all the customizations.
To delete data, I always delete all accounts. That deletes alle related records as well (Cases, contacts, opportunities etc.) Depending on your needs, you might need to delete unrelated data as well.
As far as I know, there's no single 'delete all' button.