It is possible to install Dynamics CRM On-premises using SQL Server named instance. For most parts, the process is straightforward and no different from a “standard” installation except that you have to use server_name\instance_name notation when referring to SQL Server. But sometimes things don’t go according to the plan and this is what I learned:
- Have SQL Server Browser service on. On some networks administrators tend to keep SQL Server Browser service off. It does minimize the attack surface and follows the idea that on-premises you ought to know what you’re connecting to anyway. As it turns out, that does not sit well with both CRM installer and CRM Server after the installation is complete.
- Fix the port. Change the port for the SQL Service from dynamic to a fixed one, e.g. 1434. While it might work with dynamic ports as well, I found it’s easier to deal with known quantities.
- Open TCP port on SQL Server firewall for that port number. Chances are you already have a rule for the default instance, just add the port there.
- Open UDP port 1434. This is SQL Server Browser Service. It’s documented but buried towards the end of the document and easy to miss.
- Install a separate instance of SQL Server Reporting Services. One of the ideas I’ve seen floating around is that, because SQL Server is licensed per physical core, you can install multiple instances on one machine and save a bundle. That is true, until you need to run any custom fetchxml reports. To have that you need Dynamics CRM Reporting Extensions installed. And here is the catch – reporting extensions only support single installation and use fixed registry key to store SQL Server connection string. That means that you need to have SSRS installed elsewhere (could be CRM server itself, for all I care) but that would require an additional SQL Server license. Oops.
Other than the above, named instance installation works and runs smoothly. It totally makes sense in some scenarios, for example, if you have a beast of a server with enterprise licenses already in place.
Regarding SSRS, I wonder if you could get away with using SQL Server Express with Advanced Services just to host the additional SSRS instances? Yes, it’s pretty crippled…. but… if only for hosting an instance of SSRS it could work and not cost anymore dollars license wise.
You are assuming that SSRS Extensions installer does not check the edition. CRM installer does check edition of the SQL Server so I suspect this one won’t be any different.
That’s why I said: “I wonder” ;). It would be interesting to have a crack though.
Just a quick question here. So if the port of the SQL service is. changed from 1433 to any custom port, the above procedure should work fine right?