Back to Blog

On-Premises Reporting with Power BI Report Server - When It Makes Sense and When It Doesn't

October 25, 2026•9 min read•Michael Ridland

Every few months someone asks us a version of the same question. Usually it comes from a state government agency, a hospital network or a manufacturer with a plant network that has never touched the internet. "We want Power BI, but our data can't go to the cloud. Can we run it ourselves?"

The answer is yes, with caveats. Microsoft has a whole usage scenario in its Power BI implementation planning guidance for exactly this: on-premises reporting. The product doing the work is Power BI Report Server, and I've seen it deployed well and I've seen it deployed for reasons that didn't stand up once anyone looked closely.

So this post covers how it actually works, what it costs you in features, and how I'd make the call if I were sitting in your seat.

What Power BI Report Server actually is

Power BI Report Server is a descendant of SQL Server Reporting Services (SSRS). If you've run SSRS, you'll recognise most of it: the web portal, folder-based security, a SQL Server catalog database that stores all the content, subscriptions, and the same paginated report engine. Microsoft bolted on the ability to host Power BI reports (.pbix files) alongside the traditional .rdl paginated reports.

The usage scenario goes roughly like this:

  1. Report creators build reports in Power BI Desktop optimised for Report Server. Note the name - this is a separate build of Desktop, not the one you get from the Microsoft Store.
  2. They publish (or upload) those reports to the Report Server web portal.
  3. Paginated reports are built in Power BI Report Builder or the older Report Builder tooling and published to the same server.
  4. Consumers open reports in a browser through the web portal, or through the Power BI mobile apps pointed at the server.
  5. Data either comes from imported models that refresh on a schedule the server runs, or from live and DirectQuery connections to sources sitting on the same network.

Everything stays inside your network boundary. There's no gateway, no tenant, no data leaving the building. For some organisations that's the whole point.

Licensing, which is where people get confused

You can't just download Report Server and run it for free in production. The rights come from one of two places:

  • SQL Server Enterprise Edition with Software Assurance. If you're already paying for SQL Server Enterprise cores with SA, you likely have the right to run Report Server.
  • Power BI Premium or Fabric capacity. Microsoft grants Report Server rights with certain capacity purchases. The specifics have shifted as Premium per capacity SKUs have been retired and replaced by Fabric F SKUs, so check the current product terms rather than trusting a slide deck from 2023.

Report creators also need a Power BI Pro licence (or equivalent) under most arrangements. That surprises people. "We're not using the cloud, why are we paying for Pro?" Because that's how the licence is written. Do the maths with your licensing partner before you commit to an architecture, because I've watched a project get halfway in and then stall when the procurement team realised the total licensing cost was close to what the cloud option would have been.

The Desktop version trap

This is the single most common operational headache we see.

Power BI Report Server gets updated about three times a year. Power BI Desktop for the cloud gets updated monthly. Report Server only accepts files from the matching Desktop optimised for Report Server release, and that release lags behind the cloud Desktop.

What this means in practice:

  • Your report authors need the Report Server version of Desktop installed, matched to your server version.
  • If someone builds a report in the regular Desktop and tries to upload it, it may fail or lose features.
  • When you upgrade the server, you need to roll out the new Desktop version to authors at roughly the same time.
  • Authors who also work on cloud reports end up with two Desktop installs side by side, and they will open the wrong one. Every single time.

One client of ours had an analyst who spent a full afternoon rebuilding a report because they'd saved it in the cloud Desktop, which wrote a newer file format the server rejected. Nobody had told them there were two versions. A one-page "which Desktop do I use" guide fixed that, and it's one of the first things I recommend now.

What you give up

I'll be direct. Report Server is a subset of Power BI, and the gap has been widening for years. Microsoft's investment is in the service and in Fabric. The on-premises product gets maintenance and a trickle of features.

Things you don't get on Report Server, or get in a limited form:

  • Dashboards. Report Server has reports. It doesn't have the pinned-tile dashboards from the service.
  • Copilot and the newer AI features. None of the Copilot experiences in Power BI run on-premises. If your executives have seen a Copilot demo and expect that, set expectations early.
  • Q&A natural language queries. Not available.
  • Dataflows, shared semantic models and composite models across published content. Each .pbix carries its own model. You can't build one certified semantic model and have twenty reports connect to it the way you would in the service. This is the one that hurts most at scale, because you end up with model sprawl.
  • Apps and the workspace collaboration model. You get folders and role-based permissions, which work fine but feel old.
  • Many newer visuals and Desktop features, which arrive later or not at all.

What does work well: paginated reports (this is the SSRS heritage and it's solid), imported Power BI reports with scheduled refresh, live connections to on-premises SQL Server Analysis Services, row-level security in imported models, subscriptions for paginated reports, and the mobile apps.

If your reporting needs are mostly operational reports, printed or exported PDFs, and a moderate number of interactive Power BI reports, Report Server is perfectly capable. If you want a modern self-service BI platform with shared models, governance features and AI, it isn't that.

Infrastructure and operations

Running it yourself means you own all of it:

  • A Windows Server to host Report Server, sized for your concurrency.
  • A SQL Server instance for the catalog databases (ReportServer and ReportServerTempDB).
  • Backup of the catalog database and the encryption key. Lose the encryption key and you lose stored credentials and connection strings. I've seen a server rebuild turn into a two-day exercise because nobody had backed up the key.
  • Authentication, usually Windows integrated. If you're doing live connections to Analysis Services with user identity flowing through, you'll be configuring Kerberos constrained delegation. Budget time for that. The double-hop problem is not new, but it still catches teams out.
  • Scale-out deployments across multiple servers are possible but need Enterprise rights.
  • Patching and upgrades, three times a year if you want to stay current.

None of this is hard for an infrastructure team that already runs SQL Server. But it's real work, and it's work that disappears when you use the service.

Hybrid is often the real answer

Here's where I've changed my thinking over the last few years. A lot of organisations that say "we must be on-premises" really mean "this particular data can't leave". Those are different requirements.

The patterns we see work:

  • Sensitive operational data stays on Report Server, everything else moves to the service. A hospital might keep clinical reporting on-premises while finance, HR and operational dashboards go to Power BI in the cloud.
  • Report Server as a stepping stone. Organisations with a big SSRS estate upgrade to Report Server first, keep their paginated reports running, and start building Power BI content. Later they migrate paginated reports to the service, which now supports them well.
  • Cloud with the data in Australia. Power BI tenants for Australian organisations sit in Australian Azure regions, and Microsoft's Azure services in Australia have gone through IRAP assessment. Plenty of agencies that assumed they had to stay on-premises found that their security team was comfortable with cloud once the data residency and assessment documentation was on the table.

That last point is worth stressing. Before you commit to running servers for the next five years, get your security and compliance people to write down the actual requirement. Not "we're on-prem", but which data classifications, which regulations, which contractual obligations. Then compare the requirement to what the service offers. Sometimes Report Server is the honest answer. Sometimes it's habit.

When I'd recommend Report Server

I'd pick Report Server when:

  • There's a genuine policy or contractual requirement that data and reports stay on infrastructure you control, and it's been tested against the cloud options.
  • The environment is air-gapped or has no reliable internet, like some mining sites, defence-adjacent work or remote industrial plants.
  • You have a large SSRS estate and want Power BI capability without a big-bang migration.
  • You already own SQL Server Enterprise with SA, so the licensing is largely sunk cost.

I'd steer away from it when:

  • The main driver is "we've always been on-premises".
  • You want Copilot, shared semantic models or Fabric features in the next couple of years.
  • You don't have an infrastructure team who'll own patching, backups and Kerberos.
  • You expect self-service BI at scale across hundreds of report authors.

Practical tips if you go ahead

A short list from projects we've run:

  • Pin the Desktop version. Distribute the Report Server Desktop build through your software deployment tool so authors can't drift.
  • Back up the encryption key on day one, and store it somewhere your DR runbook points to.
  • Plan your folder and security structure before content arrives. Retrofitting permissions to 400 reports is miserable.
  • Watch model sprawl. Without shared semantic models, ten reports can each import the same 2 GB of sales data and refresh it on overlapping schedules. Agree on a small number of "source" reports, or use Analysis Services for shared models.
  • Monitor refresh schedules. The server will happily run fifty refreshes at 6am and then crawl. Spread them out.
  • Write down your exit plan. Even if you're on-premises now, keep reports in a shape that can move to the service later. Avoid relying on features that only exist on Report Server.

Where we fit

We do a fair bit of this work for organisations deciding between on-premises, cloud and hybrid. Usually the most valuable part isn't the install, it's the conversation that clarifies what the requirement really is. If you're weighing it up, our Power BI consultants can help you make that call. If you're further along and thinking about where Fabric fits, have a look at our Microsoft Fabric consulting work. And for public sector teams with specific residency obligations, our AI and data work for government covers the patterns we've used.

Report Server is a decent product with a clear, narrowing purpose. Use it when the requirement is real, keep it tidy, and keep a door open to the service.