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.
this problem went on also to SSRS 2019!
Tobias Schuster commented
We can't change to SSRS 2017 until this capability has been restored.
I work at a University where security is tight. I keep the different departmental Reporting Servers separate and it is far less oversight to have the instances on one server than to have to manage multiple servers.
Resources on the VMWare are tight and we recently ran out of space to create additional servers. The waste of time and resources for the University because Microsoft doesn't want to support multiple SSRS instances will generate money for someone, but it's not going to be for Microsoft.
How is SSRS licensed? More specifically, can we install an instance of SSRS on different servers with the databases hosted on a licensed Enterprise SQL instance and only pay for the SQL Server instance?
Looking for options to get around the removal of named instance support in SQL 2017 and 2019 which could well be a deal breaker for us too if we have to license each individual SSRS instance as well.
Thomas Lehrer commented
Removing the side-by-side installation of several Reporting Services is an absolute showstopper. As it worked in the past there can only be some commercial reasons to do so.
@Microsoft: Please describe how an update scenario should look like. We cannot force our customers to install every SQL Server Version on separate (virtual) machines.
Unfortunatly this again shows, that you cannot trust Microsoft. Customer needs are ignored, bugs are not solved, you always should use workarounds.
Jason Boyd commented
This was a really poorly thought out change for the way many of us use SSRS in the SMB space. I have vendors that require their own SSRS instance. At least change the licensing to let me install the SSRS engine on the app server and point to the SQL server.
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.