Peter

I often read newsgroup posts complaining about licensing issues surrounding Sql Reporting Services. However, I think most of the complaints are overblown. In mosts cases, you simply need to reconsider why you are having to deal with these licensing issues in the first place. Typically this issue first arises when you try to architect your SRS implementation to be more scaleable - beyond a single-server install.

When addressing scaleability and availability you should start by using a remote ReportServer DB instead of hosting Sql Server on the same box as SRS. This 2-tier approach is what MS recommends for scaleability - and is covered by the standard SRS licensing that says gives you 1 license per Sql Server license.

Tier 1: Report Manager UI & ReportServer WebService
Tier 2: ReportServer Database

Where I most often see people lamenting the licensing costs is when they are trying to further split the web-sites into a third, Web Services, tier such as:

Tier 1: Report Manager UI
Tier 2: ReportServer WebService
Tier 3: ReportServer Database

My question is; what problem are you trying to solve by creating this architecture?

Typically I have seen this approach when trying to deploy SRS within an existing Web Farm that already has a 3-tier archicture:

Tier 1: Web UI
Tier 2: Web Services & Application Services
Tier 3: Database

From my experience this is not a good idea for Sql Reporting Services for 3 reasons;

A) due to the large payload for PDF and other potential rendering outputs, the performance characteristics of SRS is substantially different than a typical website or web-service. So it is usually bad to mix-in these services with an existing web-farm since it will likely cause both to perform differently (usually worse).

B) the SRS Report Manager, the ReportServer Web Service, and the ReportServerService (Windows Service) all do report rendering - they simply share the same underlying codebase for Report Rendering (at least in SRS 2000, but I havent checked SRS 2005)

C) both websites require the ReportServerService for activation, which would require you to have it installed on both tiers. This defeats any attempt to create a clean seperation of web and app functionality - which is often at the core of trying to scale-out the number of tiers.

From what I have read, Microsoft's proscribed approach to scaling SRS is; First split the data and web tiers - using a remote SQL Server instance (instead of installing SQL locally). Second, scale-up the CPU's and memory - with a max of 8 logical cpu's (4 HT CPU's) recommended. I don't think you can actually add "too much memory", but my experience has shown that 4GB is ample. Third, to scale-out the above SRS farm - by duplicating this setup across multiple servers and using load-balancing. Basically, stick to the 2-tier architecture, then scale-out the SRS application. I have not seen any additional benefit from further splitting the web tiers.

Following this approach, the licensing costs do not increase until you have hit the limit of a single server or if you desire to increase availabilty via load-balancing or clustering. In my experience, addressing availability (for redundancy) typically happens long before you start dealing with scaleability (load-balancing) issues.

Obviously, at this point you may need to purchase additional Sql Server licenses. However, keep in mind that its also likely that if you are pushing enough volume to require this level of scaling, then you may already have multiple SQL Server licenses that you can leverage to cover your licensing requirements for SRS.

NOTE: if you are running SRS 2005, there is one additional thing you can do to squeeze a bit more performance. Change the configuration to use "Filesystem Snapshots" (see books online or helpfiles) instead of the default SQL Snapshots for report-caching and histories. This can reduce your network and SQL overhead - at the expense of local server file IO which is often a worthwhile trade-off.

I hope this information is useful, and as always your comments are welcome - since there are always gaps in my knowledge, or scenarios that I havent yet considered.