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.
Related
I am using the free plan for a personal project, so can't afford to move to a better (paid) one. Unfortunately, my database filled and stupid me did a reset, thinking it will delete only the rows, leaving the structure intact. But it deleted everything, so now I have to rebuild it.
Before I start, I'd like to know if there is a way to empty old records/rows from the database. If I could manage to do this automatically (ideally there are some heroku settings that can do this, something I've missed), so I won't reach the 10000 monthly limit, it will be great.
There are no safeguards built into the platform to delete rows on your behalf. You will need to do it manually or teach one of your applications to do it programmatically.
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.
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.
My team currently works with an on-premises TFS 2012 server. I am migrating everything to Visual Studio Team Services, formerly Visual Studio Online. I am starting with a test project and was able to easily get all the code migrated, but can't figure out how to do the same for the work items.
Are there any good guides out there?
New options as of March 29th 2018:
TFS to VSTS migration - The official import option which will import 1 project collection into 1 VSTS account. It automatically imports everything stored in the backup. At the point of writing this, the TFS must be upgraded to TFS 2018 and some work item template customizations must be removed (there are a few well documented features unavailable on VSTS).
VSTS Sync Migrator - Marting Hinshelwood, the uncrowned king of TFS and VSTS migrations, has built his own little tool that can migrate work items from one server/account to another. It can even do migrations from one Team Project to another and while doing it switch between process templates.
VSTS Work Item Migrator - Microsoft has also open sourced a project that they used internally to migrate work items. It's less powerful, but it was made by Microsoft.
Previous answer:
At the moment there isn't a really good story. Your options are:
Start over - easiest :).
Start over and manually recreate items of value - It's a pain, but it's some teams have done these things in the past. keep the old TFS server available in read-only mode and each time you use a work item in the old system, you manually create it in the new one, set all the fields and upload the attachments. Depending on the number of items it'll take you a few sprints to migrate the most important stuff over.
Wait a while longer - Microsoft is currently working on a full fidelity import option which will allow you to upload a Project Collection and it will be exposed as a new VSTS Account (it's not going to be possible to import a project collection into an existing account).
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.
There are specialized TFS consultants who live off these kinds of migrations if your current state of the work items is precious to you, then you could reach out to them.
See also:
https://www.visualstudio.com/en-us/articles/adopting-vsts
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.