I added two values in an option set field on the production system (on premise Dynamics solution). I realized the right way would be to first introduce the two values into the option set on Dev, then export the solution as managed, and import it into production.
Now when I try to import the managed solution, I'm getting an error:
An error has occurred. {1}{0}
I believe it's because I had created those first values before in Dynamics, since Dynamics only does soft deletes.
I'm wondering should I go to the StringMapBase table and force delete those option set values, in order for the import to work.
You added those options as unmanaged customizations, so you should be able to delete them in production using the regular customization tooling.
Playing with managed solution is dangerous. That's why I always work unmanaged. I would suggest you to recreate the component manually with the same name or to copy your production database in dev.
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 need a temporary workflow to update records in Production instance. I was thinking to just create one in production directly and run it on records and delete it. Whats the best way to do it, should I just create it in customization area (i.e. Default solution) and then delete it later or create a new solution, add this work flow to that solution and then delete that solution?
Or should I create it in Dev and then move the solution to Test/Production like we normally do?
As a best practice, create it in Dev using a new Hotfix solution - test it against some Dev records. Then export the solution (may be Managed one) & deploy in Test/UAT/Prod.
Once data fix is completed in Prod using our WF, delete the Managed solution (which will delete the WF too).
If you want - you can just deactivate the WF in Prod: Settings - Processes for future usage & to maintain environments in sync.
Never customize in the default solution - unless you're working on a managed solution (of which you have no control in Dev/Test), or are looking for a full list of components in an entity without adding them to your Solution (example - when writing a plugin, you need to know the field names of OOTB fields - I go to Default Solution to get these).
You didn't tell us in the message what your Workflow should be doing, and if it needs to be done in DEV or TEST.
What I would do is build the WF in DEV or test, re-create the situation that needs to be fixed in PROD, and test it in DEV/TEST. Once you know it will work, you can either push it over as a solution (or as a part of your existing solution), or, you can simply add it to your solution in PROD and then run it as required. If you need to delete it, great, delete it. If not, just de-activate it so people don't accidentally run it.
I am on Dynamics CRM 2015 on premise. I export the default solution, and the very strange problem is that some attributes are missing in the exported solution Xml. For example: aging30, businesstypecode in the Account entity.
Any suggestion would be very appreciated.
Not long ago they made a change to the export process that only exports out-of-the-box attributes if they've been customized. It's a good change, since exporting attributes that every single CRM environment has is pointless unless it's been changed. I only know this because we noticed the same thing a while ago and came to this conclusion, I can't find any official announcement about it unfortunately.
I had the same issue when trying to compare solutions from Dev and Test environments using the Customization Comparer tool. For example the OOB attribute "telephone1" for contact entity is only showing up in Test column in Customization comparer and not in Dev column so it is showing as missing in DEV but actually that is not the case. So what i did was open the entity attribute in CRM for both environments and find out that on Test , Auditing for the attribute was enabled but not in Dev. So I enabled Auditing in DEV , export the solution and compare again. IT shows up in both columns and as green. Then i disabled it in DEV and reexport the solution in DEV, it shows up as Yellow now and both columns contain the attribute with the isAuditEnabled as different value.
so my conclusion, as Polshgiant mentioned above, only customized OOB attributes appear in the XML when we export a crm solution.So Sean, Just check one of the attributes that are missing in your case and make sure nothing is touched in prod.
I have this situation where we have a production Dynamics 2009 AX (RTM) environment whose AOT we used to do a code update project to RU8.
So now, I have a production environment (RTM) and one that is the same but patched to RU8.
The thing is that since, Page Definitions have changed in the RTM environment and I want to export those to the RU8 environment.
I can export an XPO of the whole tree (Web->Web Files->Page definitions) and import it in the RU8 env. but do I export with or without IDs ? Does this change anything if objects exist in both environments ?
Thanks!
Almost in any situation you should prefere to EXPORT WITH IDs. There is nothing you can lost with this.
You should prefere to IMPORT WIDTH IDs when you want to maintain two copies of the same environment (DEV, TEST, ...).
You has to IMPORT WIDHOUT IDs when you import objects in an environment that has not been in that environment before, nor in a copy of this environment. For example, when you import objects from another company or created by another developer. This usually has to be done in development environment and then export-import WITH IDs to the next apps (TEST, PRODUCTION, ...)
When you import objects WITHOUT IDs, the system will assign new IDs to the objects for this application, so you won't be abble to export-import WITH IDs to another copies of the app. This will lead to problems soon or late so it should be avoided.
There are exceptions to this rule but to be sure of picking the right option in any situation you have to understand well this best practices.
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.