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.
Related
I am working with a customer which have SharePoint 2013 dev, test and prod environments sitting in a datacentre. We are moving the datacentre which means their SharePoint 2013 needs to be moved as is. They have 1 heavly custom build application on top of SharePoint which needs to be moved. I need confirmation, process suggestion on the migration part.
I install SharePoint 2013 like for like in new environment.
Option 1
I take backup for their databases and restore them on new SQL Server. Use Mount-SPContentDatabase to mount database and test if everything is working as expected
Option 2
Recreate web application, site collections, activate custom features, timer job and migrate content.
I personally think that option 1 is more applicable but need input and suggestions. Any road blockers or gotcha are also encouraged.
Thanks for sharing your experience
As its a same version migration it wont be much of an issue but go with option 1.
Re Creating the whole farm is so hard specially if you decide to deploy each and every component.
I've migrations to same version and these are the steps that i follow.
Create a checklist of all solutions and features (WSP etc).
The check list should have the same services that are running in the farm as well.
Install SharePoint in the new farm and update to the same version as the existing farm , having same version will reduce a lot of
problems.
Create the service applications just like the existing farm.
Restore the service application databases (MetaData, UserProfile etc)
Create the web application and restore the content database
Deploy the custom solutions
Confirm that everything in your checklist is deployed and working fine
Fix errors if there are any
This is the flow that i follow and so far i've been successful.
Good Luck
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 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.
The SharePoint install is a SP2010 install on a 2008 R2 server. Everything is fully patched. I am running the SP Designer on the SharePoint Server directly.
I have a workflow which is intended to send an email when a new document is created in a custom list. I have deliberately kept the workflow very simple in order to illustrate this problem.
After creating this single step workflow in SP Designer, I click "Check for Errors" and SP Designer reports "The workflow contains no errors".
I then click "Publish" but the Workflow Error dialog is displayed with the message
Errors were found when compiling the workflow. The workflow files
were saved but cannot be run.
Clicking the advanced button reveals more information:
Could not publish the workflow because the workflow configuration file
contains errors
Any suggestions gratefully received
I'll share what fixed it for me - deactivating all workflow features at the site collection level (that is, Workflows, Three-state workflow, Publishing Approval Workflow) and then reactivating the features. I was then able to publish my workflow. This post helped, not sure whether this only works for 365 though, but it's sure worth trying first if you are considering a reinstall.
after googling for quite some time, i think it's an authentication issue. How is your SharePoint set up? Do you use HTTPS for authentication? If so check out this article.
I know this error message from sharepoint. I got this by dealing with multiple lookup fields refering to other lists. Even when I check the worfklow for errors SharePoint says that its all fine but i can't publish it at all.
Try to build a new Test-Site on your Site Collection. Build a Custom Document Library, leave it standard and then set up a new simple workflow just sending a mail.
Fill out the needed fields in mail only using simple values. Send to your mailadress, simple mail subject and simple mail body.
Set the workflow to run only manually.
Try to publish the workflow.
When this is working, then compair to your existing workflow and change your values by trail and error.
After doing a clean install of the OS and SharePoint, workflows are working flawlessly. I can only conclude that the problems were caused by left over registry settings from MOSS 2007. Thanks for the suggestions that people made.
This could also happens if you chage the URL of the web application, all you have do is click the Design button from the library itself.
when changinf the URL from http://server/Site to example: http://server.xx1.net/site, and you try to publish it tries the old url.
what helped in my situation is changing from start workflow automatically to manually.some times answers for critical situation is very easy. hope it helps, many thanks
I ran into this problem and after digging for days and folks suggesting to rebuild the servers, disabling and re-enabling site features, remove previous workflow versions, etc. and trying everything except rebuilding the servers (not practical for clients production environment). I decided to try some tests and found that this issue was only happening on one particular list no matter how simple or complex the workflow was... And when I would check the box for start automatically on item create (or when item changed) it would fail to publish and give the error above, but if I published it with just manually start worked fine. Finally after deleting views and some more testing, I discovered that there was over 240+ columns in this list (I did not create it...) and 50+ workflows set to run on create... Thankfully I have a test environment I built out for the client so I sync'd the Site Collection database back to test environment from Production re-ran my tests and got same error... So what resolved the problem and what was the ultimate cause of the problem, there was to many columns defined in the list and I had to delete several columns to publish the workflow in the test environment. This actually issue translates into the there is a limit in SQL Server on how much data the list can store each type of column takes up so much space read more about it here:
https://technet.microsoft.com/en-us/library/cc262787(v=office.15).aspx#Column
So what I did in production was worked with my client to determine how to break up the list into multiple lists and have relationships between them, thus moving some of the columns and data to another list (Think database/list normalization)... I hope this solution helps someone.
One of the biggest challenges that I've encountered with SharePoint is that it doesn't lend itself nicely to the typical project environment, which, at minimum, contain development and production environments. The issues I've run into the most are that content and lists are so tightly coupled that it makes it difficult to perform design changes without performing a content freeze on the production environment. For example, if I have a list with calculated columns and wanted to add some new functionality, I would have to do a content freeze on the production server, create a list template (including content) from the production server, restore that list to the development environment, make my changes, then reverse the list template process. The same holds true for pages and just about anything else in SharePoint. It seems as though once the site is deployed, it's best to work directly on the production box, but that breaks a ton of best practices, for obvious reasons.
How are some of you other SharePoint developers handling this limitation?
There are really two (more?) levels to SharePoint "development". You have the code which gets deployed to the server, such as web parts, content types, workflow actions, etc. This works relatively well in terms of deployment and best practices.
Then you have your example, which is more of a customization of site instances. What we've done when we had to customize a calculated field in the Portal's Site Directory list, is to try and tweak the changes in development. Then write up detailed instructions of the customization to be made, and have a separate person with appropriate permissions use those instructions to make the change on an integration (staging) server. Then have the same person makes the changes live on the production.
I'm not sure if your changes are susceptible to this approach, but it's worth considering.
Then we have another site which is heavily customized with SharePoint designer, and that one we work live on.
You can use Content Deployment Wizard (http://www.codeplex.com/SPDeploymentWizard) to migrate things like lists and libraries quickly. You could also take a backup/restore copy of production, then make your changes on that, and then in the early morning hours, do a content freeze (hopefully no one will care then), import all the changed data from production into your copy, and then restore the copy over production. At least the freeze could be put off and would only be necessary for the duration of the export->import->restore procedure.
In practice, I just make my production changes by hand.
Use FeatureActivation code to deploy changes to the lists' fields. After the code updates the fields then you deactivate the feature and remove it. This allows results to be tested in a QA environment before hand.