Restore multiple instance support for Reporting services in SQL 2017
Please restore the multiple instance support per server for Reporting Services 2017. SQL Server reporting Services has supported multiple instances on one server in versions SQL 2000 thru 2016 and it was removed by design with the release of SQL 2017. This was a bad move as it will force my company to deploy 6X as many servers to deploy what is a lightweight application server.
I'm not sure if this has anything to do with the PowerBI integration with SSRS, but it also suffers from this bad decision as well.
Marco Nanninga commented
Also for our company this would affect our testing environment quite a bit, we now have 5 SSRS instances on a single server with very low load per instance, sometimes some peaks on one instance at a time. No need to run one VM for each SSRS instance. However to facilitate our customers we will need to run SSRS 2019, for now on a 2nd reporting server VM. Would be great to have multi instance support back in SSRS 2019.
Randy in Marin commented
We are getting ready to upgrade to SQL 2019 and this was an unpleasant surprise. We had the SQL install, including SSRS, automated with several instances on a VM for ALM. Now, I have to now both install SSRS manually and use a separate VM for each ALM environment. A double slap. In the past we pushed for named instances as part of a consolidation effort. Now I will have to apologize and ask them to change back. A reliable product requires a reliable roadmap. Was SSRS separated from the herd so that is can be killed?
Reddy Eswarprasad commented
If SQL Server is allowed to create multiple instances then SSRS ought to have the ability for multiple instances as well... It doesn't sound good to me...
Please add this option asap... We need to install SSRS in our shared environments. Thanks.
Agree, please add this option back!
My company does not have the capacity to have several machines for each client using the report server. Please reconsider the lap of multiple instances.
Justin Terry commented
Jaw drops … How can MS tout a shiny new version in 2017 that breaks compatibility with a fundamental installation option in previous versions. Do MS product teams actually talk to each other at all anymore? What about System Center and isolation of report servers for the different product components? OK, in that particular case we are luckily getting free SQL licenses, but it's still painful to have to spin up separate machines, and in the case of our small deployment, well it's just not viable. Goodbye System Center and SSRS, is that really what MS want?
We can't move forward with SSRS 2017 until this capability is restored.
We have been growing our SSRS environment leaps and bounds - away from Hyperion reports to using SSRS as our enterprise tool. This design makes it difficult in SO MANY WAYS to expand. We have various requirements for different SSRS instances - including SCOM, Sharepoint, and vendor specific installations. each one of these requires a special, distinct, instance of SSRS. Our security guys are telling us that they want SSRS moved out of the Database VLan anyway -so more licenses. Now you are telling us - more VMs, more VM licenses, more SSRS licenses. We won't be moving to SQL2017 SSRS any time in the near future. Bring back that functionality!
Nat Hartge commented
Try an in-place upgrade from SQL 2016 to 2017 when SSRS is installed, the installer asks you to uninstall the 2016 versions. Poor coding on Microsoft behalf, but then they do want everyone to move away from VMware and jump onto AZURE which doesn’t need DBAs as it’s a magical place like AWS.
Frances Searle commented
Our clients seperate their different applications onto different SSRS instances to improve internal application security. Many of their older applications are finally being migrated from SQL 2008 and the best we can do for them is 2016 due to not being able to have multiple instances on a dedicated SSRS server.
We need this when connecting to more than one data base with different reports.
Yasuhiro Tsukamoto commented
Please restore this functionality
Please restore this functionality. It will force my company to explore other products.
Please restore this functionality. We like many others use it a lot.
Without it will force us (and I am sure many others) to explore other options instead of spending more for SQL Server and other licenses.
Tom Dzembo commented
Fully concur with comments below. This new direction will result in unnecessary "server proliferation" and wastes computing power. Last I knew, most computers (servers) were architected as "general purpose" devices. This change suggests the need for a dedicated "appliance" to run reports.
While fixing this, also figure out how to extend the same to the "Reporting Extensions Option" required by MS Dynamics (and possibly other MS products where SSRS use is "embedded" in the install). This option has required the same limitation (1 instance per server) in prior Sql Server versions. Again, it kills our ability to consolidate reporting services when the requirements are crying out to do so.
Nalli, Mark (ITS) commented
Restore this functionality!!! Like many others, this will result in excessive VM's, Licensing, and $$$$. Will force moving away from SSRS. If that was what you were after by doing this, then keep it - and bye bye.
This also breaks the ability to use a single reporting server for System Center applications, as SCOM requires (at least required) a separate instance of SSRS because it munted the instance to be specifically for SCOM.
Jakub Urban commented
Insane. no more comments needed.
Another funny thing is that in the SSRS 2017 documentation, there is not mentioned support to host SSRS databases on SSDE 2017. LOL
Iain Herdman commented
Upgrading our three SQL 2014 Enterprise instances to 2017, and want separate SSRS databases to follow the logical structure we have. Feel totally screwed over by the "new" 2017 setup where as far as I can see, you can forget an SSRS instance per SQL instance. Everything in one container? Not likely!
We have been considering going over to MS Power BI hence the update to SQL Server 2017. With new SSRS functionality working together with Power BI this seemed logical. No longer… looks like we stick with Cognos.
This is such a major change, how on earth to you make a decision like this without checking with users?
Please let us make our own choices how to setup our systems!
John Zabroski commented
I believe I have discovered an alternative path forward today: Docker containers.
The following article explains how to use Docker containers to create multiple SSRS instances on the same machine: http://www.sqlservercentral.com/articles/containers/178448/ - In theory, all you need to do is bind the exposed port for SSRS to a unique port for each container instance.
I had stumbled upon this answer today while trying to figure out how to create repeatable test environment for Microsoft's Powershell Module ReportingServicesTools, and it occurred to me this would be a cheap way to also do multiple instances of SSRS on the same machine.
NOTE: I have not yet tested this, just sharing my clever idea with everyone.