Power BI Report Server: Power BI reports without the cloud

The company has a clear rule: data does not leave its own network. A bank, a manufacturer, a hospital, it does not matter which. Management still wants Power BI reports, and everyone around them says Power BI lives “in the cloud”.

Not only there. Power BI Report Server is the on-premises version that runs on your own server. Most companies are moving to the cloud, but many large ones, because of the kind of work they do, still keep everything in house behind the intranet. Little is written about the on-premises version, and most of it is shallow. This article collects what you need to know before deciding, with links to Microsoft’s documentation.

What Power BI Report Server is

It is a report server you install on a Windows Server in your network. It holds Power BI reports (.pbix) and classic paginated reports (.rdl), and people open them in the browser.

Reports are built in a separate edition of Power BI Desktop, “optimized for Report Server”, downloaded together with the server. New releases come out three times a year, in January, May and September (comparison with the Power BI service).

Starting with SQL Server 2025, Microsoft consolidates all on-premises reporting under Power BI Report Server. No new versions of SQL Server Reporting Services (SSRS) will be released, and SSRS 2022 gets security updates until January 11, 2033 (consolidation FAQ).

What the architecture looks like

The basic setup has three parts:

1. The report server. Windows Server 2019, 2022 or 2025, on a virtual or physical machine. The minimum is 1 GB of memory, the recommendation at least 4 GB, and an x64 processor (requirements). In practice the size of your models and the number of users decide the memory, so for serious use plan well above the minimum.
2. The ReportServer database. It stores reports, permissions and refresh schedules. It can sit on the same machine or on a separate SQL Server (2014 SP3 to 2025, or Azure SQL Managed Instance).
3. Data sources. Your databases, files and systems, in the same network.

A few details that cause trouble if nobody knows them up front:

• If the database is on another server, the service must run under a domain account or an account with network access. A gMSA account is supported too (installation).
• The server can live in an environment with a read-only domain controller (RODC), but it needs access to a writable domain controller to work properly.
• Since the May 2025 release, Power BI Desktop for Report Server needs a CPU with AVX instructions. On virtual machines, check that AVX is not disabled in the hypervisor settings.

Licensing: where the right to run the server comes from

This is the most common question and the most commonly misunderstood. Report Server is not bought as a separate product. The right to run it comes with something the company probably already has or plans to buy:

Basis	Where the key is	Watch out for
SQL Server 2025 Standard or Enterprise	The same key as SQL Server 2025	No separate Report Server key
SQL Server 2022 and earlier, Enterprise with Software Assurance	Microsoft 365 admin center (or Visual Studio Subscriptions for a subscription)	The right lasts only while Software Assurance is active
Power BI Premium (P capacity)	Admin portal, Premium settings tab	Microsoft is moving customers from P to Fabric capacities
Microsoft Fabric reservation, F64 or larger	Admin portal, Capacity settings tab	Comes with a capacity reservation, not with smaller F capacities

Sources: finding the product key, differences between P and F capacities.

Under a SQL Server license, Report Server may run on at most as many cores as there are SQL Server Standard or Enterprise core licenses assigned to that server, with a minimum of four licenses per operating system environment (physical or virtual). The same terms say that publishing shared Power BI reports to the server requires a Power BI Pro license (Microsoft Product Terms for SQL Server).

For testing there are free Developer and Evaluation editions, but a developer key must not be used in production.

Who sees what: AD or local accounts

On the server, permissions go to users and groups, per folder and per report. The only question is where those users and groups come from.

Through Active Directory. This is the default. An employee opens a report and is already signed in with their Windows account, no new password. Permissions go to AD groups, so when someone changes roles you just move them to another group. The server tries Kerberos first and falls back to NTLM (authentication types). Set up Kerberos from the start: without it the user’s identity is not passed on to the database, which row-level security in DirectQuery reports depends on (data sources).

Through local accounts on the server. When reports are for people without a domain account, or the company wants report users fully separate from AD, the accounts and groups are created on the machine that runs the server. There is no single sign-on then: the user types a separate user name and password. If you enable Basic authentication, always use HTTPS, because otherwise the credentials travel unprotected.

Either way the same rule applies: grant permissions to groups, not to individuals. A list of five groups is easy to maintain. A list of two hundred individual accounts is not.

Connectors: check before you start

Power BI Desktop for Report Server can connect to many sources, but the server cannot refresh all of them. Microsoft keeps a table of supported sources with three columns: cached data, scheduled refresh and live connection (DirectQuery).

Three rules from that table that most often surprise people:

• Every source in a report must support scheduled refresh. One unsupported source and the whole report stops refreshing on its own.
• Sources not in the list work only with the data saved in the file. No scheduled refresh and no live connection.
• OAuth authentication is not supported for refresh or for DirectQuery. That rules out many cloud services.

Take ClickHouse as an example. Its connector is not in Microsoft’s table, so a report built with it will not refresh on a schedule on the server. ODBC, however, is in the list and supports scheduled refresh with user name and password or Windows authentication. The way through is to install the ClickHouse ODBC driver on the report server and on the machines where reports are built, and to use the generic ODBC connector in the report. The same thinking applies to any source missing from the list: check the table first, then ODBC, and only then plan the reports.

The good news: no gateway is needed. The server reaches the sources in your network directly.

What exists only in the cloud

The on-premises version does not have everything the Power BI service has. According to Microsoft’s comparison, the server has no dashboards, no Q&A, no email subscriptions to Power BI reports, no data alerts, no composite models, no R or Python visuals and no apps for distributing reports. If one of these is essential for your team, that is a strong argument for the cloud or for a mix of both.

Growth: more servers and a later move to the cloud

More servers. When one server is no longer enough, several instances share one ReportServer database behind a load balancer (scale-out). All instances must run the same version and use the same key, and for Power BI reports the load balancer must keep each user on the same server during a session (client affinity, “sticky sessions”). Microsoft also has a capacity planning guide.

Moving to a new server. The procedure for moving an installation to a new server is in the migration guide. Back up the encryption key right after installation and keep it off the server.

Moving to the cloud. Paginated reports (.rdl) move to a Power BI workspace with the migration tool, which checks for unsupported sources and report elements. Power BI reports are republished from Power BI Desktop. If reports are built on shared, well named sources from day one, the later move is much easier.

A tip from practice: keep Power BI Desktop for Report Server and the server itself on the same release and upgrade them together. That avoids files the server cannot open.

Preparing for a Microsoft license audit

When Microsoft or a partner asks for a license review, the question is simple: how many cores do you use, and under which license. The answer is hard if it has to be collected by hand after years of changes to virtual machines.

It is better to have the data recorded automatically and regularly. For every server running SQL Server or Report Server, record the date, the server name, whether it is a virtual machine, the number of processors and cores, the SQL Server edition and version, and the number of processors SQL Server sees. A short PowerShell script writes this to a CSV file:

# licence-export.ps1: one row per run, to keep a history of changes
$cpu = Get-CimInstance Win32_Processor
$sys = Get-CimInstance Win32_ComputerSystem
$sql = Invoke-Sqlcmd -ServerInstance 'localhost' -TrustServerCertificate -Query @"
SELECT SERVERPROPERTY('Edition') AS Edition,
       SERVERPROPERTY('ProductVersion') AS Version,
       (SELECT cpu_count FROM sys.dm_os_sys_info) AS SqlCpuCount
"@
[pscustomobject]@{
  Date        = Get-Date -Format 'yyyy-MM-dd'
  Server      = $env:COMPUTERNAME
  Model       = $sys.Model
  Sockets     = @($cpu).Count
  Cores       = ($cpu | Measure-Object NumberOfCores -Sum).Sum
  Logical     = $sys.NumberOfLogicalProcessors
  SqlEdition  = $sql.Edition
  SqlVersion  = $sql.Version
  SqlCpuCount = $sql.SqlCpuCount
} | Export-Csv 'D:\audit\licence.csv' -Append -NoTypeInformation

Task Scheduler runs it, for example every Monday morning:

$action  = New-ScheduledTaskAction -Execute 'powershell.exe' -Argument '-NoProfile -File D:\audit\licence-export.ps1'
$trigger = New-ScheduledTaskTrigger -Weekly -DaysOfWeek Monday -At 6am
Register-ScheduledTask -TaskName 'Licence export' -Action $action -Trigger $trigger -User 'SYSTEM'

Invoke-Sqlcmd needs the SqlServer PowerShell module, and the account the task runs under needs VIEW SERVER STATE on SQL Server. On the virtualization host, also export the configuration of the virtual machines themselves (virtual processors per machine), because licenses are counted per virtual core. After a year you have a history you simply hand over instead of rebuilding it.

The order of steps

1. Check your licensing basis. Which SQL Server version and edition you have, whether Software Assurance is active, or whether you have Premium or a Fabric F64 reservation.
2. List your data sources and check each one against Microsoft’s table of supported sources. For those missing, try ODBC.
3. Decide how permissions are granted: AD groups or local accounts. If you go with AD, plan Kerberos.
4. Set up the server on a virtual or physical machine, first with the Developer edition, and try your hardest report.
5. Back up the encryption key and plan upgrades for January, May and September.
6. Turn on the automatic audit export from day one.
7. Move the reports over and agree on the rules: who publishes, where, and with which source names.

If you are planning on-premises Power BI, or already have a server that does not work as it should, see the System architecture service. The portfolio includes a project where Power BI Report Server was set up from design to go-live. You can also write to us and describe your environment.