Dynamics V9 on premise prod restore on dev environment - dynamics-crm

I have a prod environment where the version of dynamics in 9.0.16.7 (prod, was not installed by me).
I have installed installed the new organization which is version 9.0.2.3034. (I have not applied any kind of updates, it was this version from the beginning).
Now I want to take all that's in prod to my new organization.
Steps I have performed:
Got the backup of the prod environment sql database.
Restored it in the sql of the dev server.
Opened Deployment manager -> Import organization -> DB was automatically detected -> did the mapping -> waited for the result.
The result I got looks like this:
Microsoft.Crm.CrmException: Database having version 9.0.16.7 is not supported for upgraded.
My question(s):
How can I restore the prod environment in my new organization ?
If I need to change the version of the new organization what are the steps that I need to take in order to achieve the result ?
Any kind of response will be awesome because I struggle finding any kind of resources about this topic.
Thanks

I found an update which upgraded the organization.
I imported organization and it succeeded.

Related

what is the proper way to clone Dynamics v9 on-premise environment?

Helllo,
I have a working and up to date environment for Dynamics v9 on-prem.
I want to create another environment which will be identical to the above mentioned one.
Let's say that I want to clone PROD env and create a new Test environment with the same data and customizations that I have in prod.
What are the proper steps ? There is a lack of resources about this topic so I might have posted this in a wrong place. In this case, sorry and please refer me to the correct forum if you know such.
My idea is that, yes I would back up the sql server and then restore it but what happens on the Dynamics side ? Do I need to import any kind of configuration from the Dynamics Deployment Configuration ?
Or can I create the new environment and then restore the prod database in this env ?
Thanks
Steps:
Backup the database of the existing D365 organization
Create a new D365 organization
Restore the new organization using the backup of step 1
The wizard will guide you through the process.

Moving my first Blazor solution to Azure - Build still pointing to local DB

I just loaded my first Blazor solution to Azure. Using Visual Studio, I developed on my local laptop with two databases. One for security, another for data.
I have successfully deployed everything to the free Azure service created, and my local build reads data from the online Azure databases. But when I run the application online, it comes up with an error. Looking at the browser terminal it seems that the online system is expecting the database to be on my local machine.
When Building:
1>------ Build started: Project: ContakLibrary, Configuration: Release Any CPU ------
2>------ Build started: Project: ContakDB, Configuration: Release Any CPU ------
2> ContakDB -> C:\Users...\VisualStudioDevProjects\ContakProject\ContakDB\bin\Release\ContakDB.dll
2> ContakDB -> C:\Users...\VisualStudioDevProjects\ContakProject\ContakDB\bin\Release\ContakDB.dacpac
Excerpt from error in browser:
blazor.server.js:19 [2020-08-11T20:21:04.671Z] Error: System.Data.SqlClient.SqlException (0x80131904): Could not find stored procedure 'dbo.spLandingSiteGet'.
...
at Dapper.SqlMapper.QueryAsync[T](IDbConnection cnn, Type effectiveType, CommandDefinition command) in /_/Dapper/SqlMapper.Async.cs:line 419
at ContakLibrary.DataAccess.SqlDataAccess.LoadData[T,U](String storedProcedure, U parameters, String connectionStringName) in C:\Users...\VisualStudioDevProjects\ContakProject\ContakLibrary\DataAccess\SqlDataAccess.cs
Any help would be greatly appreciated.
Thanks.
UPDATE
Make sure that the table structure, function, and stored procedure in localdb and azure sql database are consistent.
PRIVIOUS
You need to find Connection strings in your project. It should be found in .config or .json file. Not hard coding in the code.
Then you can add new connection string in portal, and set the value of production environment.
The settings in the Portal have higher priority than the settings in the project configuration file. This helps local debugging and protects the database security of the production environment.

CRM custom workflow publisher prefix changed after deployment

We use CRM 2016 SP1. We deployed our latest changes from Dev to QA, staging and production by means of importing a managed solution file. As part of the solution file there is a custom Action workflow (Category = Action) with the publisher prefix set to our company name.
The workflow has been activated and working well in QA and staging but when trying to activate it on production CRM comes up with the error "Unexpected Error". Downloaded error details show the same message.
Upon investigating the workflow in production we realised that its publisher prefix had been changed to "new_". To be more specific, the Process Name property starts with the correct prefix name but the Unique Name property starts with "new_".
We had not made any changes to the workflow in Dev and it was working fine in production prior to the deployment.
So far my research on the Internet on how/why this change has come about and how to fix it has been in vain. So any help is greatly appreciated.
Regards
This is identified as an issue in 2016 SP1.
Check Link Here
The solution is to Recreate the Process with correct Prefix and delete the one which start with new_ that to before final deployment/packaging/release.
It is observed that even both processes has different prefix they are identified as same process.
Please see this link for the solution
https://community.dynamics.com/crm/f/117/p/243572/680715#680715

How to setup SonarQube for a large organization

I am in the process of setting up SQ for a large organization. I plan to have two separate systems one for update testing and rule development. The second would be the production system where real work occurs. I will be using SQL 2014 typically when I do that I use a SQL always On group to sync to a DR server in another datacenter. My question is with a SonarQube instance does it make sense to DR the application to that level. If my organization can wait for a period of time to stand up a new server in a DR event would that be possible with a proper backup of the DB? Further if there were no backups of the DB what would be lost with a fresh new SonarQube server besides setup/config time? Is there historical value of code scans that would be lost or would the next scan of the code base have us right back to where we were in terms of critical issues found etc.?
Thanks for your replies.
All the data is stored in the database so using DR on the database is a good idea. You should make backup of the database and restoring the database is also a good solution (note that you should do backup of installed plugins).
If you loose the database, you will also loose all the configuration (quality profiles, credentials, etc.) and the history of the analyzed projects.
So to restore a SonarQube instance, you have to :
Restore the database
Restore SonarQube or install the same version
Restore the plugins (${SONAR_HOME}/extensions/plugins)
During the first start, the ES files (${SONAR_HOME}/data/es) will be regenerated and you're instance will then be up and running.
If you have commercial plugins or if you are working with large SonarQube instance you may contact the sales team to have support on this setup.
Disclaimer : I'm working at SonarSource

Back/restore single environment in Octopus Deploy

We've been experimenting with Octopus Deploy on a development PC and now want to transfer the environment we've created onto our main Octopus Deploy server (which is used by other teams and already has a few environment set up on it).
So we would like to backup/restore this one environment. However, it looks like Octopus only allows you to backup/restore the entire database.
Is it possible to move a single environment from one Octopus server to another using backup/restore or another means?
What worked for me was simply doing the following in order:
Shutting down Octopus service so that no transaction going through.
Copy the raven database (usually stored in Program Files\Data) to your new server.
Install the new Octopus server and during the setup, in the Storage Tab, specify the location of your data location copied in the second step above.
The Octopus developer, Paul, mentions the great thing about RavenDB is the installation. It requires no services running like SQL. It's just a copy paste of the data itself and great for installation and portability.
There's currently no way to backup/restore just part of the database - you'd need to restore a full backup, and then delete the information you don't need.
Octopus 2.0 (which is now a public beta) has a comprehensive REST API so it would be possible to use that API to fetch a subset of information and import it to your new Octopus server.

Resources