Power BI Report Server: On-Premises Deployment Guide

<h2>Why Power BI Report Server Still Matters in 2026</h2>

<p>Despite the accelerating shift toward cloud-based analytics, Power BI Report Server (PBRS) remains a critical component of the enterprise analytics landscape. Organizations in regulated industries such as healthcare, financial services, government, and defense often face data residency requirements, network isolation mandates, or compliance frameworks that prohibit or restrict cloud-hosted analytics. For these organizations, PBRS provides the full Power BI report authoring and consumption experience while keeping all data, reports, and infrastructure entirely within the organization's own data centers or private cloud environments.</p>

<p>Power BI Report Server is an on-premises report server that sits behind your firewall and delivers Power BI reports, paginated reports (RDL), Excel workbooks, and KPIs through a web portal. It supports interactive Power BI reports with the same visualizations available in the Power BI service, scheduled data refresh without cloud connectivity, row-level security for multi-tenant report distribution, and mobile report viewing through the Power BI mobile apps. Our <a href="/services/power-bi-consulting">Power BI consulting</a> team has deployed PBRS for healthcare systems managing PHI under HIPAA, financial institutions subject to SEC and FINRA regulations, defense contractors operating in classified environments, and state and local government agencies with strict data sovereignty requirements.</p>

<h2>When to Use Report Server vs. Power BI Service (Cloud)</h2>

<p>The decision between PBRS and the Power BI service is not binary. Many enterprise organizations deploy both, using PBRS for sensitive or regulated data and the Power BI service for broader organizational analytics. The following decision framework helps determine the right deployment model for each use case:</p>

<h3>Choose Power BI Report Server When</h3>

<ul> <li><strong>Regulatory compliance requires on-premises data residency</strong>: HIPAA, FedRAMP, ITAR, CJIS, and certain financial regulations may require that data and reports remain within organization-controlled infrastructure. PBRS ensures no data traverses public internet or resides in shared cloud tenants.</li> <li><strong>Network isolation is required</strong>: Air-gapped environments, classified networks (SIPRNet, JWICS), and industrial control system networks cannot connect to cloud services. PBRS operates fully offline.</li> <li><strong>Data sensitivity exceeds cloud risk tolerance</strong>: Even when regulations do not explicitly prohibit cloud analytics, organizations may determine that certain data classifications (PII aggregations, M&amp;A analysis, competitive intelligence) require on-premises hosting.</li> <li><strong>Existing on-premises infrastructure investment</strong>: Organizations with significant SQL Server infrastructure, existing SSRS deployments, and on-premises data warehouses may prefer PBRS to avoid hybrid complexity.</li> <li><strong>Paginated report requirements dominate</strong>: PBRS supports both Power BI interactive reports and paginated (RDL) reports. Organizations with heavy paginated report workloads (financial statements, regulatory filings, operational reports requiring pixel-perfect formatting) benefit from PBRS as their unified report server.</li> </ul>

<h3>Choose Power BI Service (Cloud) When</h3>

<ul> <li><strong>Collaboration and sharing are priorities</strong>: The Power BI service provides richer sharing, commenting, subscriptions, and app distribution capabilities.</li> <li><strong>AI and advanced features are needed</strong>: Copilot for Power BI, AI visuals, AutoML, natural language Q&amp;A, and <a href="/blog/getting-started-microsoft-fabric-2025">Microsoft Fabric</a> integration are cloud-only features.</li> <li><strong>Reduced infrastructure management</strong>: The Power BI service eliminates server patching, capacity planning, backup management, and high availability configuration.</li> <li><strong>Real-time streaming and push datasets</strong>: Real-time dashboards and streaming datasets are cloud-only capabilities.</li> <li><strong>External sharing with customers or partners</strong>: Azure AD B2B and Power BI Embedded provide superior external sharing capabilities in the cloud.</li> </ul>

<h3>Hybrid Deployment Model</h3>

<p>The hybrid model deploys both PBRS and the Power BI service, routing workloads based on data classification:</p>

<table> <thead> <tr><th>Data Classification</th><th>Deployment Target</th><th>Example</th></tr> </thead> <tbody> <tr><td>Restricted / Highly Sensitive</td><td>Power BI Report Server</td><td>PHI dashboards, financial risk models, classified analytics</td></tr> <tr><td>Confidential / Internal</td><td>Power BI Service (Premium)</td><td>Sales analytics, HR metrics, operational dashboards</td></tr> <tr><td>General / Public</td><td>Power BI Service (Pro/Embedded)</td><td>Marketing analytics, public data visualizations</td></tr> </tbody> </table>

<p>The <a href="/services/power-bi-architecture">Power BI architecture</a> decisions around hybrid deployment require careful planning of data classification policies, network connectivity, authentication federation, and governance frameworks.</p>

<h2>Architecture and Hardware Requirements</h2>

<p>Power BI Report Server architecture consists of several components that must be properly sized for your workload. Undersizing leads to poor report rendering performance, failed scheduled refreshes, and frustrated users. Oversizing wastes infrastructure budget. The following reference architectures cover common deployment scenarios.</p>

<h3>Single-Server Deployment (Small: Up to 100 Users)</h3>

<p>For small deployments with fewer than 100 concurrent users and moderate report complexity:</p>

<ul> <li><strong>CPU</strong>: 8 cores (Intel Xeon or AMD EPYC)</li> <li><strong>RAM</strong>: 32 GB minimum, 64 GB recommended</li> <li><strong>Storage</strong>: 500 GB SSD for report server databases and temporary files</li> <li><strong>OS</strong>: Windows Server 2022</li> <li><strong>SQL Server</strong>: SQL Server 2022 Standard or Enterprise (for the report server catalog databases)</li> <li><strong>Network</strong>: 1 Gbps minimum</li> </ul>

<p>In a single-server deployment, the Report Server web service, web portal, background processing (scheduled refresh, subscriptions), and the report server catalog databases all run on the same machine. This topology is appropriate for pilot deployments, development/test environments, and small production workloads.</p>

<h3>Scale-Out Deployment (Medium: 100-500 Users)</h3>

<p>For medium deployments, separate the report server components from the database tier:</p>

<ul> <li><strong>Report Server Tier (2 nodes behind load balancer)</strong>: 8 cores, 64 GB RAM each. Handles report rendering, web portal serving, and API requests. Network Load Balancer (NLB) or hardware load balancer distributes requests across nodes.</li> <li><strong>Database Tier (1 node, SQL Server)</strong>: 8 cores, 64 GB RAM, fast SSD storage (NVMe preferred). Hosts ReportServer and ReportServerTempDB databases. SQL Server Always On availability groups provide high availability.</li> <li><strong>Shared Storage</strong>: File share or Azure File Sync for encryption keys and shared configuration.</li> </ul>

<h3>Enterprise Deployment (Large: 500+ Users)</h3>

<p>For large enterprise deployments with hundreds of concurrent users and complex reports:</p>

<ul> <li><strong>Report Server Tier (4+ nodes)</strong>: 16 cores, 128 GB RAM each. Auto-scaling through VM scale sets if running in private cloud (Azure Stack, VMware).</li> <li><strong>Database Tier (SQL Server Always On AG)</strong>: Primary node with synchronous secondary for automatic failover. 16 cores, 128 GB RAM, NVMe storage. Read-only routing directs report rendering queries to secondary replicas.</li> <li><strong>Dedicated Refresh Processing</strong>: Separate server(s) for scheduled data refresh to isolate refresh workload from interactive report rendering. Configure in PBRS scale-out settings.</li> <li><strong>Reverse Proxy / WAF</strong>: For external access scenarios, deploy behind a reverse proxy (Azure Application Gateway, F5, NGINX) with WAF capabilities.</li> </ul>

<h3>Virtualization and Private Cloud</h3>

<p>PBRS is fully supported on virtual machines (Hyper-V, VMware ESXi) and private cloud platforms (Azure Stack HCI, Azure Stack Hub). Key virtualization considerations:</p>

<ul> <li><strong>CPU reservation</strong>: Reserve 100% of allocated vCPUs to prevent noisy-neighbor performance degradation during report rendering</li> <li><strong>Memory reservation</strong>: Reserve 100% of allocated RAM. Analysis Services (the engine that processes Power BI data models) is memory-intensive and performs poorly with memory ballooning or swapping.</li> <li><strong>Storage</strong>: Use direct-attached SSD or high-performance SAN. Avoid network-attached storage (NAS) for the TempDB and Analysis Services data directories.</li> <li><strong>Network</strong>: Ensure low-latency (<1ms) connectivity between report server nodes and the SQL Server database tier.</li> </ul>

<h2>Installation and Initial Configuration</h2>

<p>Installing Power BI Report Server involves downloading the PBRS installer from the Microsoft download center, running the setup wizard, and configuring the report server databases. The following steps cover a production-grade installation.</p>

<h3>Prerequisites</h3>

<ul> <li><strong>Windows Server 2022</strong> (or 2019) with latest cumulative updates</li> <li><strong>SQL Server 2022</strong> (or 2019) Database Engine installed and accessible (local or remote)</li> <li><strong>.NET Framework 4.8</strong> or later</li> <li><strong>Service accounts</strong>: Dedicated domain service accounts for the Report Server service and the SQL Server Agent (for scheduled operations). Do not use local system accounts in production.</li> <li><strong>SSL certificate</strong>: A trusted SSL certificate for HTTPS binding. Self-signed certificates are acceptable for development only.</li> <li><strong>DNS entry</strong>: A DNS A record or CNAME for the report server URL (e.g., reports.yourdomain.com)</li> </ul>

<h3>Installation Steps</h3>

<ol> <li><strong>Download the PBRS installer</strong> from the Microsoft Download Center. The installer is updated approximately every 4 months (January, May, September releases align with Power BI Desktop version compatibility).</li> <li><strong>Run the installer</strong> and select the installation directory. Accept the license terms and choose the edition (Evaluation, Developer, or Production with a product key).</li> <li><strong>Configure the Report Server</strong> using the Report Server Configuration Manager: <ul> <li><strong>Service Account</strong>: Set to the dedicated domain service account</li> <li><strong>Web Service URL</strong>: Configure the URL reservation (default port 80, recommend changing to 443 with SSL)</li> <li><strong>Database</strong>: Create or specify the ReportServer and ReportServerTempDB databases on your SQL Server instance</li> <li><strong>Web Portal URL</strong>: Configure the portal URL (typically the same hostname, different virtual directory)</li> <li><strong>Encryption Keys</strong>: Back up the encryption keys immediately. These are required for disaster recovery. Store the backup in a secure location separate from the report server.</li> </ul> </li> <li><strong>Configure HTTPS</strong>: Bind the SSL certificate to both the Web Service URL and Web Portal URL. Remove HTTP bindings in production to enforce encrypted connections.</li> <li><strong>Configure email settings</strong>: Set the SMTP server for report subscriptions and data-driven subscriptions. Test email delivery before going live.</li> </ol>

<h3>Post-Installation Verification</h3>

<pre><code>-- Verify report server databases exist SELECT name, state_desc, recovery_model_desc FROM sys.databases WHERE name IN ('ReportServer', 'ReportServerTempDB')

-- Check report server catalog USE ReportServer SELECT COUNT(*) AS TotalItems FROM Catalog SELECT * FROM ConfigurationInfo WHERE Name = 'SiteName'</code></pre>

<p>Browse to the web portal URL (e.g., https://reports.yourdomain.com/reports) and verify you can access the home page. The initial state shows an empty portal ready for content deployment.</p>

<h2>Report Publishing and Content Management</h2>

<p>Content reaches Power BI Report Server through several publishing methods, each suited to different workflows and report types.</p>

<h3>Publishing Power BI Reports (.pbix)</h3>

<p>Power BI reports are authored in <strong>Power BI Desktop for Report Server</strong>, a special edition of Power BI Desktop that targets PBRS rather than the cloud service. This edition is updated on the same cadence as PBRS itself. Important: do not use the standard Power BI Desktop (Microsoft Store version) for reports targeting PBRS, as it may include features not yet supported on-premises.</p>

<ol> <li>Open the .pbix file in Power BI Desktop for Report Server</li> <li>Select File &gt; Save As &gt; Power BI Report Server</li> <li>Enter the report server URL and navigate to the target folder</li> <li>Click Save to publish the report</li> </ol>

<p>Alternatively, upload .pbix files directly through the web portal: navigate to the target folder, click Upload, and select the .pbix file. This method is useful for automated deployment scenarios where reports are built by CI/CD pipelines.</p>

<h3>Publishing Paginated Reports (.rdl)</h3>

<p>Paginated reports are authored in <strong>Power BI Report Builder</strong> (the successor to SQL Server Report Builder) or <strong>Visual Studio with the SSDT reporting extension</strong>. Publish paginated reports through:</p>

<ul> <li><strong>Report Builder</strong>: File &gt; Save As &gt; Report Server, enter the URL</li> <li><strong>Visual Studio</strong>: Set the TargetServerURL project property and deploy the project</li> <li><strong>Web portal upload</strong>: Upload .rdl files directly through the portal</li> <li><strong>REST API</strong>: Programmatic deployment using the PBRS REST API (useful for DevOps pipelines)</li> </ul>

<h3>Folder Structure and Organization</h3>

<p>Organize content in a logical folder hierarchy that aligns with your <a href="/services/power-bi-governance">Power BI governance</a> framework:</p>

<ul> <li><strong>By department</strong>: /Finance, /Sales, /Operations, /HR, /Executive</li> <li><strong>By function</strong>: /Financial Reporting, /Operational Dashboards, /Compliance Reports</li> <li><strong>By environment</strong>: /Development, /Staging, /Production (if using a single server for multiple environments)</li> </ul>

<p>Apply folder-level security to control access. Each folder inherits permissions from its parent by default, but permissions can be customized at any level in the hierarchy.</p>

<h2>Data Source Management</h2>

<p>Data source configuration in PBRS differs from the cloud Power BI service. There is no data gateway component; the report server connects directly to data sources accessible from the server's network location.</p>

<h3>Shared Data Sources</h3>

<p>Create shared data sources for connection strings used by multiple reports. This centralizes credential management and connection string updates:</p>

<ul> <li><strong>SQL Server</strong>: Direct connection using Windows integrated authentication or SQL authentication</li> <li><strong>Oracle</strong>: Requires Oracle Client installation on the report server</li> <li><strong>SAP HANA</strong>: Requires SAP HANA ODBC driver</li> <li><strong>ODBC/OLE DB</strong>: Any ODBC or OLE DB data source with appropriate drivers installed</li> <li><strong>Analysis Services</strong>: Direct connection to SSAS tabular or multidimensional instances</li> </ul>

<h3>Credential Storage Options</h3>

<table> <thead> <tr><th>Credential Type</th><th>Use Case</th><th>Security Consideration</th></tr> </thead> <tbody> <tr><td>Windows Integrated</td><td>Users access data with their own credentials</td><td>Requires Kerberos delegation; most secure for user-context queries</td></tr> <tr><td>Stored Credentials</td><td>Scheduled refresh, subscriptions</td><td>Encrypted in report server database; service account needs access</td></tr> <tr><td>Prompt for Credentials</td><td>Ad-hoc queries requiring user input</td><td>Credentials not stored; user must enter each time</td></tr> <tr><td>No Credentials</td><td>Anonymous data sources (public APIs, files)</td><td>Only for non-sensitive data sources</td></tr> </tbody> </table>

<h3>Supported Data Sources for Scheduled Refresh</h3>

<p>Power BI reports (.pbix) on PBRS support scheduled data refresh for a subset of data sources. The embedded Analysis Services instance processes the data model refresh. Supported sources include SQL Server, Oracle, Teradata, SAP HANA, OData, and ODBC sources. DirectQuery connections to SQL Server and Analysis Services are also supported, eliminating the need for scheduled refresh by querying data sources live at report rendering time.</p>

<h2>Authentication: Windows, Kerberos, and Custom Security</h2>

<p>Authentication is one of the most complex aspects of PBRS deployment, particularly in enterprise environments with multiple domains, forests, or external access requirements.</p>

<h3>Windows Authentication (NTLM)</h3>

<p>The default authentication mode. Users authenticate using their Windows domain credentials (Active Directory). NTLM authentication works within a single domain or forest and does not require additional configuration beyond standard Active Directory infrastructure. However, NTLM has a critical limitation: it does not support credential delegation. When a report needs to query a data source on a different server using the user's identity (the "double-hop" scenario), NTLM fails because the report server cannot forward the user's credentials to the data source.</p>

<h3>Kerberos Constrained Delegation</h3>

<p>Kerberos constrained delegation solves the double-hop problem by allowing the report server service account to impersonate the user when connecting to specific backend data sources. Configuration requires:</p>

<ol> <li><strong>Service Principal Names (SPNs)</strong>: Register SPNs for the report server service account: <pre><code>setspn -s HTTP/reports.yourdomain.com DOMAIN\pbrs-service setspn -s HTTP/reportserver DOMAIN\pbrs-service</code></pre> </li> <li><strong>Constrained delegation in Active Directory</strong>: Configure the report server service account for constrained delegation to specific target services (e.g., MSSQLSvc/sqlserver.yourdomain.com:1433 for SQL Server data sources).</li> <li><strong>Report server configuration</strong>: Set the rsreportserver.config authentication type to RSWindowsNegotiate (which attempts Kerberos first, falls back to NTLM): <pre><code>&lt;Authentication&gt; &lt;AuthenticationTypes&gt; &lt;RSWindowsNegotiate /&gt; &lt;/AuthenticationTypes&gt; &lt;/Authentication&gt;</code></pre> </li> <li><strong>Verification</strong>: Use Kerberos diagnostic tools (klist, Wireshark, Event Viewer) to confirm Kerberos tickets are being issued and delegation is working.</li> </ol>

<p>Kerberos configuration is the single most common source of PBRS deployment issues. Our <a href="/services/power-bi-architecture">Power BI architecture</a> team has resolved hundreds of Kerberos delegation failures across enterprise environments. Common pitfalls include duplicate SPNs, incorrect delegation targets, clock skew between domain controllers and report servers, and missing trust relationships in multi-forest environments.</p>

<h3>Custom Security Extensions</h3>

<p>For scenarios where Windows authentication is not feasible (e.g., external users without domain accounts, Linux clients, cross-organization access), PBRS supports custom security extensions that replace Windows authentication with forms-based or token-based authentication. Microsoft provides a <a href="/blog/power-bi-row-level-security-rls-enterprise-guide-2026">custom security sample</a> on GitHub that implements forms authentication against a SQL Server user database. Enterprise implementations typically integrate with SAML identity providers (Okta, Azure AD, PingFederate) through custom security extension development.</p>

<h2>Scheduling, Refresh, and Subscriptions</h2>

<p>Scheduled operations are a core PBRS capability that differentiates it from simply embedding Power BI Desktop files on a file share.</p>

<h3>Scheduled Data Refresh</h3>

<p>Power BI reports (.pbix) with imported data models require scheduled refresh to keep data current. Configure refresh through the web portal:</p>

<ol> <li>Navigate to the report in the web portal</li> <li>Click the ellipsis (...) &gt; Manage</li> <li>Select Scheduled Refresh</li> <li>Configure the schedule (frequency, time, time zone)</li> <li>Enter data source credentials (stored credentials required for scheduled refresh)</li> <li>Enable the schedule</li> </ol>

<p>Refresh schedules support daily, weekly, and monthly frequencies. For more frequent refresh (e.g., every 15 minutes), use DirectQuery mode instead of import mode to eliminate scheduled refresh entirely. Monitor refresh status through the web portal or by querying the report server database directly:</p>

<pre><code>-- Check scheduled refresh status SELECT c.Name AS ReportName, c.Path AS ReportPath, s.LastRunTime, s.LastStatus, s.NextRunTime FROM Schedule s JOIN ReportSchedule rs ON s.ScheduleID = rs.ScheduleID JOIN Catalog c ON rs.ReportID = c.ItemID WHERE s.EventType = 'RefreshModel' ORDER BY s.LastRunTime DESC</code></pre>

<h3>Report Subscriptions</h3>

<p>Subscriptions deliver reports to users on a schedule without requiring them to visit the web portal:</p>

<ul> <li><strong>Email subscriptions</strong>: Deliver rendered reports (PDF, Excel, Word, PowerPoint, MHTML) via email on a configured schedule. Configure SMTP settings in Report Server Configuration Manager.</li> <li><strong>File share subscriptions</strong>: Write rendered reports to a network file share. Useful for archiving, integration with document management systems, or delivery to users who access shared drives.</li> <li><strong>Data-driven subscriptions</strong> (Enterprise edition): Dynamic subscriptions where recipient lists, rendering formats, and parameters are driven by a database query. Enables personalized report delivery at scale (e.g., each regional manager receives their region's sales report).</li> </ul>

<h3>Cache and Execution Plans</h3>

<p>For frequently accessed paginated reports with expensive queries, configure execution caching:</p>

<ul> <li><strong>Live execution</strong>: Report runs the query on every request. Freshest data but highest data source load.</li> <li><strong>Cached instance</strong>: Report renders once and subsequent requests receive the cached output until expiration. Reduces data source load for popular reports.</li> <li><strong>Execution snapshot</strong>: Report renders on a schedule and all users see the snapshot. Ensures all users see identical data and eliminates query load during business hours.</li> <li><strong>Report history</strong>: Store snapshots in history for point-in-time comparison and audit trail.</li> </ul>

<h2>Web Portal Customization</h2>

<p>The PBRS web portal is the primary user interface for report discovery and consumption. Customize the portal to align with your organization's branding and user experience requirements.</p>

<h3>Branding Customization</h3>

<p>Create a brand package (a ZIP file containing branding assets) and upload it through the portal settings:</p>

<ul> <li><strong>Logo</strong>: Replace the default Power BI logo with your organization's logo (recommended: 40px height, PNG with transparency)</li> <li><strong>Colors</strong>: Customize the portal color scheme (primary color, navigation background, text colors) through a metadata.xml file in the brand package</li> <li><strong>Site name</strong>: Set a custom portal title (e.g., "Contoso Analytics Portal" instead of "Power BI Report Server")</li> </ul>

<h3>KPIs and Mobile Reports</h3>

<p>Beyond Power BI and paginated reports, the web portal supports:</p>

<ul> <li><strong>KPIs</strong>: Create simple KPI tiles directly in the portal showing current value, goal, status, and trend. KPIs are useful for executive dashboards that display high-level metrics without full report complexity.</li> <li><strong>Mobile reports</strong>: Author mobile-optimized reports using SQL Server Mobile Report Publisher. These reports use a responsive layout designed for phone and tablet screens. Note that Microsoft has deprecated Mobile Report Publisher and recommends using Power BI reports with mobile layout for new development.</li> </ul>

<h2>Migration Path to Cloud</h2>

<p>Many organizations deploy PBRS as a starting point with a planned migration path to the Power BI service. The migration involves several workstreams:</p>

<h3>Report Migration</h3>

<ol> <li><strong>Inventory all reports</strong>: Catalog every report on PBRS including type (Power BI, paginated, KPI), data sources, refresh schedules, subscribers, and usage metrics. The PBRS REST API and catalog database queries provide this inventory.</li> <li><strong>Assess cloud readiness</strong>: Identify reports that can migrate directly (Power BI reports with cloud-compatible data sources), reports that need modification (data source changes, unsupported features), and reports that must remain on-premises (compliance, network isolation).</li> <li><strong>Migrate Power BI reports</strong>: Open .pbix files in standard Power BI Desktop, update data source connections to use the on-premises data gateway, and publish to Power BI service workspaces.</li> <li><strong>Migrate paginated reports</strong>: Upload .rdl files to Power BI Premium workspaces (paginated reports require Premium capacity or Premium Per User licensing in the cloud).</li> <li><strong>Recreate subscriptions</strong>: PBRS subscriptions do not migrate automatically. Recreate them as Power BI service subscriptions or Power Automate flows.</li> <li><strong>Redirect users</strong>: Update bookmarks, portal links, and embedded URLs to point to the new Power BI service locations.</li> </ol>

<h3>On-Premises Data Gateway</h3>

<p>The on-premises data gateway bridges on-premises data sources with the cloud Power BI service. Deploy the gateway on a server with network access to your on-premises data sources. The gateway establishes an outbound HTTPS connection to Azure Service Bus (no inbound firewall rules required) and relays queries from the Power BI service to on-premises data sources.</p>

<p>Gateway best practices for migration:</p>

<ul> <li>Deploy gateway in cluster mode (2+ nodes) for high availability</li> <li>Size gateway servers with at least 8 cores and 32 GB RAM</li> <li>Place gateway servers on the same network segment as data sources for low latency</li> <li>Monitor gateway performance using the built-in gateway monitoring or <a href="/blog/power-bi-performance-analyzer-optimization-2026">Power BI performance monitoring</a> tools</li> </ul>

<h2>Licensing: Power BI Premium Includes PBRS</h2>

<p>Understanding PBRS licensing is essential for cost-effective deployment:</p>

<ul> <li><strong>Power BI Premium (capacity-based)</strong>: P1 through P5 SKUs include the right to deploy Power BI Report Server. This is the most common licensing path for enterprise organizations because Premium capacity is often purchased for cloud Power BI features (dataflows, paginated reports, deployment pipelines, large models), and PBRS is included at no additional cost.</li> <li><strong>Power BI Premium Per User (PPU)</strong>: Does NOT include PBRS rights. PPU is a per-user license for Premium features in the cloud only.</li> <li><strong>SQL Server Enterprise Edition with Software Assurance</strong>: Includes PBRS rights. Organizations with existing SQL Server Enterprise licenses with active Software Assurance can deploy PBRS without purchasing Power BI Premium.</li> <li><strong>Power BI Report Server standalone</strong>: Can be purchased as a standalone server license, though this is less common than obtaining rights through Premium or SQL Server licensing.</li> </ul>

<p>Important: PBRS report consumers do not need individual Power BI Pro or Premium Per User licenses. Any user with network access to the report server can view reports, controlled by the report server's own security model. This makes PBRS cost-effective for broad report distribution to hundreds or thousands of users who do not need cloud Power BI features.</p>

<h2>Hybrid Scenarios and Coexistence</h2>

<p>Enterprise organizations frequently operate PBRS and the Power BI service simultaneously. Hybrid scenarios include:</p>

<ul> <li><strong>Pin PBRS reports to cloud dashboards</strong>: Users can pin tiles from on-premises PBRS reports to Power BI service dashboards, creating unified dashboards that combine cloud and on-premises content.</li> <li><strong>Shared semantic models</strong>: Develop data models once and deploy to both PBRS (for on-premises consumption) and the Power BI service (for cloud consumption). Maintain a single source of truth with deployment to both targets.</li> <li><strong>Unified mobile experience</strong>: The Power BI mobile apps connect to both the Power BI service and PBRS, providing users with a single mobile app for all their reports regardless of hosting location.</li> <li><strong>Governance integration</strong>: Apply consistent <a href="/services/power-bi-governance">governance policies</a> across both environments: naming conventions, certification processes, data classification labels, and endorsement workflows.</li> </ul>

<h2>Security Hardening and Best Practices</h2>

<p>Production PBRS deployments require security hardening beyond the default installation:</p>

<ul> <li><strong>Enforce HTTPS only</strong>: Remove all HTTP URL reservations. Configure HSTS headers through IIS or reverse proxy.</li> <li><strong>Restrict TLS versions</strong>: Disable TLS 1.0 and 1.1. Require TLS 1.2 or later on the report server and SQL Server instances.</li> <li><strong>Minimize service account privileges</strong>: The PBRS service account needs local logon rights and access to the report server databases. It does not need domain admin, local admin, or broad file system permissions.</li> <li><strong>Audit logging</strong>: Enable Windows audit logging for the report server process. Monitor the ExecutionLog and ExecutionLog3 views in the report server database for report access auditing.</li> <li><strong>Network segmentation</strong>: Place the report server in a dedicated network segment with firewall rules limiting inbound access to HTTPS (443) and outbound access to data sources on specific ports.</li> <li><strong>Patch management</strong>: Apply Windows Server cumulative updates, SQL Server cumulative updates, and PBRS updates on a regular cadence. Test updates in a non-production environment before production deployment.</li> </ul>

<pre><code>-- Audit report execution history SELECT UserName, ReportPath, TimeStart, TimeEnd, DATEDIFF(SECOND, TimeStart, TimeEnd) AS DurationSeconds, [Status], ByteCount, [RowCount], Source -- 1=Live, 2=Cache, 3=Snapshot, 4=History FROM ExecutionLog3 WHERE TimeStart &gt; DATEADD(DAY, -7, GETDATE()) ORDER BY TimeStart DESC</code></pre>

<h2>Monitoring and Performance Tuning</h2>

<p>Ongoing monitoring ensures PBRS remains performant as usage grows and report complexity increases.</p>

<h3>Key Monitoring Metrics</h3>

<ul> <li><strong>Report rendering time</strong>: Track average and P95 rendering times from ExecutionLog3. Reports consistently exceeding 30 seconds need optimization.</li> <li><strong>Scheduled refresh success rate</strong>: Monitor refresh failures and duration. Increasing refresh times indicate growing data volumes or degrading data source performance.</li> <li><strong>Memory utilization</strong>: The embedded Analysis Services instance (for Power BI report data models) consumes memory proportional to the number and size of loaded data models. Monitor memory pressure and configure memory limits in PBRS settings.</li> <li><strong>CPU utilization</strong>: High sustained CPU during report rendering indicates either undersized hardware or reports with inefficient <a href="/blog/power-bi-dax-variables-return-efficient-calculations-2026">DAX calculations</a>.</li> <li><strong>Active sessions and concurrent users</strong>: Track peak concurrent user counts to validate capacity planning assumptions.</li> </ul>

<h3>Performance Optimization Strategies</h3>

<ul> <li><strong>Optimize data models</strong>: Reduce model size through column removal, data type optimization, and aggregation tables. Smaller models load faster and consume less memory.</li> <li><strong>Use DirectQuery for large or real-time data</strong>: Eliminate refresh overhead and memory consumption for frequently changing data sources.</li> <li><strong>Configure memory limits</strong>: Set the Analysis Services memory limits in the PBRS configuration to prevent a single large model from consuming all available memory.</li> <li><strong>Scale out report rendering</strong>: Add report server nodes behind a load balancer to distribute rendering workload.</li> <li><strong>Offload scheduled refresh</strong>: Configure specific nodes in a scale-out deployment to handle only scheduled refresh, preventing refresh processing from impacting interactive report rendering.</li> </ul>

<h2>Disaster Recovery and Backup</h2>

<p>A comprehensive disaster recovery plan for PBRS includes:</p>

<ul> <li><strong>Database backups</strong>: Regular backups of ReportServer and ReportServerTempDB databases using SQL Server native backup or your enterprise backup solution.</li> <li><strong>Encryption key backup</strong>: The PBRS encryption key is required to restore the report server. Without it, all stored credentials are unrecoverable. Back up the key immediately after installation and after any key rotation.</li> <li><strong>Report content backup</strong>: While reports are stored in the catalog database, maintain source-controlled copies of all .pbix and .rdl files in a version control system (Git, Azure DevOps) as a secondary recovery path.</li> <li><strong>Configuration backup</strong>: Back up rsreportserver.config, rssrvpolicy.config, and web.config files.</li> <li><strong>Recovery testing</strong>: Test disaster recovery procedures quarterly. Restore to a separate environment and verify report rendering, data refresh, and security configuration.</li> </ul>

<p><a href="/contact">Contact EPC Group</a> to plan and execute your Power BI Report Server deployment. Our <a href="/services/power-bi-consulting">Power BI consulting</a> and <a href="/services/power-bi-architecture">architecture teams</a> have deployed PBRS for healthcare systems, financial institutions, government agencies, and defense contractors. We bring deep expertise in Kerberos authentication, scale-out architecture, hybrid cloud integration, security hardening, and migration planning to ensure your on-premises analytics platform meets enterprise requirements for performance, security, and compliance.</p>