I have a .bak file with all my customizations and common data for different organizations, created from organization called 'DevOrg'
I bring it to another environment, I create a TestOrg_MSCRM, restore it with the backup, and with the Deployment Manager import the org 'TestOrg'
If I query the Organization table for 'TestOrg', it has the same ID and name than 'DevOrg'
However, when I create SecondOrg_MSCRM and do the same process, the ID and Name changes in the step of the Deployment Manager.
Both instances are working correctly, however having the incorrect name for the org causes connection problems when using the web portal.
I'm wondering at first time doesn't change the ID and Name because are unique, but;
1.Is there anyway to change it while importing, and not having to change it manually in DB?
2.Are there any other tables with this kind of information for keep on mind?
There's quite a bit to do but thankfully someone has dealt with it already. I haven't tried it myself so can't vouch for it but it's getting good feedback. I have the SQL in my back pocket for when I do need it.
Related
I have been trying to find a standard way to include databases schema patches into my Azure continuous deployment flow.
So the problem I am looking for a solution to, is that as an application evolves, so does the database. Ever so often there are changes to the database to support new functionality etc.
In earlier work situations I have used proprietary solutions that hold changes to the database in a linked list in an Xml document. The database then knows the latest patch it applied, and if any new patches are present it will apply them. That way it is easy to keep all environments synchronised, and the changes follow the code.
While these proprietary solutions have worked great, I was thinking that before I implement yet another tool to do this, I would see if there was a standard solution provided by SQL Azure to solve this problem. But I haven't been able to find one.
Is there one or do I need to create a tool myself?
Visual Studio Database Projects support deploying to Azure SQL Database so this is a good way to incorporate it into a CI workflow. If you are used to traditional deployment methods it is a bit of a mindset change; these projects work out at deploy-time what to deploy. For example, if you want to create a table, add a Table to the project and fill out the columns. Then, say months later, you want to add a column, simply add the column to the CREATE TABLE script. When you deploy, it will work out that the only schema change is a new column and it will add it.
This is a nice little series on that topic:
https://channel9.msdn.com/Blogs/Have-you-tried-turning-it-off-and-on-again/Creating-a-Database-Project-for-Artificial-Intelligence
I am new to CRM and have gone through OJT(On Job Training) and being assigned this project. So this question may sound too amateur.
We are using Dynamics CRM 2011. There is a customized solution that contains the custom entities used for storing the Case data. I have done a few changes for two new clients in the solution. Like adding new subjects, plugin changes, javascript changes etc. Now i want to get all these changes updated on production. There are some issues with the current production server because of update rollup not being installed correctly. I am not able to delete any user or do any settings changes. So we are planning to setup a new production server.
I have done the changes in the new production server. And the current production server has lot of new cases which are not on the new production. I tried the export functionality in Dynamics CRM, but it doesnt work. It always skips a few records(best has been 31/50 records) even when the wizard goes through without any errors and after migrating all dependent entities data.
Now there are following ways I can think of to streamline the servers without having any downtime :
Migrate the data from the current production to new production.
I have done my research on Instance adapter for CRM. ( http://www.powerobjects.com/2012/10/26/installing-dynamics-crm-instance-adapter/). But i got stuck as i cannot download Connector for Microsoft Dynamics.
Backup current production data and create a new organization. Import the unmanaged solution from the new production. I have tried this. It doesnt import subjects, javascript changes etc. although it does import plug ins. So i am not sure till what extent it successfully imports. In that case I will need to run a complete test cycle to ensure that everything is working. It will require downtime.
Can any experts in this forum guide me in this situation please?
We are going with option number 2. I have successfully tried to :
Backup current production. Restore to a new organization.
Import the unmanaged solution with changes.
Create any new taxonomies, users, option set values required.
Currently it is undergoing final round of testing and has passed the first round.
The important thing to remember while importing the solution is to check the checkbox for activating all workflows and sdk message processing activities. This keeps the organisation instance in the same position as the source instance i.e. SLA clocks etc.
Also the processes changes(Pre-Post plug-ins, email notification workflows etc) are not imported through unmanaged solution as they are not attached to the solution but to the database. We are planning to carry out these changes over a weekend, so no downtime.
Hopefully very soon we are going to move on to Dynamics CRM 2013.
In my solution I have a workflow where one step contains a reference to Queue. After importing this solution on another CRM instance this workflow could not be activated because it contains an invalid reference - Queue can not be resolved. Queue with same name is created on new CRM but resolving is probably based on record Guid.
Now, I'm wondering, is there a way to edit workflow steps using CRM SDK? Whole process of CRM solution deployment is automated. And I want to remove all manual work. Some example would be great :)
Thanx in advance!
There are 2 things you can do if you are having issues with the Guids not matching in a workflow lookup when deploying from one environment to another.
Use the API to create those records referenced in the WF. When you create a record you can actually specify the Guid that it uses as the id. So write a tool or see if one exists already that will create some default data for your environment.
Use a configuration entity with references to all the EntityRefrences needed in your WFs. Then you can create a custom workflow activity to retrieve the configuration entity record (there should only ever really be one) that contains all the references in that environment.
I'm having a problem when copying customization between organizations with solution export/import.
That's every time that I copy data between different organizations/environments, I have to go through all workflows and change the references to CRM data, i.e 'From' field of an e-mail, that can be a queue or user mail.
In the new solution I have "Service" and it should be Service, so having the same name isn't a solution, so I think this is regarding to the GUID of the elements, but there is any option while exporting, I suppose, for avoid that, any freeware tool for that? Thanks!
This solution requires some .Net development, but once it is set up is pretty extensible. Either create a Configuration entity that only ever has one record or create an xml web resource that that stores all the environment variables like references to users, server settings url, etc.
To access your config entity (or web resource) from a Workflow you can create a simple workflow activity that just returns the first record of the configuration entity. Once you have it you can reference any property on it and since the data in that configuration is a record it unique to that environment.
Like I mentioned you can probably use an XML resource to do it, but retrieving an entity is easier, and you get the CRM UI for option sets and lookups and you can restrict who can edit it with security. You can also add new fields at any time and not ever have to change your WF activity code.
we are currently working on a specific CRM development. As part of this development we are working with a different supplier who have provided us with a 'core' managed solution, a toolkit of sorts. This toolkit contains a number of entities/web resources etc but crucially contains the case and contact (renamed to customer) entities. As part of our development we need to extend these entities by adding attributes/amending form layout etc for both these entities.
should i create a new unmanaged solution - select add existing - choose the customer entity.
I can then make my changes (new attributes, form layout changes etc)
I then publish my unmanaged solution as a managed solution to import into a UAT/Prod environment.
Would this approach work ok?
What if the supplier make changes to their core entity and provide us with an updated release? what happens then or what should i do?
There are a couple of attributes (title and ethnicity) that are part of their entity but i need to work of global option sets so i have create 2 new attributes and these are displayed on the form in place of their's. I have not removed theirs but could this cause issues?
any help appreciated
chris
You are right on in the first paragraph, you would need to create a new solution and amend their entities. When you import their changes it will add on any additions to those entities. Importing customizations should never remove anything, you have to do that manually. Although unlikely, it is possible that the vendor may release a new version that requires you to roll back your customizations and reinstall it. In this instance you would need to come up with an upgrade plan and take into account all of the dependencies of the system.
I would imagine that those attributes would be dependencies of their managed solution and suspect that CRM won't let you delete them. If you are able to delete the fields and recreate them using global option sets there should be no issues so long as you use the same picklist integer values and schema names for the fields. Microsoft CRM basically copies all of the global option set values to the entity that you put them on so externally there is no difference between the standard and global option sets. Obviously a future upgrade by the vendor may force you to delete it all and recreate everything again manually (or via code using the CRM web services), but that is something you would have to take into account.
What the disadvantage here is, is if you create an entity, attribute or relationship in Dev and deploy to forward facing entity, if you then remove that entity, attribute or relationship in Dev, you must "uninstall" that solution. Of course, if you have critical data in that forward facing environment, it is gone when that solution is removed. So, if you deploy from Dev to forward facing, if in the future you no longer need that entity, attribute or relationship, although you can remove it from forms, it will always remain an artifact in your system. This is a disadvantage when working with Managed solutions.