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.
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 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.
We are a Housing Association. We use CRM 2016 SP1. Our Dev and QA environments are single server configuration and staging and production are multiple server config with load balancers. Our custom solutions in QA, staging and production are managed.
We needed to update a "Quick Find Active" view for two of our entities Person and Property with some extra search columns in our staging and production environments.
I added the new columns to those entities' views in Dev environment by going to Settings->Solutions->[custom solution]->Entities->[custom entity]->Views->Quick Find Active [entity]->Add Find Columns. I did the same for both entities.
To deploy the update to other environments as a patch, I exported a standalone solution file that only contained the Person and Property entities with the updated views. I then imported the solution file into the QA environment to test.
Having published the changes in QA after import, I checked the entities' Quick Find Active views in the default solution (Settings->Customization->Customize the system->[custom solution]->Entities->[custom entity]->Views). I noticed that the Property entity was updated with the changes but the Person entity was not. It made no sense.
Having spent some time to search the Internet for an answer to no avail, we decided to try out the patch solution in staging. So we exported the solution file but before publishing the changes we decided to check the update. To our surprise, both entities had been updated. So we did not publish the changes.
Happy with the result and blaming the problem on our QA environment, we decided to go ahead with the deployment to production. We imported the file and check the changes and noticed that this time around the opposite happened to our entities, i.e. The Person entity had been updated but the Property entity had not!
We tried publishing the changes but it made no difference. So at the end we gave up and had to complete the deployment by manually updating the views in production.
I am wondering if anyone else has experienced this oddity. Any help/suggestion is greatly appreciated.
You mention that you are deploying managed solutions, and that your changes are not taking effect. The entities contained in the solution have previously been deployed to the target environments.
If you have previously made any modifications directly to the target environment (which would not seem improbable given that you did so this time), these changes will be in the unmanaged layer, which by default overrides changes in managed solutions:
MSDN says:
Because unmanaged customizations are considered ”above” any managed
solution in terms of conflict resolution, organizations installing an
update to a managed solution may not see their changes applied because
of unmanaged modifications. An option exists to make sure that changes
applied by an update to a managed solution are available.
When you
release an update to a managed solution, the organization installing
the update can select:
To preserve any customizations it has applied on top of your managed solution.
To overwrite any customizations it
has applied on top of your managed solution.
In conclusion: Never make any modifications directly to your target environments if you are using managed solutions. It will cause you issues later.
Thanks to Henrik who replied to my question and put me in the right direction. We managed to resolve this issue. Refer to this page to read the solution.
I currently use TFS 2013 with custom work items for bugs, change request, requirements and features. I am wondering if I can migrate them to visual studio cloud 2015? is there a tool within VS or 3rd party that can do this?
If you are meaning the vsts. Possibly duplicate with this question: How to migrate work items from TFS to VS Team Services (VS Online) . There has been perfect answer from jessehouwing, suggest use one of below three ways as he suggested:
Use Excel for import/export - Will work for most work items, you loose attachments and work item links other than parent/child. The
trick is to extract from one Project Collection then copy all fields,
except the ID to an Excel sheet bound to the target project
collection. You will need to fix all Identity fields (works best when
users have the exact same display name on premise as in VSTS) and
you'll have to import once with state new and then past the current
state/reason over the just imported values and sync again. Test
Cases, Plans, Suites and Shared Steps will not be imported with their
relations in tact. The approach would be very similar to this
one.
Use the TFS Integration Tools - Will work for most work item types, though it will loose custom kanban states and tags. Test
cases, Shared steps and their relations will not be imported. This
option will allow you to import import work items and source code
with their relationships in tact.
Use a 3rd party solution - Out of the available options currently OpsHub offers the most complete solution. For test case and
source control link migration you're looking at the commercial
edition, which comes at a steep price. It still has a long list of
known issues and last time I tried it, I ran into numerous
issues which required their support to resolve them. PS: You can aslo try the tool as Dave suggested in the comment: VSTS Sync Migration Tools
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.