The forgotten on-premises semantic model that most Power BI Report Server teams might forget they need
Here’s a conversation I have more often than you’d think. Especially last week. A team has landed on Power BI Report Server because the data has to stay on-premises. They’ve built half a dozen reports or more many more reports. Then someone asks the obvious question: “Can’t we just point all of these at one shared dataset, the way we would in the Service?” And the answer is no. Power BI Report Server doesn’t do that.
What it does do, if you know where to look, is something older and frankly better suited to the job: an SSAS Tabular model, built once and consumed by every report through a live connection. Used properly, SSAS Tabular with Power BI Report Server is the on-prem equivalent of a certified shared dataset. It’s your single source of truth. Most teams skip it, then wonder why three reports give the board three different numbers for the same metric.
Yes, the pattern works. Yes, it’s supported. And for any estate with more than one report and a real governance requirement, it’s the right call rather than over-engineering. The caveats are narrow but worth knowing.
Why does the Power BI Report Server force the question
In the Power BI Service, the shared semantic model is the backbone of grown-up reporting. You publish one model, certify it, and then reports connect to it. Everyone consumes the same definitions, the same security, the same logic.
Power BI Report Server has no equivalent. Reports deployed there can connect using import, DirectQuery or live connection, but they cannot treat a published .pbix dataset as a shared source the way the Service can. This was a question in my course last week with a focus on Power BI Report Server, a great question, and the reason I wrote this up. If you want a governed model feeding many reports on-premises, you need somewhere to put that model. SSAS Tabular is that somewhere.
SSAS Tabular is your on-prem certified model
Define it once, consume it everywhere. Relationships, hierarchies, certified measures and row-level security all live in the SSAS model. The Report Server becomes a thin client that is queried. Nothing is copied into the report. Every interaction sends a query to the model and returns the latest processed result, so the report always reflects the model’s current state.
There’s a practical on-prem bonus: when Power BI Desktop and the SSAS server are both on your network, a live connection requires no gateway. The two simply talk to each other.
Picture a health care reporting estate. One Tabular model holds admissions, RTT and theatre-activity facts against conformed Date, Site and Speciality dimensions, with certified measures for RTT 18-week performance and theatre utilisation. Every board pack, every operational overview page, and every analyst’s ad hoc connection consumes those same measures. When the Chief Executive and a directorate manager both quote the 18-week figure, the number is identical, because it’s calculated once, in the model, not re-derived in each report. For freedom-of-information scope and audit trails, that single lineage is the whole point.
Security lives in the model, not the report
With a live connection, you secure data in the model. The roles and rules are defined in SSAS, not in Power BI Desktop. When a user opens a report, their identity is passed to Analysis Services via the EffectiveUserName property, and the model’s row-level security determines what they’re allowed to see. Define security once, and every report that connects inherits it. You can’t accidentally leave the back door open on report number seven.
One sharp edge to plan for. Report Server has no UPN mapping table, which the Service uses to reconcile identities across boundaries. So a live connection that crosses a domain boundary, with Report Server in one domain and SSAS in another, has no clean way to remap credentials and will give you trouble. Keep Report Server and SSAS in the same domain, or budget for the Kerberos delegation work before you start.
The trade-offs to this approach
A pure live connection is a single source. You can’t bolt a second data source or a Power Query step onto the thin report. You can add report-level measures, but the model is the model. That constraint is doing its job, not getting in your way, but set expectations with your analysts early.
Composite models relax this by letting a report extend the central model with local tables. They carry a version floor, though: connecting to an SSAS Tabular model in composite mode needs SQL Server 2022 Analysis Services or later. And there’s a point to verify rather than assume, whether your Report Server build of Power BI Desktop, which lags mainstream Desktop, exposes composite-on-Analysis-Services at the version you’re running. Treat the clean, single-source live connection as your default, and prove that composite works before you promise it.
Two more practicalities. Processing and refresh are separate clocks: the SSAS model is processed on its own schedule, and the thin report has no data to refresh, so it always shows the model’s last-processed state. And watch compatibility drift, a model authored at a compatibility level the Report Server tooling doesn’t understand, is the classic production failure. Pin your versions and keep the Report Server Desktop build in sync with the server.
Licensing changed in November 2025 (check your SQL Server version)
Licensing shifted materially with SQL Server 2025, so the old advice is now only half right. Under SQL Server 2025, Power BI Report Server is included with Standard edition, not just Enterprise, and Software Assurance is no longer required. Any SQL Server 2025 Standard or Enterprise core licence carries the right to run it. That’s a genuine cost saving for teams that just wanted on-prem reporting without Enterprise pricing. And comes from the decision to depracte and retire SQL Server Reporting Services
Be aware that the new rights apply only to SQL Server 2025 licences. On SQL Server 2022 and earlier, the old rules stand. You need Enterprise edition with active Software Assurance, or a Power BI Premium P-SKU, or Fabric F64+. In every case, a Power BI Pro user subscription is still required to publish shared reports. Scope the client’s exact SQL Server version and edition before you commit to a design, because the answer to “what does this cost?” now depends entirely on it.
Is it worth it?
Reach for an SSAS Tabular gold-standard model when more than one report or team needs the same measures, when governed row-level security at scale is a requirement, when a single audited source of truth is genuinely needed, or when the model’s logic will outlive any one report and deserves to be a version-controlled asset.
Don’t bother when it’s a single report, a single team, modest data and no governance driver. There, a well-structured .pbix with a clean star schema answers the question, and the SSAS infrastructure, processing schedule and deployment pipeline buy you nothing but overhead.
The one line answer: if more than one report consumes the same measures, the model belongs in SSAS, not in a .pbix. Below that threshold, you’re polishing infrastructure nobody asked for. Above it, you’re building the thing that stops your reports from disagreeing with each other.
Work with me on this
Deciding whether your on-prem reporting needs a proper semantic layer — and designing it so it scales without becoming a maintenance burden — is exactly the kind of work I do with data teams. If you’re weighing this up for your own estate, take a look at how my Power BI consulting and training engagements work, or get in touch and we’ll talk it through.
Frequently asked questions
Can Power BI Report Server connect to an on-premises SSAS Tabular model?
Yes. Report Server supports live connections to SSAS Tabular, and when Power BI Desktop and SSAS are both on-premises, no gateway is required. The report queries the model directly and shows its latest processed data.
Why can’t I just use a shared dataset like I do in the Power BI Service?
Report Server doesn’t support connecting reports to a published .pbix dataset as a shared source. That capability is Service-only. On-premises, an SSAS Tabular model is the supported way to give many reports one governed semantic layer.
Where is row-level security applied with a live connection?
In the SSAS model, not the report. Roles are defined in Analysis Services, and the user’s identity is passed through via EffectiveUserName so the model enforces what each person can see. Define it once and every connected report inherits it.
Do I need SQL Server Enterprise to run Power BI Report Server?
Not under SQL Server 2025. It’s now available with the Standard edition and no Software Assurance requirement. On SQL Server 2022 and earlier you still need Enterprise with active SA, Power BI Premium, or Fabric F64+. A Power BI Pro licence is required to publish either way.
Useful Links
Data Platform Accelerator
Why Your AI Output Is Inconsistent (And the Nine Frameworks That Fix It)
Data-Driven Storytelling with Power BI
PakarPBN
A Private Blog Network (PBN) is a collection of websites that are controlled by a single individual or organization and used primarily to build backlinks to a “money site” in order to influence its ranking in search engines such as Google. The core idea behind a PBN is based on the importance of backlinks in Google’s ranking algorithm. Since Google views backlinks as signals of authority and trust, some website owners attempt to artificially create these signals through a controlled network of sites.
In a typical PBN setup, the owner acquires expired or aged domains that already have existing authority, backlinks, and history. These domains are rebuilt with new content and hosted separately, often using different IP addresses, hosting providers, themes, and ownership details to make them appear unrelated. Within the content published on these sites, links are strategically placed that point to the main website the owner wants to rank higher. By doing this, the owner attempts to pass link equity (also known as “link juice”) from the PBN sites to the target website.
The purpose of a PBN is to give the impression that the target website is naturally earning links from multiple independent sources. If done effectively, this can temporarily improve keyword rankings, increase organic visibility, and drive more traffic from search results.
Comments are closed, but trackbacks and pingbacks are open.