The database for our Dynamics CRM installation is clustered and located on two servers. Somewhere, the MSCRM_CONFIG database is called on one of the SQL instances instead of the cluster, leading to access problems.
I need to correct this and make sure the database is called on the cluster instead. Where can I look for places where MSCRM_CONFIG is called from (config files, services etc)?
What I have tried without success
Looked in the config files for our custom-built CRM-related services
Searched config files in the Program Files\Microsoft Dynamics CRM folder for the name of the instance
Looked at the Deployment Manager for the SQL Server for our CRM Organization
Every Dynamics CRM Server (front-end and back-end as well as servers with the discovery or deployment role) can be expected to open connections to the MSCRM_CONFIG database. This database is needed to get e.g. the organization settings.
The connection string for the MSCRM_CONFIG database can be found on these servers in the registry at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSCRM\configdb.
Related
At our company we currently have a Dynamics CRM 2015 instance running, which has all its databases located on our central database server. Recently, we started developing a new solution, this time based on Dynamics CRM 2016, and for this version too we want to have its databases located on our central database server.
However, when I try to install this CRM 2016 instance, the CRM 2016 installer reports the following error (which is correct, as the existing database is from our CRM 2015 instance):
The following databases already exist on the specified SQL Server: MSCRM_CONFIG
Is it supported to deploy two different versions of Dynamics CRM on the same database server, and if so, how?
It's not supported to have two CRM installation (even same version) on the same SQL server instance. Also installing CRM on same server but on separate instances might put you in trouble with for example SSRS Report Connector.
I take it that you currently have your SQL server deployed using the default instance? (ie; you reference you SQL server as <machine_name>)
If you're not in a position to create a new SQL server (the main limitation being licensing) one option you can consider would be to deploy an additional named instance on the existing server. You could then point your new CRM deployment at, for example, <machine_name>\CRM2016
Sorry for asking this basic question. But I am not having on-premise Dynamics CRM instance, and so I cannot verify this from my end, and also I couldn't find this information online.
As On-premise deployment allows multi-tenant architecture, i.e., one instance can host multiple organizations. Does it mean that there will be one database for one organization? Or if there is a single database for all organizations?
I am more interested into learning about On-premise deployment, but I don't have resources to play around. So just thought to get this info in form of answers
Each organization in Dynamics CRM has its own database, and there is one server configuration database, with each CRM installation, called MSCRM_CONFIG.
Each organization is independent of the others. For example it can host different users and it can have totally different customizations.
One important thing that is to note (in my opinion), is that very frequently it may happen that you may need to move one organization to a different server, or create a copy of an organization on the same server. In this case, when moving to another server you only need the organization database, to copy and restore it to another server, and then import it through the Deployment manager. This will be sufficient and you do not need the MSCRM config database in this case, to have the same organization running on a separate server. This is of course you don't have advanced configuration on the database such as database mirroring, or load balancing.
See attached image, to see how databases look like in SQL Management studio, of Dynamics single server installation. Each database in red, ending with _MSCRM ia a separate organization, and the one in yellow (as its obvious), is the MSCRM_CONFIG database.
Multiple organizations mean multiple databases - one database per organization.
EDIT: plus one configuration database for all organizations
I'm working on a Windows application. When I give this software to the client it is necessary to give database also? I want to lock the database of SQL Server on his computer so that he can not open that database or copy or view its schema or anything by which he can access that database.
When he tries to access that, it must ask for a password. So, what is the solution for the above?
SQL Server databases cannot be password-protected - they're not just files that get opened (like dBase or SQLite)
"normal" access control is handled via permissions and users - you can define who can see what, modify what, delete what
This does not however prevent a system admin from looking at your database schema and contents; there's really no way to prevent this, a sysadmin can also just copy the .mdf file to another server and attach it there and circumvent all your "security"
if you really must hide all of this, don't deliver a database - hide the database in your own company and provide a web-service based interface to the customer who can then call those web services to do his work - then the schema and data is under your control, but also: the customer's data is no longer under his control so he might not like that.....
I have an ASP.NET MVC 3 application using an Entity Framework (4.3.1) Code First database. Now I would like to create a comprehensive zip file containing the database, the application package generated by Visual Studio 2010 and a script to deploy everything to a Windows 2008 server with IIS7 and SQL Server 2008 with a prepared (but empty) database.
I don't foresee any problems with the deployment of the application package, but I'm unsure of what approach to use in deploying the database. The target environment already has an empty database that's been assigned to me, but I've been told that dropping and creating the database is fine.
From what I've read, I can do a straightforward copy of the .mdf and .ldf files to the server and then setup my connection string to point to that specific file but this approach sort of ignores the database that has already been created (or at least named) for me. The other approach would be to use the the existing .mdf to create the database on the server with a script. My only issue here is that I would like to keep the database name assigned to me.
I usually connect to my development database locally using SQL Management Studio and right-click the database, choose Tasks -> Generate Scripts. Then I select the entire database or just the tables I'd like to keep, click next, then click the Advanced button and make sure that I am scripting out "Schema and Data", and then generate a sql script that I can run on the production database, therefore keeping the table structure and the data that was in the dev database. Obviously, if you don't want to keep the data then just script out the Schema only. Then, point your application's connection string to the new production environment database and you're good to go.
I'm a bit new to database projects, but I find that with a bigger team it is a good way to synchronize development.
I had a single Database Project that contained all the tables used by a web app.
The powers that be want to display data from another database in the web app.
I create another Database Project that represents the tables I need in the other database.
I create views in the original database that represent tables in the second database (for linq to sql joins mainly)
Questions
Do I create a Sql Server 2008 Server Project and merge both of these databases into it? From what I can tell, a Server Project still only represents a single database.
If a Server Project isn't meant to represent multiple databases, what is it for?
I have added steps in our TFS Workflow to deploy changes from the first Database Project into our Dev environment on check-in (CI). Assuming a Server Project is meant to contain multiple database projects, can I deploy it and have it deploy changes in both databases?
Thanks!
A server project is for server scope objects needed by your solution: endpoints, server principals (logins), server level permissions, linked servers and other similar constructs that are not scoped to any particular database.
Seems to me that what you need is a solution with two projects:
your original database project
you reference database project
You need a third project in this solution, a server project, only if you must add server scoped objects.
For more details, see Using References in Database Projects.